Thank you for answer, Kevin.<br><br>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.<br>
<br>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.<br><br><br><div class="gmail_quote">2009/6/10 Kevin Darcy <span dir="ltr"><<a href="mailto:kcd@chrysler.com" target="_blank">kcd@chrysler.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
</blockquote></div></div>
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.<br>


<br>
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).<br>


<br>
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.<br>


<br>
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.<br>


<br>
                                                                                                              - Kevin<br>
<br>
_______________________________________________<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div><br>