Thank you for your detailed review. I'll incorporate fixes in a new rev. Comments inline.]
- Alain.
In order to preserve name space continuity, the following administrative
policies are RECOMMENDED:
- every recursive DNS server SHOULD be either IPv4-only or dual
stack,
- every single DNS zone SHOULD be served by at least one IPv4
reachable DNS server.
This rules out IPv6-only DNS servers performing full recursion and
DNS zones served only by IPv6-only DNS servers.
==> as was noted in my comment in a related subject in v6ops earlier (just rehashing here with a different audience), this is not entirely accurate, especially with all the interpretations of "recursive DNS server". That is, it would be entirely OK to have an IPv6-only resolver point to a few IPv6-only DNS servers which would be configured to recurse from some other servers (ad infinitum) until a dual-stack recursive DNS resolver is found.
Some might say that such a dummy DNS resolver is not really recursive but a forwarder but I might disagree..
So, I think we need to both clarify the terminology and decide what exactly we want to recommend or allow. (Note, if someone deploys IPv6-only networks with "first-hop DNS resolvers", being able to deploy IPv6-only recursive servers might be beneficial.)
The problem is that DNS terminology is not very well defined anywhere. So, I suggest to add a sentence specifically talking about forwarders to clarify the point.
==> the other thing to clarify might be "dual stack". Again, if one wanted to be entirely accurate, the question is about whether the DNS server software is programmed (and enabled) for the both IP versions while the node is dual-stack. I'm not sure how important this clarification is.
In order to enforce the second point, the zone validation process SHOULD ensure that there is at least one IPv4 address record available for the name servers of any child delegations within the zone.
We could be pedantic and say: "the server software has to be dual stack, configured to listen for IPv6 traffic, on a dual stack host where IPv6 is turned on, an a network annoncing and routing Ipv6 packets to the big Internet...." I think that "dual stack" is a nice shortcut that everybody understand.
==> what is this "zone validation process"? where is it defined? where is it done (dns regisrars, dns software etc.)?
This happens in several places, software are developped for this. Before delegating a zone, numberof registrars insist on some kind of a zone check. I'm not sure there is much value in explaining this process in details.
5. Security considerations
Being a critical piece of the Internet infrastructure, the DNS is a
potential value target and thus should be protected. Great care
should be taken not to weaken the security of DNS while introducing
IPv6 operation.
The RECOMMENDED guidelines are compatible with the operation of
DNSsec and do not introduce any new security issues.
==> add something like below after the first paragraph:
Keeping the DNS name space from fragmenting is a critical thing for the availability and the operation of the Internet; this memo addresses this issue by clear and simple operational guidelines.
Ok.
BCP is the target for this document.semi-editorial --------------
Abstract
This memo provides guidelines and best common practice to operate DNS
in a mixed world of IPv4 and IPv6 transport.
==> the abstract should be longer, and include e.g. the summary of those guidelines (if possible).
==> note: is the goal for this Informational or BCP? If Info, reword to remove reference to BCP [sic].
OkToday there are only a few DNS "zones" on the public Internet that are available over IPv6 transport, and they can mostly be regarded as "experimental". However, as soon as there is a root name server available over IPv6 transport it is reasonable to expect that it will become more common to have zones served by IPv6 servers over time.
==> The " as soon as there is a root name server available over IPv6 transport" is unrelated and irrelevant in this context, for the whole purpose of this document, please remove! (transport!=data; one could add IPv6 glue in root, gtld's or cctld's before those are available over IPv6)
The RECOMMENDED approach to maintain name space continuity is to use administrative policies.
==> the curious reader now (before looking down a bit) begins to wonder, "OK, _what_ administrative policies??". Fix: s/policies./policies, as described in the next section./ :-)
ok
#---------------------------------------------------------------------- # To unsubscribe, send a message to <[EMAIL PROTECTED]>.
