Re: [DNSOP] [Ext] Lameness terminology
Shane Kerr <shane@time-travellers.org> Fri, 04 May 2018 09:59 UTC
Return-Path: <shane@time-travellers.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 5134412D7F0 for <dnsop@ietfa.amsl.com>; Fri, 4 May 2018 02:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.401
X-Spam-Level:
X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 JMHAJLFafbxb for <dnsop@ietfa.amsl.com>; Fri, 4 May 2018 02:59:47 -0700 (PDT)
Received: from time-travellers.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D420126C26 for <dnsop@ietf.org>; Fri, 4 May 2018 02:59:47 -0700 (PDT)
Received: from [65.19.167.131] (helo=[127.0.0.1]) by time-travellers.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <shane@time-travellers.org>) id 1fEXWO-0001l2-09; Fri, 04 May 2018 10:01:00 +0000
To: Amreesh Phokeer <amreesh.phokeer@gmail.com>
Cc: "dnsop@ietf.org" <dnsop@ietf.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>
From: Shane Kerr <shane@time-travellers.org>
Message-ID: <81f139a9-b806-b505-946c-4c1880974073@time-travellers.org>
Date: Fri, 04 May 2018 09:59:00 +0000
MIME-Version: 1.0
In-Reply-To: <CACRw5znmX559DpXv5Copn9u6YN0mUgrk9q5QT=bpUbYArU8VzA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/irbFL-YIr5sdAfKHU5CC1n6gODA>
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 09:59:49 -0000
Amreesh, Amreesh Phokeer: > On Wed, May 2, 2018 at 11:47 PM, Edward Lewis <edward.lewis@icann.org> > wrote: >> >> >> If I can't find the text soon, I'll try to recreate the list of references >> at least. >> > > We are in process of implementing a "Lame delegations" policy at AFRINIC > <http://tiny.cc/afrinic-lame> > > We consider "lame" any NS which is either: > - Not responding at all. > - Responding in some way, but not for the specific domain queried. > - Responding for the correct domain, but without the authority bit set. > > We used the definition in RFC1713: > > A lame delegation is a serious error in DNS configurations, yet a > (too) common one. It happens when a name server is listed in the NS > records for some domain and in fact it is not a server for that > domain. Queries are thus sent to the wrong servers, who don't know > nothing (at least not as expected) about the queried domain. > Furthermore, sometimes these hosts (if they exist!) don't even run > name servers. As a result, queries are timed out and resent, only to > fail, thus creating (more) unnecessary traffic. A reference! Nice. Pending Ed's archival research, it seems like we need to actually do some work to structure the concepts around lameness. Digging in... Within a given NS RRset for a zone, we have a few failure modes: A. One or more NS do not resolve B. NS RR points to a CNAME (technically disallowed, right?) C. NS RR does not point to any A or AAAA that resolve D. An A or AAAA RR is for one or more addresses that are not authoritative Case C might not strictly be lame, if for example it points to a .ONION address or similar. Case D might be usefully split into addresses that reply and those that timeout. I think that all of these fit into the definition of "lame delegation" in RFC 1713. I don't know if it makes sense to have any more definitions for anything in this list beyond that. Probably not. 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"? 😉 There are also a few related issues coming from mismatches at parent & child. 1. "Lame hint" might describe an NS that is above the zone cut, and points to one or more lame servers 2. "Authoritatively lame" might describe an NS that is below the zone cut 3. "Totally lame, man" might describe a lame NS that is in both We can also have: 4. "Confusingly lame" which might describe when there is a mismatch between NS answers of authoritative servers, some of which point to lame servers 😆 I hesitate to suggest it, but is there value in a draft around lameness? Cheers, -- Shane
- [DNSOP] Status of draft-ietf-dnsop-terminology-bis Paul Hoffman
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Matthijs Mekking
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Matthew Pounsett
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Paul Vixie
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Matthijs Mekking
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Stuart Cheshire
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… John Dickinson
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Paul Hoffman
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Paul Hoffman
- Re: [DNSOP] Status of draft-ietf-dnsop-terminolog… Paul Hoffman
- [DNSOP] Lameness terminology (was: Status of draf… Shane Kerr
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Edward Lewis
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Amreesh Phokeer
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… David Huberman
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Mark Andrews
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… David Huberman
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Bill Woodcock
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Frederico A C Neves
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Mark Andrews
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… David Huberman
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Mark Andrews
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… David Huberman
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Mark Andrews
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Bill Woodcock
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Bill Woodcock
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Bill Woodcock
- Re: [DNSOP] Fixing lame delegations Paul Hoffman
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Mark Andrews
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Mark Andrews
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… John Kristoff
- Re: [DNSOP] [Ext] Lameness terminology Paul Vixie
- Re: [DNSOP] [Ext] Lameness terminology Shane Kerr
- Re: [DNSOP] [Ext] Lameness terminology Shane Kerr
- Re: [DNSOP] [Ext] Lameness terminology Matthew Pounsett
- Re: [DNSOP] [Ext] Lameness terminology (was: Stat… Edward Lewis
- Re: [DNSOP] [Ext] Lameness terminology Joe Abley
- Re: [DNSOP] [Ext] Lameness terminology Joe Abley
- Re: [DNSOP] [Ext] Lameness terminology Edward Lewis
- Re: [DNSOP] [Ext] Lameness terminology Paul Hoffman
- Re: [DNSOP] [Ext] Lameness terminology Edward Lewis