Re: [DNSOP] [v6ops] [IANA #989438] ipv4only.arpa's delegation should be insecure.

Mark Andrews <marka@isc.org> Tue, 19 June 2018 02:16 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 53AA0131045; Mon, 18 Jun 2018 19:16:12 -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 fvckevYfKSq9; Mon, 18 Jun 2018 19:16:10 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 4E150131030; Mon, 18 Jun 2018 19:16:10 -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 6E0153AB03F; Tue, 19 Jun 2018 02:16:09 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 37809160079; Tue, 19 Jun 2018 02:16:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 20BC416008D; Tue, 19 Jun 2018 02:16:06 +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 qSlYQdjDoOxQ; Tue, 19 Jun 2018 02:16:06 +0000 (UTC)
Received: from rock-73422.home.lan (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 94732160079; Tue, 19 Jun 2018 02:16:04 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <CAPt1N1mzNa5i42-ATH_1wOq5qoexKTy6qK2vZOo2ipvjYb2axQ@mail.gmail.com>
Date: Tue, 19 Jun 2018 12:16:01 +1000
Cc: David Schinazi <dschinazi@apple.com>, IPv6 Operations <v6ops@ietf.org>, Michelle Cotton via RT <iana-questions@iana.org>, Stuart Cheshire <cheshire@apple.com>, Warren Kumari <warren@kumari.net>, dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DF2212F8-500D-49DF-B5E6-ECE490F88852@isc.org>
References: <rt-4.2.9-2607-1515188710-296.989438-6-0@icann.org> <FAA35F1A-9AD4-4993-9A5C-53A6143B9DE7@isc.org> <43D81243-B2D8-4622-B03D-D20DB7EC243C@apple.com> <DE670372-BF0E-4A81-8DB3-6CC2595B7D8E@isc.org> <CAHw9_iKBiWe4-EgMkT6_rYHDS0QLjbaZ1BYAsg3XkF2368g+rg@mail.gmail.com> <A9DBE612-8260-45D6-9693-6ABA2628CE80@apple.com> <CAPt1N1mzNa5i42-ATH_1wOq5qoexKTy6qK2vZOo2ipvjYb2axQ@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/gF0rxaYtCdjOMHP0wDIvuJVnIMM>
Subject: Re: [DNSOP] [v6ops] [IANA #989438] ipv4only.arpa's delegation should be insecure.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 19 Jun 2018 02:16:13 -0000

> On 19 Jun 2018, at 11:35 am, Ted Lemon <mellon@fugue.com> wrote:
> 
> You should steal the text from the dot home RFC. 
> 
> On Mon, Jun 18, 2018 at 9:30 PM David Schinazi <dschinazi@apple.com> wrote:
> Hi, responses inline.
> 
>> On Tue, Jun 12, 2018 at 11:16 PM Mark Andrews <marka@isc.org> wrote:
>> 
>> This does not meet my requirements. There is zero need for any part of the normal DNS resolution
>> process to know the IPV4ONLY.ARPA is special if IANA stopped signing the zone.
> 
> Could you take a look at draft-cheshire-sudn-ipv4only-dot-arpa please? It explains why some parts of the DNS resolution process do need to treat ipv4only.arpa as special, regardless of DNSSEC.
> 
>> On Jun 13, 2018, at 19:19, Warren Kumari <warren@kumari.net> wrote:
>> 
>> I read that a few times, and even when squinting I cannot figure out how that is supposed to work. Can someone enlighten me? I can see how a signed ipv4only.arpa allows a validating DNS64 server to validate the (well known!) v4 addresses, but the malicious AAAA RR detection bit confuses me...
> 
> I agree, there is no point in signing the A records for ipv4only.arpa since they are well-known, and for the same reason there is no point in checking it. So having A records signed or unsigned is irrelevant since no one should be querying for these A records anyway. Similarly, since the whole purpose of the AAAA records for ipv4only.arpa is to be overridden by a DNS64 recursive resolver which is not owned by .arpa, checking signatures will not validate anything useful.

No.  You expect DNS64 recursive server to query for them as part of the synthesis process when they get a request from a device that is attempting to configuring the CLAT service by asking for the AAAA records for ipv4only.arpa.  And to be pedantic one is overriding the NODATA response as there are no AAAA records for ipv4only.arpa.

> I agree with Mark's point that queries will fail when the client is behind a validating resolver that has no special knowledge of ipv4only.arpa.
> 
> To resolve this, we'll update draft-cheshire-sudn-ipv4only-dot-arpa to mention that ipv4only.arpa MUST NOT be signed.
> 
> Thanks,
> David
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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