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