Broken PMTUD for . + TLD servers, was: Re: Smallest Transit MTU
Mark_Andrews at isc.org
Sun Jan 9 23:08:15 UTC 2005
In article <A7B004D6-6288-11D9-BA2A-000A95CD987A at muada.com> you write:
>On 5-jan-05, at 17:39, Sabri Berisha wrote:
>>> Are there any common examples of the DF bit being set on non-TCP
>> Here you go. A root-nameserver setting the DF-bit on its replies :)
>This is very bad.
>With a 296 byte MTU I don't get answers from
>(a|b|h|j).root-servers.net, *.gtld-servers.net, tld2.ultradns.net and
>some lesser-known ccTLD servers.
>I would have thought this impossible, but seeing is believing...
>Fortunately, this problem won't present itself with regular smaller
>MTUs, the MTU has to be smaller than around 500 bytes. I haven't tested
>whether these servers also suffer from the "regular" PMTUD problem
>where the ICMP messages are ignored, but I'm assuming they don't, so
>doing all of this over TCP should still work.
Well DNS (not EDNS) is limited to 512 octets so you unless there
are real links (not ones artificially constrained to demonstrate
a issue) this should not be a issue in practice. The default link
mtus for slip/ppp/ethernet are all large enought for a DNS/UDP
response to get through without needing fragmentation.
For EDNS which will send up to 4k UDP datagrams (current recommended
size) this could be a issue in that the clients would have to fall
back to DNS after timing out on the EDNS query.
EDNS response (dropped due to DF)
DNS response gets through.
Note for IPv6 one sets IPV6_USE_MIN_MTU on the UDP socket so this
should be a non-issue there.
More information about the NANOG