copying the question section

Brian Wellington Brian.Wellington at
Sat Aug 3 21:06:21 UTC 2002

On Sat, 3 Aug 2002, Paul Vixie wrote:

> bind has always copied the question section into the response.  some versions
> (notably the ill-fated 4.9.2) demanded to see this, but earlier and current
> versions only demand that the question section in the response match the one
> from the query if it's present at all -- an empty question section in a
> response is not treated as an error.  some non-bind servers have been sending
> back empty question sections for years now and it's been seen to cause no
> trouble.
> for the root name servers, copying the question into the response limits the
> total amount of space in the 512-octet (pre-EDNS) payload for the answer,
> authority, and additional sections.  since it's optional in the protocol,
> it counts as a waste if it causes the TC bit to be set ("truncation occurred")
> and a TCP retry to be done.
> we could simply stop copying the question section at all.  (loses information.)
> or we could make it an obscure configuration option.  (one of many, it seems.)
> or we could try an adaptive strategy: if truncation occurs while building a
> response, then try it again with an empty question section, and if truncation
> still occurs, then give up and set the TC bit.
> i'm in favour of that last approach.  anybody else got strong views on it?

In the positive response case, the name in the question section will
almost always cause a later name to be compressed, I'd estimate that in
the average case, omitting the question would save 6 bytes.  (a compressed
name, type, and class).  In the referral or nxdomain response, there won't
be a later name matching the qname exactly, but I still wouldn't expect a
savings of more than 20 bytes or so.

This would likely break some clients, so it shouldn't be done without the
client using EDNS (or some other mechanism) to indicate that it won't
break, and if it uses EDNS, it can already handle a much larger UDP

Are there that many messages that are in the 513-550 byte range that 
this would make a difference?


More information about the bind-workers mailing list