Broken PMTUD for . + TLD servers, was: Re: Smallest Transit MTU

Mark Andrews 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
>>> packets?
>
>[...]
>
>> 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.

	e.g.
		EDNS query
		EDNS response (dropped due to DF)
		timeout
		DNS query
		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.

	Mark



More information about the NANOG mailing list