queries with no RD bit set are truncating

Kevin Darcy kcd at chrysler.com
Wed Jun 10 16:07:42 UTC 2009


Peter Andreev wrote:
> Good day
>
> I have met a trouble with non-recursive BIND 9.3.3, running on FreeBSD 
> 6.2-R.
> Sometimes if one of our clients sends query with no RD bit set, he 
> receives a truncated answer.
> If RD bit is set then all well.
>
> Where I should look to localise a problem?
>
By "non-recursive" do you mean that recursion is turned completely *off* 
and the response is coming from a zone for which you are authoritative 
(master or slave)? If so, I can't believe that there would be a 
difference between the responses to a RD=0 versus a RD=1 query. I'd 
suggest duplicating the problem by making the same queries manually. Run 
a sniffer trace if necessary.

My suspicion is that your "non-recursive" server isn't completely 
"non-recursive", and the RD=1 queries in question might be fetching data 
sets from remote, authoritative servers (e.g. chasing aliases), which 
happen to be smaller than the delegation sets that would be returned in 
a referral response in the RD=0 case. That would explain why the RD=0 
query truncates and the RD=1 query doesn't (because NS records are 
*necessary* in a referral response, but *optional* in other types of 
responses, unless QTYPE=NS; TC is only set when the full set of 
*necessary* records doesn't fit into the response).

If you have delegation sets that are so large that they don't fit in a 
"classic" 512-byte DNS response, then in my opinion you should probably 
review whether all of those NS records are really necessary, and prune 
the list(s) down.

In any case, why is this really an issue, except perhaps from a 
performance/capacity standpoint (which hardly seems the case since you 
said this only happens "sometimes")? The client retries via TCP, and 
almost certainly gets the full answer it was looking for. The only way 
to get truncation on a TCP query is if you hit the 64K limit, but that 
seems highly unlikely.

                                                                         
                                       - Kevin




More information about the bind-users mailing list