Bind 9.4.2 not resolving one domain
Chris Buxton
cbuxton at menandmice.com
Thu Sep 4 18:44:48 UTC 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sep 4, 2008, at 10:58 AM, caio wrote:
> Chris Buxton escribió:
>> I would be more inclined to suspect network connectivity problems
>> with
>> the lookup you're having problems with. With that many lookups,
>> each one
>> needs to complete in a reasonable amount of time - 50 ms on
>> average, or
>> thereabouts, to complete the whole thing in 5 seconds. How is your
>> connection to the various servers involved?
>
> do not know if a connectivity problem, because i have 2 name
> servers, at
> the same network level hierarchy (but differents subnet).., and maybe
> there is one working ok while the other with failure..
>
> here the case of the secondary ns...(at this moment):
>
> # dig @dns2.mydomain.com www.yahoo.com.ar +trace
[...]
> And without "+trace" argument:
>
> # dig @dns2.mydomain.com www.yahoo.com.ar
>
> ; <<>> DiG 9.4.2 <<>> @dns2.mydomain.com www.yahoo.com.ar
> ; (1 server found)
> ;; global options: printcmd
> ;; connection timed out; no servers could be reached
>
> Why with 'trace' the query seem to finish, and without 'trace' it
> fails?
The "+trace" option causes dig to behave quite differently than
without. With "+trace", you're not really asking your server anything
other than for a list of root servers. Then 'dig' does all the work of
recursion.
More interesting would be to repeat your previous query with "+norec"
added, in parallel with the recursive query. Or better yet, configure
logging so that we can see what's going on - but this can be hard with
a busy server.
The fact that you previously indicated that retrying the query a few
seconds later yields an answer tells me that this is some kind of
performance problem, most likely in network latency (as Kevin Darcy
originally suggested). Looking at the trace, which doesn't show
everything (and also terminates at the first CNAME record), I can see
some pretty slow response times - the response from the root server is
over 400 ms. Of course, your resolving name server most likely has
some of this already in cache, including good working RTT values for
the root and .com servers, among others. Therefore, it's likely that
your server is completing the recursion process in something like 6
seconds, just a bit over dig's 5 second timeout. Try this:
dig @dns2.mydomain.com www.yahoo.com.ar +time=20
What is the result? You might do something like this for a real test:
rndc flush
# wait 10 seconds
dig @dns2.mydomain.com www.yahoo.com.ar +time=20
Chris Buxton
Professional Services
Men & Mice
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkjALKAACgkQ0p/8Jp6Boi3L2QCeNLgFfhIiJjGaFoBe5dfT9RJV
bigAn0N932nkJIFrG1qlgQiKOvycz8nC
=1ouR
-----END PGP SIGNATURE-----
More information about the bind-users
mailing list