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

[Paul Vixie]

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.

-- 
Paul