On Apr 6, 2014, at 7:06 AM, Stephane Bortzmeyer <bortzme...@nic.fr> wrote: > > Second issue, the pessimistic tone. The draft could be read as a > warning that horrible things will happen if the size of the answer is > not kept well below 512 bytes. But, since the version -00 has been > published, typical response sizes have increased and nothing > happened. The respsize.pl tool flags .com as always red, for maximum > size queries. But we observe daily that .com works.
To add to this: The horribles when they do occur occur not at 512b but at ~1400B, when things start fragmenting, as far too many devices (and its worse on IPv6) have decreed that fragments don't work. This also means that the recursive resolver, unless its doing raw packet reception, does not know that this is the problem source. Yet even in this case, its only a few (single-digit-percent) of recursive resolvers affected (its more when you include the path to the clients). My belief is that EDNS0 fallback (like what BIND does) should be to use an MTU of 1400B and then 1200B first (which guarantees no fragmentation on IPv6, even in the face of tunnels, and a practical guarantee of no fragments on IPv4), rather than skipping directly down to EDNS with an MTU of 512B, and if multiple authority servers require this fallback, the recursive resolver should use this MTU for all authorities, and just accept the minor latency hit incurred in having to shift to TCP more in the very rare case -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
