Question from an absolute rookie
Kevin Darcy
kcd at chrysler.com
Tue Jan 12 00:03:03 UTC 2010
Rij wrote:
> Hello,
>
> I am trying to understand the behavior of bind resolver regarding a
> particular issue. Let us say a resolver A sends a query to a server B.
> If the response is too big, B will set the TC flag. Let's assume that
> the truncated portion was NOT part of the additional section since I
> believe in that case A is free to ignore.
>
> Will A now definitely open a TCP connection with B to get the full response?
>
> Or will A ignore that and try a different server?
>
I believe all resolvers which are based on BIND's resolver library will
retry the same nameserver via TCP before going to the next nameserver in
the list.
In "classical" DNS, this behavior only made sense: the only reason for
truncating is because the response is too big, but ideally you should
get the same-sized response from *any* of the nameservers you query
(disregarding "optional" contents such as certain records in the
Additional Section, as you noted) so they'll *all* presumably be
truncated. It would be rather rare for one nameserver to truncate a
response and then another nameserver in the same resolver list to give
an un-truncated response to the same query [*].
I will point out, however, that RFC 2181 only says "query again, using a
mechanism, such as a TCP connection, that will permit larger replies"
when getting a truncated response. It doesn't specify any particular
nameserver-selection algorithm. So this behavior might vary from
implementation to implementation.
- Kevin
[*] The introduction of the EDNS0 extension (see RFC 2671), which allows
clients and servers to negotiate a buffer size, deviates from the
"classical" model and raises some new hypothetical scenarios, where the
same response might be truncated from some resolvers but not others. As
a practical matter it shouldn't really change the resolver behavior;
I'll defer discussion of that unless you're really interested.
More information about the bind-users
mailing list