<div><div dir="auto">Hi,</div></div><div dir="auto"><br></div><div dir="auto">Just to add to that, I’ve been working with Azure recently and they warn that any packets over 1400 bytes will be fragmented, which seems crazy, but there it is.</div><div dir="auto"><br></div><div dir="auto">IMHO It doesn’t seems unreasonable though to aim to support networks that the majority use and to let broken networks be broken.</div><div dir="auto"><br></div><div dir="auto">Daniel</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 21 Apr 2020 at 8:27 AM, Petr Špaček <<a href="mailto:petr.spacek@nic.cz">petr.spacek@nic.cz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 20. 04. 20 22:22, Viktor Dukhovni wrote:<br>
> On Mon, Apr 20, 2020 at 12:52:49PM -0700, Brian Somers wrote:<br>
> <br>
>> On Apr 18, 2020, at 9:39 PM, Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org" target="_blank">ietf-dane@dukhovni.org</a>> wrote:<br>
>>> Is there any new information on whether something closer to 1400 is<br>
>>> generally safe also for IPv6?<br>
>><br>
>> At Cisco we allow up to 1410 bytes upstream and drop fragments.  We prefer IPv6<br>
>> addresses when talking to authorities.  We’ve been doing this for years (except for<br>
>> a period between Feb 2019 and Aug 2019).  Zero customer complaints.<br>
> <br>
> So perhaps the advice to default to 1232 should be revised:<br>
> <br>
>     <a href="https://dnsflagday.net/2020/#dns-flag-day-2020" rel="noreferrer" target="_blank">https://dnsflagday.net/2020/#dns-flag-day-2020</a><br>
> <br>
> I see some movement in that direction, with the recommendation of 1220<br>
> in:<br>
> <br>
>     <a href="https://tools.ietf.org/html/draft-fujiwara-dnsop-avoid-fragmentation-00#section-3" rel="noreferrer" target="_blank">https://tools.ietf.org/html/draft-fujiwara-dnsop-avoid-fragmentation-00#section-3</a><br>
> <br>
>        o  Full-service resolvers SHOULD set EDNS0 requestor's UDP payload<br>
>           size to 1220.  (defined in [RFC4035] as minimum payload size)<br>
> <br>
>        o  Authoritative servers and full-service resolvers SHOULD choose<br>
>           EDNS0 responder's maximum payload size to 1220 (defined in<br>
>           [RFC4035] as minimum payload size)<br>
> <br>
> revised in -01/-02 to:<br>
> <br>
>     <a href="https://tools.ietf.org/html/draft-fujiwara-dnsop-avoid-fragmentation-02#section-4" rel="noreferrer" target="_blank">https://tools.ietf.org/html/draft-fujiwara-dnsop-avoid-fragmentation-02#section-4</a><br>
> <br>
>        o  [RFC4035] defines that "A security-aware name server MUST support<br>
>           the EDNS0 message size extension, MUST support a message size of<br>
>           at least 1220 octets".  Then, the smallest number of the maximum<br>
>           DNS/UDP payload size is 1220.<br>
> <br>
>        o  However, in practice, the smallest MTU witnessed in the<br>
>           operational DNS community is 1500 octets.  The estimated size of a<br>
>           DNS message's UDP headers, IP headers, IP options, and one or more<br>
>           set of tunnel, IP-in-IP, VLAN, and virtual circuit headers, SHOULD<br>
>           be 100 octets.  Then, the maximum DNS/UDP payload size may be<br>
>           1400.<br>
> <br>
> While <a href="http://darpa.mil" rel="noreferrer" target="_blank">darpa.mil</a> still need to enable TCP, a more generous buffer size<br>
> that avoids IPv6 issues will also avoid unnecessary and potentially even<br>
> unavailable TCP fallback.  So I'm in favour of 1400 or 1410 (do we need<br>
> more empirical evidence from other vantage points?) assuming those are<br>
> also safe.<br>
> <br>
> If the IPv6 obstacles are typically closer to the resolver than the<br>
> authoritative server, just Cisco's experience may not be enough to make<br>
> a definite conclusion.<br>
<br>
Please let's not jump to conclusions, especially because of single anecdote.<br>
<br>
As Knot Resolver developer I counter with another anecdote:<br>
We have experience with networks where ~ 1300 buffer was workable minimum and 1400 was already too much.<br>
<br>
As for OpenDNS experience - I'm hesistant to generalize. According to<br>
<a href="https://indico.dns-oarc.net/event/33/contributions/751/attachments/724/1228/20200201_DNSSEC_Recursive_Resolution_From_the_Ground_Up.pptx" rel="noreferrer" target="_blank">https://indico.dns-oarc.net/event/33/contributions/751/attachments/724/1228/20200201_DNSSEC_Recursive_Resolution_From_the_Ground_Up.pptx</a><br>
DO bit is sent out only since Sep'2018, and presumably from resolvers in data centers. <br>
<br>
Results would be very different for recursive resolver deployment deep in corporate networks/on the last mile.<br>
<br>
DNS-over-TCP is mandatory to implement so please let's stop working it around.<br>
<br>
-- <br>
Petr Špaček  @  CZ.NIC<br>
_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net" target="_blank">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Sent from Mobile Command</div>