Document: draft-ietf-dnsop-3901bis
Title: DNS IPv6 Transport Operational Guidelines
Reviewer: Geoff Huston
Review result: Not Ready
Not Ready
I have been assigned as the DNS Directorate reviewer of this draft.
I have identified the following issues with this draft and the I
suggest that these issues should be addressed before the draft advances
towards publication as a BCP.
Minor Nits:
1 Section 2 - Terminology : "recrusive" -> "recursive"
2 Section 3.3 - " At the time of writing" -> This reference is already 2
years old. Perhaps the document should explicitly state this as a
reference to measurements undertaken in 2023, as per the citation
Issues:
1 Section 3 is a treatise on on the pontential fragmentary pressures on a
single name space when a transport protocol-based failure to resolve a
name may result in different views of the same name space when
exclusively using one protocol or another. This section appears to this
reviewer to stray from the purpose of a BCP document, namely to provide a
description of guidelines, processes, and methods that are considered the
best engineering judgment for designing, using, and managing the
Internet. Some level of justification such processes and methods, but the
material in Section 3 goes further than a brief justification and
presents some general descriptions of DNS pathologies and remedial
configuration settings for DNS servers and resolvers. Restating at length
material from other DNS literature, including RFCs, appears to this
reviewer to wander from the intended scope and purpose of this proposed
revision to RFC3901.
2 Section 4.1 "It is usually recommended that DNS zones contain at least
two name servers, which are geographically diverse and operate under
different routing policies [IANANS]." This reference to advice from the
IANA is advice that explicitly limits itself to consideration of the root
zone, and delegations in the TLDs .int and .arpa, and does not purport to
describe a usual case. Either the text should be modified toi note the
intended limited scope of the IANA advice, or other DNS literature should
be cite to justify this claim.
3 Section 4.1: "RECOMMENDED that at least two name servers for a zone are
dual-stack name servers." There is no justification for this
recommendation, and there are clearly other ways of providing resilience
in the DNS for single-stack DNS resolvers. For example, using two
nameserve names that are accessible using IPv4-only and a further twp
nameserver names that are acessible using IPv6-only meets the same
requirement of resilience in both protocols. The reviewer suggests that
this recommendation be rewritten to address a requrement for resilience
in each protocol familty.
4. Section 4.1: "IPv4 adoption: Every DNS zone SHOULD be served by at least
one IPv4-reachable authoritative DNS server". It appears that the intent
of the RECOMMENDATION in the previous paragragh is that there is a
minimum of TWO IPv4-reachable authoritative DNS servers. Which is it?
5. Section 4.1: "Given the IPv4 address scarcity, operators 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 constraint or
limit the clients that query it. The conditional expression in this text
relating to ensuring all client c an support DNS resolution via IPv6
appears to contradict the context of the public Internet. The review
suggests that this sentence has no place in a BCP relating to the DNS on
the public internet, and should be removed.
6. Section 4.1: "To avoid reachability issues, authoritative DNS servers
SHOULD use native IPv6 addresses instead of IPv4-converted IPv6 addresses
for receiving queries." Perhaps the draft should state that authoritative
DNS servers SHOULD NOT use IPv4-Compatible IPv6 Addresses and IPv4-Mapped
IPv6 Address [RFC4291]", as the reviewer dowa not believe that "native
IPv6 addresses" is a well defined term in the IPv6 address architecture.
7. Section 4.1: "IPv6 adoption: Every DNS zone SHOULD be served by at least
one IPv6-reachable authoritative DNS server". It appears that the intent
of the RECOMMENDATION in the previous paragragh is that there is a
minimum of TWO IPv6-reachable authoritative DNS servers. Which is it?
8. Section 4.1 Avoiding IP Fragmentation: This appears to be a more concise
treatment of the material in Section 3 in the subsections "DNS-over-UDP
packets requiring fragmentation" and "DNS-over-TCP packets requiring
fragmentation". This reviewer suggests that the material in Section 3 can
be dropped in favour of this treatment in Section 4.1.
9. Section 4.2: "Every recursive DNS resolver SHOULD be dual-stack." This
is not justified in the body of the document, and as such probably
deserves further thought. Stub resolvers are encouraged to use a local
configuration that has two (or more) recursive resolvers, and in such a
scenario the stub resolver has recovery options if one of the configured
recursive resolvers is unreachable. Secondly, there still exist many
access networks in the public Internet where there is no IPv6 deployment.
In such context this recommendation for local recursive resolver to be
dual-stacked for its function of responding to the queries from the set
of local stub resolvers makes no sense. At the very least this
recommendation should be considered in respect to the
stub-resolver-facing role of a recursive resolver and the authoritative
server-facing role. If autheorativbe servers follow the recommendations
on Section 4.1 then it would appear thathere is no generic requirement
for all recursive resolvers to be dual-stacked in every instance.
10. Section 4.2: "..a configuration where it forwards queries.." Embedding
non-explicit forwarding of queries in the DNS resolution process is not
exactly an instance of Best Current Practice. The DNS has no form of
query loop detection or excessive resolver query chain detection, and
application of this practice in resolver implementations should be avoided
as a general behaviour. This reviewer suggests removing all references to
query forwarding by recursive resolvers in Section 4.2.
11. Section4.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?
12. Section 5. Security Considerations: "introduce no new security\
considerations into the DNS protocol." This reviewr 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
advice relating to resover-to-resolver forwarding in this document.
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
