queries with no RD bit set are truncating

[Peter Andreev]

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
> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20090611/cb6792a7/attachment.html>