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
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
