queries with no RD bit set are truncating
andreev.peter at gmail.com
Thu Jun 11 10:02:08 UTC 2009
Thank you for answer, Kevin.
Yes, recursion completely *off* by "recursion no;" option. And only my
servers are authoritative for client's zone. So I'm in confusion, because as
you said, for servers should not have a difference between RD=0 and RD=1.
I'm afraid that there are reasons for such strange behaviour that are hidden
from me. I'm worry that this reasons can become an unevident source of
problems in the future.
2009/6/10 Kevin Darcy <kcd at chrysler.com>
> 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
> 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
> 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
> - Kevin
> bind-users mailing list
> bind-users at lists.isc.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bind-users