Re: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa

Mark Andrews <marka@isc.org> Fri, 06 July 2018 11:37 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 D968B130E5B for <dnsop@ietfa.amsl.com>; Fri, 6 Jul 2018 04:37:00 -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 CbtSUCiV9DWy for <dnsop@ietfa.amsl.com>; Fri, 6 Jul 2018 04:36:59 -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 BB024130EA3 for <dnsop@ietf.org>; Fri, 6 Jul 2018 04:36:59 -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 65C063AB063; Fri, 6 Jul 2018 11:36:58 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2F64416003A; Fri, 6 Jul 2018 11:36:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1FD92160047; Fri, 6 Jul 2018 11:36:55 +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 LS4LolynNFYA; Fri, 6 Jul 2018 11:36:55 +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 740CD16003A; Fri, 6 Jul 2018 11:36:54 +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: <m1fbMar-0000HxC@stereo.hq.phicoh.net>
Date: Fri, 06 Jul 2018 21:36:51 +1000
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1ACD3204-1040-46B6-B005-5034ED5F17DC@isc.org>
References: <m1fb194-0000FpC@stereo.hq.phicoh.net> <A61E2913-891E-4F14-82AF-A8A40F39F47F@isc.org> <m1fbMB8-0000FkC@stereo.hq.phicoh.net> <FA54B85D-EBD7-4852-86F2-672B918A96E1@isc.org> <m1fbMar-0000HxC@stereo.hq.phicoh.net>
To: Philip Homburg <pch-dnsop-3@u-1.phicoh.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/p6XLg0m6D2kTQiJVrUxnfu4Aqn0>
Subject: Re: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa
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: Fri, 06 Jul 2018 11:37:01 -0000

> On 6 Jul 2018, at 6:59 pm, Philip Homburg <pch-dnsop-3@u-1.phicoh.com> wrote:
> 
> In your letter dated Fri, 6 Jul 2018 18:50:44 +1000 you wrote:
>> All it does is ensure that the DNS queries get to the DNS64 server. 
> 
> The way RFC 7050 works that you send queries to your local recursive
> resolver. The problem there is that if the user manually configured
> a public recursive resolver then you don't learn the translation prefix.
> 
> In this context I don't see how serving ipv4only.arpa from dedicated addresses
> would help. 

When the local recursive server forwards the query to the ISP’s servers
they get the AAAA records.

With a dedicated prefix if the recursive server is iterative it will get
the delegation from the ARPA servers and find the ISP’s servers ipv4only.arpa 
which will return the prefix.  This is how I run my servers though it will
be a cold day in hell by the time my ISP delivers IPv6 let alone IPv6-only.
(I’ve only been asking for IPv6 since 2003).

This doesn’t help with those that send queries to 8.8.8.8, only DPI or
having the recursive server follow the learned DNS server for ipv4only.arpa 
will help with that scenario.

It’s all about closing off failure paths.

> We can define a new prefix discovery protocol where the node that needs to
> discover the prefix directly queries the authoritative servers for
> ipv4only.arpa. That would solved the issue with manually configured 
> resolvers. But it would also add yet another way off discovering the prefix
> that needs to be supported.



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