[dns-operations] Unexpected truncation

[Matt Larson]

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 signed responses
> 
> http://svsf40.icann.org/meetings/siliconvalley2011/presentation-verisign-update-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