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

[Mark Andrews <[e-mail]>]

In message <CAAiTEH8x3=AxGPeZos=[e-mail]>, 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.

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

> 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.
>

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]