One more question:
> 3. Proposal to avoid IP fragmentation in DNS
> o UDP requestors and responders SHOULD send DNS responses with
> IP_DONTFRAG / IPV6_DONTFRAG [RFC3542] options, which will yield
> either a silent timeout, or a network (ICMP) error, if the path
> MTU is exceeded. Upon a timeout, UDP requestors may retry using
> TCP or UDP, per local policy.
If the IP_DONTFRAG/IP_DF/IP_PMTUDISC_DO option is available and can be
used to set the DF flag on DNS over UDP over IPv4 PDUs, why are any of
the following maximum-size mitigations (the next 3 items after the above
quoted item) necessary?
A large response may be dropped on path, but such conditions are already
expected by resolvers; they make use of the OPT UDP payload size field
to retry to settle on a maximum size that will work with the peer.
It would be helpful to the reader to understand better, if the
requirements of "SHOULD" are annotated with the specific reasons why
that particular item is suggested. The 3 items after the above quoted
item don't specify reasons, and so it's not clear how with DF=1 set,
these items matter.
Off-topic, it appears to me that some of this overlaps with general DNS
over UDP behavior between client server, esp. a resolver vs. upstream. I
am not aware of an RFC/draft that describes in sufficient detail the
tricks (song and dance sequence) that a resolver uses to start
communications with an unknown peer and deal with UDP datagram loss on
path due to a variety of possible factors (loss due to
PMTU/fragmentation+drops, routing, EDNS0 behavior, lack of EDNS support,
etc. some of which was the topic of DNS flag day 2019). A resolver
retries with changes in how it makes its request. IP fragmentation
issues is a subset of this topic of how to communicate with a DNS peer
over UDP. You may want to consider documenting the techniques a client
could use when talking to a peer over UDP.
More generally, a modern day resolver algorithm includes nameserver
selection (SRTT-derived metric, bad peers, transport, etc.), limits on
recursion and indirection, response message processing, etc. These have
security implications and documentation is scant, of low-quality, and
scattered. Documentation for understanding of resolver<->NS
communication behavior is an often-requested item from users.
Mukund
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
