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

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?

share|improve this question
    
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
    
@petrus yes. - debian squeeze machine. –  Zulakis Sep 23 '12 at 20:23
    
@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
show 3 more comments

1 Answer

up vote 2 down vote accepted

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
share|improve this answer
    
same error, no additional output to what i already had. –  Zulakis Sep 23 '12 at 20:21
1  
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. –  Iain 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 4:43
add comment

Your Answer

 
discard

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.