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