[dns-operations] DNS flag day 2020 update

[Willem Toorop]

Op 25-03-2020 om 09:27 schreef Paul Vixie:
> On Wednesday, 25 March 2020 07:41:51 UTC Petr Špaček wrote:
>> Hello DNS operators!
>>
>> ... 
>>
>> Are you a DNS vendor, operator, firewall vendor or service provider and want
>> to improve on DNS resilience?
> 
> yes.
> 
>> Then ready our guidelines on "Message Size Considerations" for EDNS [3] to
>> reduce or even avoid fragmentation of the DNS and please allow DNS over
>> TCP!
>>
>> [3] https://dnsflagday.net/2020/#message-size-considerations
> 
> from [3]:
> 
> "An EDNS buffer size of 1232 bytes will avoid fragmentation on nearly all 
> current networks. This is based on an MTU of 1280, which is required by the 
> IPv6 specification, minus 48 bytes for the IPv6 and UDP headers."
> 
> many of us are successfully using 1400 or larger. the MTU value of 1280 that 
> this calculation is based on, was arbitrarily chosen in the IPv6 
> specification, and no real network operates with this limit. the 48 byte 
> subtrahend was arbitrarily chosen without leaving room for IP6 options. this 
> never matters for TCP because TCP knows the size of the IP6 options that will 
> be used. this in turn never matters because the internet's effective MTU is 
> ~1500.

Hi Paul,

I did measure MTU's available to resolvers on RIPE Atlas in June 2013
and presented results then at RIPE67:

https://nlnetlabs.nl/downloads/presentations/20131016-RIPE67-pmtud4dns.pdf

At that time there were 1029 RIPE Atlas probes, which combined had 863
IPv6 capable resolvers.  411 of those (51%) had MTU smaller than 1500.
115 had an MTU of 1280.  On slide 17 of the presentation you can see the
the different detected MTU's at that time.

Maybe it's worthwhile to redo those measurements again with the 16000
IPv6 capable resolvers that we can target on RIPE Atlas right now.


-- Willem

> 
> a less-arbitrary value would be better. those of us using 1400 do so because 
> we want to leave room for IP6 options as well as tunnel overhead.
> 
> please reconsider the further use of the number 1280, which was made 
> deliberately small because of the unrealistic expectation that all IP6 flows 
> would be governed by PMTUD. no real network today operates with this MTU size.
>