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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
