Document: draft-ietf-dnsop-3901bis
Title: DNS IPv6 Transport Operational Guidelines
Reviewer: Tim Wicinski
Review result: Ready with Nits
I have been assigned as the DNS Directorate reviewer of this draft.
Ready with Nits
It appears that the -11 version does address the issues raised in the previous
DNSDIR review.
I do feel like the document is disjointed in the target audience.
For example, section 3.1 discusses all the various misconfigurations,
if the target audience is DNS Operators, I would hope a BCP would have examples
both good and bad perhaps in an appendix. Or maybe the target audience is
more advanced?
Section 4:
4.2 Guidelines for Recursive DNS Resolvers
Every recursive DNS resolver SHOULD be dual-stack.
Why not MUST? This is a BCP, It should be a MUST or should explain why it is
not?
Having zones served only by name servers reachable via one IP address
family would fragment the DNS. Hence, the need for a way to avoid
this fragmentation.
Not just fragment the DNS, but cause resolution failures. I feel referring to
it as fragmentation and not resolution failures isn't ideal. But I can't come
up with better wording.
"Avoiding IP Fragmentation"
Questions about discussion of Fragmentation. This is brought up in sections 3.2
and 4.1 and seem to be mostly aligned but reading them:
3.2 - Avoiding IP Fragmentation:
Therefore, IP fragmentation SHOULD be avoided by following
guidance on maximum DNS payload sizes [RFC9715] and providing TCP
fall back options [RFC7766]. Furthermore, similar to the guidance
in [RFC9715], authoritative DNS servers MAY set an MSS of either
1388 (analogous to [RFC9715]) or 1220 (analogous to the
[DNSFlagDay2020] suggestions) in TCP sessions carrying DNS
responses.
either 1388 or 1220....
4.1 - DNS-over-UDP packets requiring fragmentation
In general, DNS servers SHOULD follow [RFC9715], which provides
additional guidance on preventing fragmentation by ensuring that
the maximum DNS/UDP payload size does not exceed 1400 octets.
This can be accomplished by setting a corresponding EDNS(0) size,
with most implementations using a lower EDNS(0) size of 1232
octets as per the suggestions made by the [DNSFlagDay2020]
initiative, to ensure that generated packets always fit into lower
bound of the IPv6 MTU of 1280 octets, as defined in [RFC8200].
Hence, DNS servers MAY also opt to set an EDNS(0) size of 1232
octets as suggested by the [DNSFlagDay2020] initiative.
...does not exceed 1400...using a lower size of 1232 per ... or 1280 or 1232
If I was an operator looking at this, I would be wondering why the differences?
There are reasons, but they should be either be more descriptive or
combine the guidance in one place, and refer to it. This is just me.
I will not hold up the document based on this, but it feeds back to my thoughts
on the target audience.
5 Security considerations
* Two resolvers handle queries for a set of clients, each of these
resolvers support one and only one address family that is distinct
from the address family supported by the other resolver;
Should this not be "Two recursive resolvers" ? It would make sense if you are
making security considerations for authoritative servers, you should do so
separately.
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
