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