Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

Mark Andrews <marka@isc.org> Fri, 04 May 2018 00:34 UTC

Return-Path: <marka@isc.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 BB91F1271FD for <dnsop@ietfa.amsl.com>; Thu, 3 May 2018 17:34:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Lh1m-wIe0uIp for <dnsop@ietfa.amsl.com>; Thu, 3 May 2018 17:34:37 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 9F5EB12704A for <dnsop@ietf.org>; Thu, 3 May 2018 17:34:37 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 374703AB045; Fri, 4 May 2018 00:34:37 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C6947160043; Fri, 4 May 2018 00:34:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id AF35C160055; Fri, 4 May 2018 00:34:36 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 98oivP5WD9gG; Fri, 4 May 2018 00:34:36 +0000 (UTC)
Received: from [172.30.42.90] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 7BE2C160043; Fri, 4 May 2018 00:34:35 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <7EA6E03A-412F-4EA0-82DB-CDEC64EAB7F6@pch.net>
Date: Fri, 04 May 2018 10:34:32 +1000
Cc: David Huberman <david.huberman@icann.org>, Edward Lewis <edward.lewis@icann.org>, Shane Kerr <shane@time-travellers.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9EDEF6A5-0A24-438F-82B4-DAA337156B4E@isc.org>
References: <7C873271-A784-4594-91A3-48C697EEC613@vpnc.org> <b3ed96d7-26fb-3d97-118b-39e8f352a38c@time-travellers.org> <87F43055-5B0E-4551-BD8D-241D93F9039F@icann.org> <0AA87D00-17F7-4D10-A72D-E4723C4A0642@icann.org> <B1F34038-595E-48A5-AFB6-20F3214BB8BF@isc.org> <EFC5B29C-48D2-4F5C-BF2D-26C26E302889@icann.org> <40451767-9536-448B-8BBD-A592AD430A78@pch.net> <29B15AF5-7C26-4373-8B97-E90D223B8D2A@icann.org> <7EA6E03A-412F-4EA0-82DB-CDEC64EAB7F6@pch.net>
To: Bill Woodcock <woody@pch.net>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fVdgOYuUGRwD0q54wcOHdgpAOdM>
Subject: Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)
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 00:34:40 -0000

> On 4 May 2018, at 10:13 am, Bill Woodcock <woody@pch.net> wrote:
> 
> 
> 
>> On May 3, 2018, at 4:28 PM, David Huberman <david.huberman@icann.org> wrote:
>> 
>>>> On May 3, 2018, at 3:27 PM, David Huberman <david.huberman@icann.org> wrote:
>>>> In practical terms, when any type of registry strips away a lame delegation
>>>> attached to a real, operating network with users behind it, and things break
>>>> as a result…
>> 
>> Woody replied:
>>> But isn’t that, by definition, impossible?  What could break as a result of a _lame_ delegation
>>> being removed?
>> 
>> Mark provided you with a forward DNS example. Here’s a _common_ reverse DNS example:
>> 
>> You are the registrant of 192.168.0.0/17.
>> You setup a single SOA record for 168.192.in-addr.arpa instead of properly defining 128 records
>> for each /24 reverse zone.
>> 
>> PTR queries to the NSes will work (for the /17).
>> 
>> But you’ll fail the lameness checking at an RIR because the RIR checks all zones in the
>> SOA record, and assumes that if you assert 168.192.in-addr.arpa, that you really meant
>> to claim authority over the /16.
> 
> Errrr, but that’s a special RIR alternate understanding of what lameness means, specific to CIDR, no?

No.  That is one form of basic DNS lameness.  The server delegated to doesn’t server the delegated zone.

> In the general DNS sense, if the NS can answer PTR queries for the thing delegated to it, it’s not lame.  And we’re talking about forward here, not in-addr, and more specifically, not the special CIDR in-addr.

DNS servers need to produce VALID negative answers as well as VALID positive answers for the name space delegated to them.  You need to test for BOTH types of answers.  Failure to produce VALID negative answers causes problems when new types are introduced.

Look at the history of AAAA, SPF, and TLSA records.  All of these are/were issued by clients to see if the records existed at given names.  While these are mostly forward zone issues the same issues could arise in the IN-ADDR.ARPA and IP6.ARPA name spaces.  We don’t know what is coming in the future.  We have however defined how those queries should be answered.  We can test to ensure that correct behaviour occurs.

>                                -Bill
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org