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

Mark Andrews <marka@isc.org> Wed, 04 July 2018 22:55 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 6E38C130DDB for <dnsop@ietfa.amsl.com>; Wed, 4 Jul 2018 15:55:36 -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 SMDBYtzjVDhY for <dnsop@ietfa.amsl.com>; Wed, 4 Jul 2018 15:55:35 -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 58C00130DC9 for <dnsop@ietf.org>; Wed, 4 Jul 2018 15:55:35 -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 086033AB03E; Wed, 4 Jul 2018 22:55:34 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C2552160042; Wed, 4 Jul 2018 22:55:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B2BC4160047; Wed, 4 Jul 2018 22:55:33 +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 r2ID7WXb0Lb1; Wed, 4 Jul 2018 22:55:33 +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 09DEB160042; Wed, 4 Jul 2018 22:55:32 +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: <CAHw9_iK605yw--xE0NutaF=r+MfmmT2cBj9eNnSOh4Swkx=_QQ@mail.gmail.com>
Date: Thu, 5 Jul 2018 08:55:28 +1000
Cc: dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3D1B7766-A50E-4B7A-A8B4-DBF423112684@isc.org>
References: <CAHw9_iK605yw--xE0NutaF=r+MfmmT2cBj9eNnSOh4Swkx=_QQ@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xVx-Yeosqg7QR5cBOI2Vs4cP7lE>
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: Wed, 04 Jul 2018 22:55:37 -0000

This paragraph is factually incorrect.

   Possibly this problem could have been avoided if we had forced all
   NAT64 gateways to use the same Well-Known Prefix for IPv6 address
   synthesis [RFC6052].  If the decision had been made to use a single
   fixed Well-Known Prefix, then there would have been no need for
   clients to discover the local network's NAT64 prefix, and no need for
   the 'ipv4only.arpa' [RFC7050] query.  However, that was not the
   decision that was made.

ipv4only.arpa would still be needed even when using the well known prefix
as it is used to discover if the well-known-prefix is being USED or not.

i.e. ipv4only.arpa performs 2 functions.
1) discovery of whether AAAA synthesis is occurring.
2) discovery of the prefix associated with that synthesis.

Forcing everyone to use the WKP would remove 2 but 1 would still remain.

This paragraph is wrong.

       Traditional recursive resolvers SHOULD NOT recognize
       'ipv4only.arpa' as special or give that name, or subdomains of
       that name, any special treatment.  The rationale for this is that
       a traditional recursive resolver, such as built in to a home
       gateway, may itself be downstream of a DNS64 recursive resolver.
       Passing though the 'ipv4only.arpa' queries to the upstream DNS64
       recursive resolver will allow the correct NAT64 prefix to be
       discovered.

A FORWARDING recursive server needs to pass through the queries.
(For BIND9 that is forward-only)
A ITERATIVE recursive server needs to answer the queries locally
except for ipv4only.arpa/DS.
(For BIND9 that is plain forwarding and not forwarding modes)

CPE recursive servers are often FORWARDING recursive servers.

There is not such thing as a TRADITIONAL recursive server.

This paragraph needs to be re-worded to permit DS queries for ipv4only.arpa
to hit the ARPA servers.  Also “domain" should be replaced with “zone”.  You
want the servers to serve the ipv4only.arpa zone.  

       All DNS64 recursive resolvers MUST recognize 'ipv4only.arpa' as
       special and MUST NOT attempt to look up NS records for it, or
       otherwise query authoritative name servers in an attempt to
       resolve this name.  Instead, DNS64 recursive resolvers MUST act
       as authoritative for this domain and generate immediate responses
       for all such queries.

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