Re: [DNSOP] Review of draft-cheshire-sudn-ipv4only-dot-arpa-06
On 28 November 2016 at 15:24, Mark Andrews wrote:
>
> In message 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 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.
>
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 192.0.0.1 | egrep '^[A-Z]'
Internet Assigned Numbers Authority SPECIAL-IPV4-REGISTRY-IANA-RESERVED
(NET-192-0-0-0-1) 192.0.0.0 - 192.0.0.255
Internet Assigned Numbers Authority DS-LITE-RFC-6333-11-IANA-RESERVED
(NET-192-0-0-0-2) 192.0.0.0 - 192.0.0.7
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-cheshire-sudn-ipv4only-dot-arpa-06
In message
, 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: +61 2 9871 4742 INTERNET: ma...@isc.org
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
