Broken PMTUD for . + TLD servers, was: Re: Smallest Transit MTU
alex at relcom.net
Mon Jan 10 07:59:58 UTC 2005
I receive DNS responses > 500 bytes every day (reported by PIX firewall). So
it is an issue, no matter wgat is recomended in RFC.
----- Original Message -----
From: "Mark Andrews" <Mark_Andrews at isc.org>
To: <nanog at merit.edu>
Sent: Sunday, January 09, 2005 3:08 PM
Subject: Re: Broken PMTUD for . + TLD servers, was: Re: Smallest Transit MTU
> 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.
> EDNS query
> EDNS response (dropped due to DF)
> 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.
More information about the NANOG