Re: [DNSOP] default value of draft-ietf-dnsop-avoid-fragmentation

[Jim Reid <[e-mail]>]

> On 15 Mar 2021, at 04:16, [e-mail] wrote:
> 
> Dear DNSOP participants,
> 
> Thanks very much for good comments for draft-ietf-dnsop-avoid-fragmentation.
> 
> These are my proposal of Section 3.3.  Default Maximum DNS/UDP payload size.
> 
> I'm not sure what to do with "MAY, "SHOULD", or "MUST",
> so please give us your opinion.

Fujiwara-san, “resolvers MAY use PMTU” is probably right. A SHOULD or a MUST seems too strong: for instance when the resolver already has a priori knowledge of the MTU or that’s somehow hard-wired into the link-layer technology end-to-end.

>   However, operators of DNS servers SHOULD measure their path MTU to
>   well-known locations on the Internet, such as [a-m].root-servers.net
>   or [a-m].gtld-servers.net at setting up the servers.

I think it would be better to replace this with “Operators of DNS servers MAY measure their path MTU.”.

Measuring the MTU to well-known locations on the Internet won’t be appropriate for some use cases. For instance inside private nets that aren’t connected to the Internet or for forwarding-only servers that never query an authoritatve server.

IMO it’s a bad idea to recommend specific servers that could be the target for those PMTU probes. [Suppose those names change one day - unlikely for the above but you never know.] That could become a vector of (D)DoS attacks - probably not on the above name servers themselves but on the access routers in front of them that might well be rate-limiting ICMP packets. This could get nasty with icky CPE firmware: imagine every home router in (say) Comcast’s net doing PMTU to the same root server. Besides, is the PMTU to a root or .com server, going to be the same as that for the example.whatever name servers?

If PMTU is to be used, maybe it needs to be applied to all authoritative name servers a resolver queries? And maybe these will need to be re-probed from time to time, just like how resolving servers continually monitor RTTs to authoritative servers. PMTUs might well change when the links and routes change.

I think it would also be helpful to discuss some of the trade-offs of using PMTU for DNS resolution. Some of these are mentioned in RFC8899. I’m sure PMTU will unquestionably be the right thing to do in some settings. But in others, it could cause more operational trouble than fragmented DNS packets: increased latency for example. It would be great if the ID helped developers and operators to make informed choices on when to use or not use PMTU.