[dns-operations] Unexpected truncation

[Mark Andrews]

In message <20110403220737.GA57969 at DUL1MLARSON-M2.vcorp.ad.vrsn.com>, Matt Lars
on writes:
> On Sun, 03 Apr 2011, Unbitrium wrote:
> > According to the response their maximum packet size is set to 512,
> 
> Please don't conflate the maximum UDP buffer size value that a DNS
> protocol speaker advertises in messages it generates with the maximum
> size of those DNS messages that it actually sends over UDP.
> 
> The advertised UDP buffer size is the maximum size of DNS messages
> that the sender is able to receive.  The maximum size of a DNS message
> that will be sent to a given address corresponds to the UDP buffer
> size advertised in DNS messages received from that address.
> 
> The *.gtld-servers.net servers advertise a UDP buffer size of 512
> bytes.  Since these are the authoritative servers for .com and .net,
> they will only receive queries and no query approaches 512 bytes:
> typically they are an order of magnitude lower.
> 
> Put another way, just because I say that I don't want DNS messages
> bigger than 512 bytes doesn't mean that I'm not willing and able to
> send messages bigger than 512 bytes if someone says they can accept
> them.
> 
> On Sun, 03 Apr 2011, Dave Knight wrote:
> > 
> > On 2011-04-03, at 11:33 AM, George Barwood wrote:
> > 
> > > dig a.root-servers.net @a.gtld-servers.net +dnssec
> > > 
> > > is truncating, even though the response size is only 1170 bytes after TCP
>  retry.
> > > 
> > > This seems odd to me.
> > 
> > 
> > I think this is an artefact of how they are handling fragmentation of signe
> d responses
> > 
> > http://svsf40.icann.org/meetings/siliconvalley2011/presentation-verisign-up
> date-16mar11-en.pdf
> > 
> > See slide 13
> 
> That's it exactly.  In our current network design, we don't want to
> deal with IP fragments, so we take pains never to generate a DNS
> message (i.e., a response) larger than can be carried in an Ethernet
> frame.  (Obviously a datagram can fragment because of an MTU smaller
> than Ethernet size, but that ought to be highly unlikely in today's
> Internet.)
> 
> The .com/.net authoritative servers run ATLAS, our bespoke name
> server.  When assembling a response, if it looks like the response is
> going to exceed the Ethernet MTU, we stop and set the TC bit.  Because
> of complexities in the message assembly algorithm, sometimes we're
> conservative and set TC before the message is at the Ethernet MTU.
> 
> I don't know offhand why the query a.root-servers.net/IN/A sets TC;
> I'll have to check.  Note that other, larger responses are sent in
> their entirety: an example is com/IN/DNSKEY, which is 743 bytes.
> 
> Matt

Trying to avoid fragmentation is a double edged sword.  It increases
the amount of TCP traffic for the vast majority of sites that can
handle fragmented traffic.  It also doesn't make visible misconfigured
firewalls which is just pushing the fragmentation problem resolution
onto your signed customers.

> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org