[dns-operations] DNS Flag Day 2020 will become effective on 2020-10-01

[Petr Špaček]

On 11. 09. 20 6:47, Paul Vixie wrote:
> Ondřej Surý wrote on 2020-09-10 21:25:
>> Paul,
>>
>> do you actually believe that shouting the same thing over and over will achieve anything?
> 
> no, of course not.
> 
>>
>> We’ve heard you before, we’ve listened to you, we’ve considered your arguments, and you haven’t convinced us and there’s a consensus between the vendors to go ahead with the change because it’s beneficial for the DNS ecosystem.
> 
> i think you changed the definition of the words "we" and "us" midsentence.

My non-native-speaker reading suggests it is in both cases refering to "consensus between the vendors". Let's not get distracted.

> 
>>
>> Sending multiple shouts to mailing lists, issue tracker, etc... because you have different opinion is not helpful to the DNS community nor to the cause. We are as much DNS experts as you are.
> 
> i don't think all of the people i intend to address here have heard my views. they may think that dns-oarc speaks for the community rather than for a small self selected team. they may also think that i as co-founder of dns-oarc can be relied upon to support this activity. so, thank you for your concern for my reputation (or my sanity, if that's also true), but i'll continue. if you wish to actually respond to any of my claims, i am listening. if you wish to continue to ignore those claims, i will cope.
> 
> this isn't a flag day and shouldn't be called that. it cheapens the term.
> 
> 1232 is a cargo-cult number. we must not revere as holy those things which fall out of the sky.

I disagree. That number is based on real-world experiance of today's DNS resolver vendors - based on their experience with un/reliability of real configurations.

Later on research https://indico.dns-oarc.net/event/36/contributions/776/attachments/754/1277/DefragDNS-Axel_Koolhaas-Tjeerd_Slokker.pdf shown that the estimate based on vendor's experience was pretty good.

> 
> there is a right way to deprecate fragmentation. it would not involve adding config complexity.

Well, this is not adding any complexity at all! It is the other way around:

a] All the configuration knobs for EDNS buffer size were already in the software, vendors are _just changing default values_ in their own software (as opposed to adding new options).

b] This effort actually enables vendors to remove code/fallback logic which attempts to guess a working EDNS buffer size, thus _reducing_ complexity of the DNS software and real-world operations.

> 
> there is a right way to reach consensus. it's an RFC draft, not a github repo for the initiated.
> 
> in the testing referenced by the "flagday2020" web page, there was no significant difference in loss between 1200 and 1400. there will be a significant difference in truncation and tcp retry.

I think readers on this list can make conclusions for themselves, there is no need to hand wave. Slides are here:
https://indico.dns-oarc.net/event/36/contributions/776/attachments/754/1277/DefragDNS-Axel_Koolhaas-Tjeerd_Slokker.pdf

Do not forget to add ethernet + IP + UDP headers to EDNS buffer size when comparing numbers from slides, i.e. 14 + 20 + 8 + 1232 = MTU 1272 B vs. MTU 1442. See slides 19 and 20 (= recursive resolvers) and do the math.

Is lowering failure rate roughly by 0.8 % for IPv4 and by 0.33 % for IPv6 significant or not?
That's matter for each DNS vendor to decide because in the end it is the vendors who have to support the software and deal with all the obscure failure reports.

-- 
Petr Špaček  @  CZ.NIC