Subject: [DNSOP] Review of draft-cheshire-sudn-ipv4only-dot-arpa-06

From: Matthew Pounsett <[email-masked]>
Date: Mon, 28 Nov 2016 12:21:31 -0500

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.

I have one comment and one question on the specifics of the reservations
considerations sections:

The answers to question 5 for both reservation considerations sections seem
to mix developer and operational considerations for authoritative servers.
It's my understanding that operational considerations should be handled
under question 6 .. and in both cases they mostly are.   Removing the
duplicate instructions, and moving the remaining operational notes to
question 6 would simplify the text.  I'm happy to provide suggested text if
that's useful to the authors.

Have the authors considered including RFC2119 language in the answers to
question 6 directing the operators of the arpa and in-addr.arpa zones to
configure their name servers to answer for these special names?  e.g.
"Operators of the arpa zone MUST configure their servers to answer for
ipv4only.arpa as defined in RFC7050." .. and a similar statement for the
reverse lookups.

Although I lean slightly in favour of including such text, I don't have a
strong opinion either way.  The draft indicates an expectation that the
operators of arpa and in-addr.arpa will configure their servers as
requested, but for completeness and strict conformance to 6761 it might be
useful to be more explicit.  On the other hand, the IAB statement in 7050 §
8.3 could be read to be that directive.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 29 Nov 2016 07:24:55 +1100

In message <CAAiTEH8x3=AxGPeZos=[email-masked]>, Matthew Pounsett write
> 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.

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

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.

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 170.0.0.192.in-addr.arpa and 171.0.0.192.in-addr.arpa
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.

Mark

> useful to be more explicit.  On the other hand, the IAB statement in 7050
> § 8.3 could be read to be that directive.
>

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]