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

["Alexei Roudnev" <alex () relcom net>]

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 () isc org>
To: <nanog () 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 () 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