[dns-operations] FlagDay 2020 UDP Size
Petr Špaček
petr.spacek at nic.cz
Wed Aug 5 10:53:17 UTC 2020
On 04. 08. 20 18:26, Viktor Dukhovni wrote:
> On Mon, Aug 03, 2020 at 09:44:17PM +0100, Tony Finch wrote:
>
>> jack tavares <tavares at gmail.com> wrote:
>>>
>>> I have gone through the archives, is there consensus on this at this time?
>>> For both the date of Flag Day (Which appears to be 1st October 2020,
>>> pending confirmation from google)
>>> and for the suggested default?
>>
>> There are some interesting measurements in
>> https://rp.delaat.net/2019-2020/p78/report.pdf
>
> What I haven't seen reported is measurements of problems that occur when
> the EDNS(0) UDP buffer size is *too small*.
>
> There are lots of measurements with lost UDP datagrams when the buffer
> size is too large, but given a "too small" buffer size servers truncate
> responses, and some don't also support TCP. This causes lookup failures
> when the buffer size is sufficiently low.
You are right, and that's exactly reason why https://dnsflagday.net/2020/ web test tool focuses on TCP availability.
It is way easier to test if "TCP works for all auths for a given domain" than to test if "IP fragments can traverse all relevant paths over the Internet for all relevant answer sizes". The second option is just infeasible/madness.
Once we get TCP working we do not need to worry that too small EDNS buffer will break something, it only might make things less effective...
Of course once proponents of perfect-EDNS-buffer-size-detection-methods implement them in a resilient and scalable way we can can move on to these (at the moment hypothetical) better methods and get rid of these slight ineffectivity.
--
Petr Špaček @ CZ.NIC
More information about the dns-operations
mailing list