On 28 November 2016 at 15:24, Mark Andrews <ma...@isc.org> wrote:

> In message <CAAiTEH8x3=AxGPeZos=cbctdwufbmnc7q-e2-8nrc-txp+f...@mail.gm
> ail.com>, Matthew Pounsett write
> s:
> > I think this draft is useful and necessary, and that the registration of
> > ipv4only.arpa within the SUDN registry is justified by the applicability
> > statement of RFC 6761.  Having NAT64-unaware recursive servers answer
> > authoritatively as they would for other reserved names (e.g. RFC 1918
> > address reverse lookups) is a useful optimization, and having NAT64-aware
> > servers answer without querying the arpa servers removes a problematic
> > external dependency.  Furthermore, the inclusion of example.{org,com,net}
> > in RFC 6761, which are clearly less special in their technical handling
> > than ipv4only.arpa, provides further justification for ipv4only.arpa's
> > inclusion in the registry.
> No.  This requires a much more nuanced approach than "just serve
> the specified zone contents" all the time.  We need to consider
> chains of recursive servers.  We need to consider DNSSEC.

You raise some excellent points about things that could be improved in the
draft, but I don't think any of them sound like an argument for saying "No"
to including the name in the SUDN registry.  The issues you raise seem to
have simple fixes, unless I've missed something.

> Firstly the delegation of ipv4only.arpa needs to be made insecure
> before anything else can answer for it.  This is basic DNSSEC.

Agreed.  I think this could be covered in the answer to Question 6, in a
directive to the arpa zone operators.

> Secondly a recursive server MUST only answer for ipv4only.arpa if
> it is resolving the ipv4only.arpa namespace interative.  If the
> recursive server is configured to get the answers for ipv4only.arpa
> solely via another recursive server it MUST NOT be configured to
> serve ipv4only.arpa.  This allow for a recursive server to be
> configure to point to a recursive DNS64 server and the expected
> answers be returned to both the original client and all recursive
> servers in the chain.

Yes, anyone operating chained recursive servers in a DNS64 environment
should not configure them to answer for these names.  The authors could
address this with one or two sentences in the answer to Question 4... they
could even use your text above.

> Thirdly RFC 6147 just talks absolute grabage about DNSSEC and what
> CD and DO do.  There was lots of wishful thinking in the working
> group when this was written and it would not listen to reality.
> draft-cheshire-sudn-ipv4only-dot-arpa-06 would do best to stay
> absolutely silent about DNSSEC and DNS64.
> draft-cheshire-sudn-ipv4only-dot-arpa-06 also suggest that recursive
> servers respond to and
> if we agree that this needs to be done these names need to be done
> as per RFC 6303.  Currently there is no delegation for these names.

192.in-addr.arpa is delegated to ARIN's name servers, but it looks to me
like IANA is still responsible for the zone contents[1].  I don't see any
impediment to them following the directives in this draft if it were
published as an RFC, and publishing updates to the relevant zone for ARIN
to serve.

[1]: % whois | egrep '^[A-Z]'
Internet Assigned Numbers Authority SPECIAL-IPV4-REGISTRY-IANA-RESERVED
(NET-192-0-0-0-1) -
Internet Assigned Numbers Authority DS-LITE-RFC-6333-11-IANA-RESERVED
(NET-192-0-0-0-2) -
DNSOP mailing list

Reply via email to