[dns-operations] DNS flag day 2020: Recommended EDNS buffer size discussion

[Lee]

On 9/2/19, Paul Vixie <paul at redbarn.org> wrote:
> noting, first, that these are not "flag days" and that i object to the
> political heavy-handedness of both the fake democracy used to point the
> weapon
> and to the harsh "power words" like "flag day" used to communicate it, i'll
> go
> further:
>
> On Monday, 2 September 2019 06:52:36 UTC Jerry Lundström wrote:
>> Hi all,
>>
>> I have opened an issue that will serve as a public, open to all,
>> discussion forum for what the recommended EDNS buffer size should be for
>> DNS Flag Day 2020.
>>
>>    <https://github.com/dns-violations/dnsflagday/issues/125>
>>
> ...
>>
>> Please feel free to voice your opinion!
>
> my opinion as rendered looked like this:
>
>>  vixie commented now
>>
>> no fixed number is appropriate, any more than 512 was appropriate in DNS
>> over IPv4 UDP. EDNS BUFSIZE should be calculated exactly the same way as
>> TCP MSS, and for identical reasons. i operate networks with MTU 8192 and
>> i
>> will not thank you if you make me use TCP for DNS payloads in the size
>> range between ~1200 and the EDNS recommended default (4096). please,
>> please, please, remember the lesson of 640K in the IBM PC, and avoid
>> unneccessary hard limits.
>>
>> TCP MSS is calculated by looking at the routing table to find the
>> endpoint-specific MTU (if known) or else the interface MTU (if local) or
>> else the default route MTU (which is often 1500) and then subtracting a
>> fudge factor (40 octets for IPv4, ~300 for IPv6) to allow for transport
>> and
>> protocol headers. this is working -- TCP avoids fragmentation. this is
>> future-proof -- any network that has a larger MTU gets to use it, and any
>> endpoint-specific knowledge (such as PMTUD) is communicated to
>> fragmentation-sensitive transports like TCP, or applications like DNS,
>> via
>> the local routing table.
>>
>> we should not needlessly invent something that's different from TCP MSS.
>> just use what works.

I think tcp mss working as well as it does is because the mss is
negotiated at connection setup time (syn, syn+ack option tcp mss
size).  Your machine can figure out the mss & middle boxes that know
better can reduce the mss value to something they know will work.
  eg. 'ip tcp adjust-mss ' in ciscoland
  https://www.cisco.com/en/US/docs/ios-xml/ios/ipapp/command/ip_tcp_adjust-mss_through_ip_wccp_web-cache_accelerated.html#GUID-68044D35-A53E-42C1-A7AB-9236333DA8C4

How do you do that with udp?

Lee