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