dig @8.8.8.8 not working

Question

I was wondering what could be the reason that

dig @8.8.8.8 stackoverflow.com

fails with a

;; connection timed out; no servers could be reached

error.

A tracert -p 53 8.8.8.8 worked fine, I allowed the port in our firewall.

How can I find out until which points the packets come?

Are you allowing both inbound and outbound DNS packets (UDP port 53) on your firewall? — growse, Sep 23 '12 at 20:13
What OS are you using? `tracert` doesn't seem to have a `-p` switch. Are the two commands executed on the same machine? — petrus, Sep 23 '12 at 20:21
@growse The problem is that I don't really know if it fails on the machine itself (maybe iptables? they are really large so I am not really sure) or on the firewall. I am looking for a method how I can check how for the packets come. — Zulakis, Sep 23 '12 at 20:24
@Zulakis: I don't have `tracert` on my debian. Are you sure that the `-p` switch set the port and it uses UDP? — petrus, Sep 23 '12 at 20:26
There is not `tracert` on Debian. Please show the complete command line you used, as well as its output. — daff, Sep 23 '12 at 20:33
traceroute debian package version 2.0.11. -p is port according to manual. — Zulakis, Sep 23 '12 at 20:37
Have you tried 8.8.4.4 or one of the OpenDNS servers to see if it's something specifically with 8.8.8.8? — DerfK, Sep 23 '12 at 20:43

user9517 · Accepted Answer · 2012-09-23T20:45:37.297

I just added a rule to my local iptables to block outgoing UDP packet on port 53 and I get the same error as you. I then removed this rule and blocked the port on my firewall and I got the same result again which is expected.

To answer your question, you need to use your network and system administration skills to work out the route that packets traverse through your network and then check the relevant iptables/firewall rules on each router/host to figure out which one is blocking your requests.

I don't think there is a shortcut to doing this.

use the +trace flag

+[no]trace Toggle tracing of the delegation path from the root name servers for the name being looked up. Tracing is disabled by default. When tracing is enabled, dig makes iterative queries to resolve the name being looked up. It will follow referrals from the root servers, showing the answer from each server that was used to resolve the lookup.

dig +trace  @8.8.8.8 stackoverflow.com


; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.1 <<>> +trace @8.8.8.8 stackoverflow.com
; (1 server found)
;; global options:  printcmd
.                       24299   IN      NS      a.root-servers.net.
.                       24299   IN      NS      b.root-servers.net.
.                       24299   IN      NS      c.root-servers.net.
.                       24299   IN      NS      d.root-servers.net.
.                       24299   IN      NS      e.root-servers.net.
.                       24299   IN      NS      f.root-servers.net.
.                       24299   IN      NS      g.root-servers.net.
.                       24299   IN      NS      h.root-servers.net.
.                       24299   IN      NS      i.root-servers.net.
.                       24299   IN      NS      j.root-servers.net.
.                       24299   IN      NS      k.root-servers.net.
.                       24299   IN      NS      l.root-servers.net.
.                       24299   IN      NS      m.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 35 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
;; Received 507 bytes from 198.41.0.4#53(a.root-servers.net) in 351 ms

stackoverflow.com.      172800  IN      NS      ns1.serverfault.com.
stackoverflow.com.      172800  IN      NS      ns2.serverfault.com.
stackoverflow.com.      172800  IN      NS      ns3.serverfault.com.
;; Received 149 bytes from 192.5.6.30#53(a.gtld-servers.net) in 184 ms

stackoverflow.com.      3600    IN      A       64.34.119.12
stackoverflow.com.      3600    IN      NS      ns3.serverfault.com.
stackoverflow.com.      3600    IN      NS      ns1.serverfault.com.
stackoverflow.com.      3600    IN      NS      ns2.serverfault.com.
;; Received 165 bytes from 64.34.119.33#53(ns1.serverfault.com) in 102 ms

Since he's specifying a server with `@` I don't think `+trace` will produce anything useful since he's not using the normal recursion process. — DerfK, Sep 23 '12 at 20:42
@DerK: The output from dig +trace @... and dig +trace ... looks pretty much the same to me. — user9517, Sep 23 '12 at 20:55
Ahh, I got it. There are several network interfaces in the machine and I expected it to use another one, which I actually already allowed in the firewall. Thanks anyways. — Zulakis, Sep 24 '12 at 04:43

dig @8.8.8.8 not working

1 Answers1