Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

If I try to query a root server with dig, I never receive an answer.

For example the output for dig @b.root-servers.net www.ubuntu.com is

; <<>> DiG 9.8.1-P1 <<>> @b.root-servers.net www.ubuntu.com

; (1 server found)

;; global options: +cmd

;; connection timed out; no servers could be reached

But if I query other servers (the one of my ISP, or, they answer correctly. Why?

P.S. Using Wireshark I can see the outgoing queries to the right IP address of the root-server, but there aren't incoming packets from the same IP.

share|improve this question
And what happens when you query other root servers ? –  Sandman4 Nov 19 '12 at 11:14
If I query an other root-server, it doesn't work. I've the same output. But if I query (for example) I've the correct answer. –  JustTrying Nov 21 '12 at 9:35
And if you specify root server IP instead of domain name ? –  Sandman4 Nov 21 '12 at 12:01
For the first time I tried to dig to a root-server from my home network (when I asked the question I was at university) and it works. Probably the university network's firewall blocks the direct queries to a root-server and permits queries only to the internal DNS server. Is it possible? –  JustTrying Nov 21 '12 at 13:52
At uni, they probably view Google as a trusted DNS. You'll probably be able to hit OpenDNS as well. Basically, it limits DNS traffic per whatever their internal traffic policy is, one being that Google DNS and OpenDNS both try to suppress phishing, malware sites, cache poisoning, etc. –  Fiasco Labs Jan 13 '13 at 7:42

2 Answers 2

up vote 1 down vote accepted

Sounds like your internet provider must blocking access to the root name servers. They obviously don't block access to their own resolvers, and they probably exempt a couple of other popular external resolvers like Google Public DNS, but might block all domain-port access otherwise.

Is this common? It depends. I think it's relatively common for such blocks to be present on university and corporate networks, but I would say it's not supposed to be a particularly common occurrence with regular residential providers. (Most providers do block outgoing smtp-port, however.)

Why would anyone block external nameservers? This has probably to do with various man-in-the-middle attacks that are possible if legitimate nameservers are substituted for compromised ones. To avoid any such attacks and to reduce user complaints, most providers usually redirect all domain-port requests to their own servers: when they do so, you can't run your own recursive server anymore or do dig +trace troubleshooting, but at least you wouldn't have to change your DNS settings otherwise.

Anyhow, indeed there is nothing wrong with your command itself: you're supposed to receive a reply as below, which would make it possible for you to make another request on the manual recursive path to the resolution of the given name.

# dig @b.root-servers.net www.ubuntu.com

; <<>> DiG 9.7.3 <<>> @b.root-servers.net www.ubuntu.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20828
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14
;; WARNING: recursion requested but not available

;www.ubuntu.com.                        IN      A

com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.

a.gtld-servers.net.     172800  IN      A
b.gtld-servers.net.     172800  IN      A
c.gtld-servers.net.     172800  IN      A
d.gtld-servers.net.     172800  IN      A
e.gtld-servers.net.     172800  IN      A
f.gtld-servers.net.     172800  IN      A
g.gtld-servers.net.     172800  IN      A
h.gtld-servers.net.     172800  IN      A
i.gtld-servers.net.     172800  IN      A
j.gtld-servers.net.     172800  IN      A
k.gtld-servers.net.     172800  IN      A
l.gtld-servers.net.     172800  IN      A
m.gtld-servers.net.     172800  IN      A
a.gtld-servers.net.     172800  IN      AAAA    2001:503:a83e::2:30

;; Query time: 12 msec
;; WHEN: Sat Jan 12 22:52:12 2013
;; MSG SIZE  rcvd: 492
share|improve this answer

The root servers should answer your question for a dig with a reply to where you may find .com. the reason b.root-servers.net is not answering might be that your root hints file is out of date. Try updating this file.

share|improve this answer
The latest up to date root hints can be found at internic.net/domain/named.root –  James Park-Watt Nov 19 '12 at 10:37
I checked and the root hints file was updated. Anyway I update it again just to be sure. In spite of everything, dig @b.root-servers.net www.ubuntu.com still doesn't work (and it doesn't work even if I use any other root-server). –  JustTrying Nov 21 '12 at 9:30

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.