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

Mark Andrews <marka@isc.org> Fri, 06 July 2018 00:54 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 8EC8F130FBD for <dnsop@ietfa.amsl.com>; Thu, 5 Jul 2018 17:54:34 -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 rzl_VlmH7Lpl for <dnsop@ietfa.amsl.com>; Thu, 5 Jul 2018 17:54:32 -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 97DC6130FBB for <dnsop@ietf.org>; Thu, 5 Jul 2018 17:54:32 -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 C4E983AB03E; Fri, 6 Jul 2018 00:54:28 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 8CCD9160044; Fri, 6 Jul 2018 00:54:27 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 79DF5160047; Fri, 6 Jul 2018 00:54:27 +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 HY_dRQ6qs8mC; Fri, 6 Jul 2018 00:54:27 +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 A6C81160044; Fri, 6 Jul 2018 00:54:26 +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: <CAPt1N1mavff_n9vA=TWCcXyf7FeBwcaeWHtnD4mKgiYoe9cmzg@mail.gmail.com>
Date: Fri, 06 Jul 2018 10:54:23 +1000
Cc: Philip Homburg <pch-dnsop-3@u-1.phicoh.com>, dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <47A1A210-AD27-4488-B991-958CEABEDFA0@isc.org>
References: <m1fb194-0000FpC@stereo.hq.phicoh.net> <A61E2913-891E-4F14-82AF-A8A40F39F47F@isc.org> <CAPt1N1mavff_n9vA=TWCcXyf7FeBwcaeWHtnD4mKgiYoe9cmzg@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/mqQyvOTYfu1aF7Pbm-r0pqJNiLo>
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 00:54:35 -0000

> On 6 Jul 2018, at 10:28 am, Ted Lemon <mellon@fugue.com> wrote:
> 
> If special handling is required for ipv4only.arpa, isn't it also required for home.arpa?   I tested this a bit and it doesn't appear to be necessary.   I suppose a stub resolver could in principle walk down from the root and notice the discrepancy in the NS records in the delegation, but in practice they don't do this, because it's not necessary: if it were intended that the zone be secure, it would be signed and have a signed delegation.

For HOME.ARPA the border is the CPE routers.  They can just intercept/redirect/proxy
queries as they are on path.  That said dedicated servers would allow for clients
to cleanly tie server properties to addresses (EDNS, DNS-COOKIE, whatever else we
dream up).  CPE’s could instantiate the well know address.  We don’t want to force
the CPE devices to have to do DPI for HOME.ARPA.

It would help but is not a critical.

> On Thu, Jul 5, 2018 at 6:37 PM, Mark Andrews <marka@isc.org> wrote:
> Most of the special handling could be avoided if IANA was instructed to run the servers for ipv4only.arpa on dedicated addresses. Hosts routes could then be installed for those address that redirect traffic for ipv4only.arpa to the ISP’s DNS64/ipv4only.arpa server. 
> 
> Perhaps 2 address blocks could be allocated for this purpose. One for ipv4 and one for ipv6. 
> 
> -- 
> Mark Andrews
> 
> On 5 Jul 2018, at 20:05, Philip Homburg <pch-dnsop-3@u-1.phicoh.com> wrote:
> 
> >> draft-cheshire-sudn-ipv4only-dot-arpa document
> > 
> > Section 7.1:
> > "Name resolution APIs and libraries MUST recognize 'ipv4only.arpa' as
> > "special and MUST give it special treatment. 
> > 
> > It seems to me that it is going way to far to require all DNS software to
> > implement support for a hack that abuses DNS for configuration management of
> > a rather poor IPv4 transition technology.
> > 
> > I think the more obvious approach is to formally deprecate RFC 7050 and
> > require nodes that need to do NAT64 address synthesis use one of the other
> > methods for obtaining the NAT64 prefix.
> > 
> > The only part of the draft that makes sense to me is to make ipv4only.arpa
> > an insecure delegation. 
> > 
> > Any other problems are better solved by deprecating RFC 7050.
> > 
> > _______________________________________________
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________
> 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