In article <A7B004D6-6288-11D9-BA2A-000A95CD987A@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