-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sep 4, 2008, at 12:23 PM, caio wrote: > and here the result of: > > # rndc flush > # (10 secs) > # dig @dns2.mydomain.com www.yahoo.com.ar +time=20 [...] > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36748 That's interesting. So it's maybe not just a simple performance problem (a generally slow link to somewhere). I notice also that the SERVFAIL response was returned after almost 20 seconds. > And after 2 minutes, I threw 2 parallels dig (with +norec, and > rec)..., and I do not know how can I explain it.., but both returns > successfull results.., but with differents query times... That's perfectly normal. The recursive query has to wait for the server to finish looking up the data, which in this case took a reasonable amount of time (174 ms). The nonrecursive query only returns what is in cache, which returns in 0 ms (after rounding). > If everything goes 'normally' the primary name server in a while > will start to fails, and the secondary name server will keep > resolving well.. That's interesting. It sounds like you're seeing intermittent, but relatively frequent, outages to one set of authoritative name servers or another that need to be queried to look up the name. named will wait for several seconds for a response from an authoritative name server, although after a short delay it will start querying the other name servers in that set. This can therefore mean several parallel queries outstanding. I believe the timeout for any outbound query is 5 seconds, although I could easily be wrong. The fact that you got a SERVFAIL after almost 20 seconds means that several steps (probably at least 3) in the chain were slow, and one step was very slow - too slow for named's patience. You should run a packet sniffer on the server, or on a monitoring port of a switch that outbound queries would traverse, and keep trying until you get another such SERVFAIL. Then examine the packet log to see what remote servers are not answering. Something like dnscap would probably be ideal for this, although presently the dns-oarc.net server is down. When the website is working, you can find info here: https://www.dns-oarc.net/tools/dnscap More generally, a solution that can graph query response times and failed queries might be interesting to you. For example, Men & Mice makes a commercial solution for this, the Men & Mice DNS Performance Monitor. Contact me off-list if you are interested. Chris Buxton Professional Services Men & Mice -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjAVaMACgkQ0p/8Jp6Boi14lQCfeLoj3BM/MnJOl/2ncLaPwr/v UCIAoIynq1DCuPTinVY/1vPjLR6aphZH =Kdo6 -----END PGP SIGNATURE-----
