IETF Logo Mail Archive

Re: [DNSOP] [Ext] Lameness terminology

Joe Abley <jabley@automagic.org> Fri, 04 May 2018 14:24 UTC

Return-Path: <jabley@automagic.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6E2129C56 for <dnsop@ietfa.amsl.com>; Fri, 4 May 2018 07:24:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RDNS_NONE=0.793, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (OpenSSL error: data too large for key size)" header.d=automagic.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wkEgZP6Ts7g for <dnsop@ietfa.amsl.com>; Fri, 4 May 2018 07:24:15 -0700 (PDT)
Received: from mail.hopcount.ca (unknown [IPv6:2001:4900:1:392::156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA9812895E for <dnsop@ietf.org>; Fri, 4 May 2018 07:24:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=automagic.org ; s=hopcount; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version: Content-Type:Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=cCIxtrZ06fGO6NvJdEeSsWLDV7Ih/ndKB1vMTxHmw8g=; b=VEiM6utUR0WRu4a13BsBXjI2pQ cZNDZOciG0A+4y1cnU9bC4fEwYWjp7Vtp38JhcqokuyJ/odTq69jnN74bfo0xA60mvDkmYmYkmxhw AMkPkwQg2d8LAn4ScDCKsO8x/6YRWvf/iYPNAXu3ANkSFmbRYN6GvbYQOsn3lbuPJv+UkNMKfkTqk lWUAmxYW6mRXx45lemPoT4ShMoKsRja0Anp+DAMDcY9aIOTyyL92E8qcFLA36PV27mOnEBqMTbJ1z zU38ehDJz2Zg6eA0SkTgOCBnqaRWOeKZcRIlKqI7ko6xUa6QU7C1rRlFiSWa1GUEFqyBz3BJdf9xR zKB0L0ww==;
Received: from [23.233.21.69] (helo=[199.212.90.48]) by mail.hopcount.ca with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from <jabley@automagic.org>) id 1fEbd4-000Bex-Dz; Fri, 04 May 2018 14:24:11 +0000
From: Joe Abley <jabley@automagic.org>
Message-Id: <1B4F870E-97AB-40E3-9BB4-44F769D246CC@automagic.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_84409A0E-BAED-4813-9CF3-85B9138BBCF1"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Fri, 04 May 2018 10:24:09 -0400
In-Reply-To: <81f139a9-b806-b505-946c-4c1880974073@time-travellers.org>
Cc: Amreesh Phokeer <amreesh.phokeer@gmail.com>, "dnsop@ietf.org" <dnsop@ietf.org>
To: Shane Kerr <shane@time-travellers.org>
References: <7C873271-A784-4594-91A3-48C697EEC613@vpnc.org> <b3ed96d7-26fb-3d97-118b-39e8f352a38c@time-travellers.org> <87F43055-5B0E-4551-BD8D-241D93F9039F@icann.org> <CACRw5znmX559DpXv5Copn9u6YN0mUgrk9q5QT=bpUbYArU8VzA@mail.gmail.com> <81f139a9-b806-b505-946c-4c1880974073@time-travellers.org>
X-Mailer: Apple Mail (2.3445.6.18)
X-SA-Exim-Connect-IP: 23.233.21.69
X-SA-Exim-Mail-From: jabley@automagic.org
X-SA-Exim-Scanned: No (on mail.hopcount.ca); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/b1dD49WV0br3BJICpRPpS6H6LY8>
X-Mailman-Approved-At: Fri, 04 May 2018 07:32:46 -0700
Subject: Re: [DNSOP] [Ext] Lameness terminology
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 May 2018 14:27:07 -0000

On 4 May 2018, at 05:59, Shane Kerr <shane@time-travellers.org> wrote:

> I think that there may be something useful in creating a term when a
> delegation only points to lame servers, thus cannot be resolved at all.
> Perhaps "broken delegation"?

One thing that I think has been missing from much of this conversation (but not all) is the idea that the vantage point matters when determining if a server is lame for a particular zone [1].

Just because from my vantage point I can't get responses from any of the nameservers cited in a referral response doesn't mean that my experience is universal. Some of the servers might be reachable in other routing domains; some servers might be blocking my queries due to some transient network problem that affects just a subset of its potential clients, or because addresses near me have been participating in an attack, etc, etc.

I am wary of any description that implies that there is some simple measure of lameness that is universal.


Joe

[1] the grammar also seems to vary between opinions. Is a server lame for a domain? Or for a particular query? What do we mean by server, in the case where a single instance of nameserver software running in a single compute environment responds to multiple addresses, e.g. is dual-stacked?

v2.23.0 | Report a Bug | By Email