1

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 8.8.8.8), 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.

7
  • And what happens when you query other root servers ?
    – Sandman4
    Nov 19, 2012 at 11:14
  • If I query an other root-server, it doesn't work. I've the same output. But if I query 8.8.8.8 (for example) I've the correct answer.
    – JustTrying
    Nov 21, 2012 at 9:35
  • And if you specify root server IP instead of domain name ?
    – Sandman4
    Nov 21, 2012 at 12:01
  • 1
    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, 2012 at 13:52
  • 1
    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. Jan 13, 2013 at 7:42

2 Answers 2

4

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

;; QUESTION SECTION:
;www.ubuntu.com.                        IN      A

;; AUTHORITY SECTION:
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.

;; ADDITIONAL SECTION:
a.gtld-servers.net.     172800  IN      A       192.5.6.30
b.gtld-servers.net.     172800  IN      A       192.33.14.30
c.gtld-servers.net.     172800  IN      A       192.26.92.30
d.gtld-servers.net.     172800  IN      A       192.31.80.30
e.gtld-servers.net.     172800  IN      A       192.12.94.30
f.gtld-servers.net.     172800  IN      A       192.35.51.30
g.gtld-servers.net.     172800  IN      A       192.42.93.30
h.gtld-servers.net.     172800  IN      A       192.54.112.30
i.gtld-servers.net.     172800  IN      A       192.43.172.30
j.gtld-servers.net.     172800  IN      A       192.48.79.30
k.gtld-servers.net.     172800  IN      A       192.52.178.30
l.gtld-servers.net.     172800  IN      A       192.41.162.30
m.gtld-servers.net.     172800  IN      A       192.55.83.30
a.gtld-servers.net.     172800  IN      AAAA    2001:503:a83e::2:30

;; Query time: 12 msec
;; SERVER: 192.228.79.201#53(192.228.79.201)
;; WHEN: Sat Jan 12 22:52:12 2013
;; MSG SIZE  rcvd: 492
2

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.

2
  • The latest up to date root hints can be found at internic.net/domain/named.root Nov 19, 2012 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, 2012 at 9:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .