Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a DNS server that resolves all queries for an internal group of servers. It is a bind on CentOS 5.5 (same as RHEL5) and I have set it up to allow recursion and resolve direction without any forwarders.

The problem I am facing is that it takes a freakishly long amount of time to resolve a name for the first time. (in the magnitudes of 20 sec) This causes clients to give timeout.

When I set it to forward all to Google's public DNS, i.e., it works very nicely (within a second).

I tried monitoring the traffic on the net to see why it is doing this:

[root@ns1 ~]# tcpdump -nnvvvA -s0 udp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
23:06:36.137797 IP (tos 0x0, ttl  64, id 35903, offset 0, flags [none], proto: UDP (17), length: 60) > [udp sum ok]  19773+ A? (32)
23:06:36.140594 IP (tos 0x0, ttl  64, id 56477, offset 0, flags [none], proto: UDP (17), length: 71) > [udp sum ok]  10105 [1au] A? ar: . OPT UDPsize=4096 (43)
23:06:38.149756 IP (tos 0x0, ttl  64, id 13078, offset 0, flags [none], proto: UDP (17), length: 71) > [udp sum ok]  54892 [1au] A? ar: . OPT UDPsize=4096 (43)
23:06:40.159725 IP (tos 0x0, ttl  64, id 43016, offset 0, flags [none], proto: UDP (17), length: 71) > [udp sum ok]  11205 [1au] A? ar: . OPT UDPsize=4096 (43)
23:06:41.141403 IP (tos 0x0, ttl  64, id 35904, offset 0, flags [none], proto: UDP (17), length: 60) > [udp sum ok]  19773+ A? (32)
23:06:42.169652 IP (tos 0x0, ttl  64, id 44001, offset 0, flags [none], proto: UDP (17), length: 60) > [udp sum ok]  1184 A? (32)
23:06:42.207295 IP (tos 0x0, ttl  54, id 38004, offset 0, flags [none], proto: UDP (17), length: 205) > [udp sum ok]  1184- q: A? 0/3/3 ns: NS, NS, NS ar: AAAA 2001:470:1a::1, A, A (177)
E....t..6./,.......... ..p.............,..........H4G..I..........&g..
(this goes on for a few more seconds)

If you look carefully, you will see that the first 3-4 root servers did not respond at all. This wastes 7-8 seconds, until one of them responded.

Do you think I have setup something wrong here? Interestingly, when I dig directly from the root servers that did not respond, the always respond very fast (showing the firewall/nat is not the issue here). E.g.

dig @

works perfectly, consistently, and very fast. What do you think about this mystery?

share|improve this question
up vote 3 down vote accepted

I strongly suspect that you have a broken firewall between the DNS server and Internet that drops long DNS responses that are normal with DNSSEC. Try running dig with "+dnssec" option and see if it starts timing out too.

Cisco PIX/ASAs, up until very recent versions, are known to behave like this by default:

share|improve this answer
Bingo! +dnssec causes dig to timetout. Time to go poke at the firewall. You are awesome!! – Ehsan Mar 9 '11 at 14:39

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.