Document: draft-ietf-dnsop-3901bis
Title: DNS IPv6 Transport Operational Guidelines
Reviewer: Geoff Huston
Review result: Not Ready
Many of the issues raised in my previous review of this draft have been
addressed. There are, however, a number of issues which have not been
addressed and are repeated here, as they remain significant unresolved
issues, in my opinion.
1. Section 4.1, "IPv4 Adoption": "Given the IPv4 address scarcity, operator
MAY opt not to provide DNS services via IPv4, if they can ensure that all
clients expected to resolve this zone do support DNS resolution via
IPv6." In the context of the public Internet (which is the intended
context of RFC3901, and presumably the intended context of this draft
that proposes updating it), a DNS server is a promiscuous server and
SHOULD NOT assume that it can apply a constraint or otherwise limit the
clients that query it. The conditional expression in this text relating
to ensuring all client can support DNS resolution via IPv6 transport
appears to contradict the context of the public Internet. This sentence
appears to be out of place in a BCP relating to the DNS on the public
internet.
2. Section 4.1. "IPv6 adoption": "Authoritative DNS servers SHOULD use
native IPv6 addresses instead of IPv4-converted IPv6 addresses for
receiving queries." Neither RFC4291, nor RFC 6052 define a
"IPv4-converted IPv6 address." The draft should state that:
"Authoritative DNS servers SHOULD NOT use IPv4-Compatible IPv6 Addresses
and IPv4-Mapped IPv6 Address [RFC4291]".
3. Section 4.2: "..a configuration where it forwards queries.." Embedding
non-explicit forwarding of queries in the DNS resolution process is not
exactly an example of Best Current Practice. The DNS has no form of query
loop detection or excessive resolver query chain detection, and
application of this practice of query forwarding between recursive
resolvers is best avoided, as a general behaviour. I suggest that all
references to query forwarding by recursive resolvers should be removed
in Section 4.2.
4. Section 4.2: "when responding to recursive queries sent by stub DNS". How
can a recursive resolver know that a query has been sent by a stub resolver?
5. Section 5. Security Considerations: "introduce no new security
considerations into the DNS protocol." This reviewer differs with respect
to the recommendation that under certain circumstances a recursive
resolver may forward a query to another recursive resolver. As already
noted, the DNS resolution protocol has no form of query loop detection or
excessive resolver query chain detection, and there is the potential for
scenarios that can be used to launch a DOS attacks on recursive
resolvers. The authors should reconsider this section in the light of the
existing advice relating to resover-to-resolver forwarding in this document.
Also, I have seperately noted my reservation regading the inappropriate use of
Best Current Practice classification for documents that do not describe
what is understood to be current operational practice, and for completeness I am
repeating that reservation here.
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
