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