dns 8.8.8.8 timed out

2,578 views
Skip to first unread message

Ricardo Contreras

unread,
Sep 2, 2016, 8:30:38 AM9/2/16
to public-dns-discuss
traceroute -n -w 2 -q 2 -m 30 8.8.8.8

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  146.83.2.1  0.464 ms  0.245 ms
 2  146.83.247.77  1.051 ms  0.937 ms
 3  200.91.0.213  0.825 ms  0.844 ms
 4  10.200.247.70  1.254 ms  1.152 ms
 5  186.148.61.126  1.842 ms  1.743 ms
 6  72.14.194.223  132.004 ms  131.898 ms
 7  209.85.251.45  129.235 ms 209.85.242.193  127.662 ms
 8  * *
 9  * *
10  * *
11  * *
12  * *

Alex Dupuy

unread,
Sep 2, 2016, 2:40:02 PM9/2/16
to public-dns-discuss
Hi Ricardo,

For the record,  the last IP responding seems to be in SCL (Chile).

That said, Google Public DNS is a Domain Name System service, not an ICMP network testing service.

While Google does not block ICMP or random UDP to 8.8.8.8 or other Google Public DNS IP addresses, there are rate limits on ICMP error replies from Google networking equipment, and ICMP error replies are de-prioritized within Google networks and are thus more likely to be dropped. Even a complete lack of response to traceroute after a certain point may be related to ICMP handling by firewalls and not reflect any sort of issue with DNS.

For these reasons, ping and traceroute drops are not evidence *by themselves* of a problem with your connectivity to Google Public DNS, and do not reflect the quality of service that your DNS queries are receiving. You need to provide some indication that your DNS service is not working in some way; ideally this would be dig results for 8.8.8.8 and 8.8.4.4, but nslookup is also acceptable.

If there is a real networking problem (high latencies or large numbers of drops) traceroute may be useful to diagnose and understand the source or nature of the problem, see http://www.inmotionhosting.com/support/website/how-to/read-traceroute for more details, including examples of non-problems. Furthermore, if you *are* having a networking issue with your connection to Google, the DNS engineers you are reaching through this issue tracker are not able to do anything about it. You need to contact the Google networking teams through the ISP portal at isp.google.com or by escalating through your upstream ISP if you do not have a peering or GGC (https://isp.google.com/iwantggc/) relationship with Google yourself.

If you want to measure the quality of your DNS service from Google Public DNS, you can use a dnsping tool (https://github.com/farrokhi/dnsdiag [Python] or https://sourceforge.net/projects/dnsping/ [C#]) to send real DNS queries and check for responses. If this shows significant levels of dropped packets (and especially if ping/traceroute do not show any drops), you should check whether your IP address is generating more than 100 queries per second (the default per-IP address QPS limit for Google Public DNS).

If you are legitimately generating more than 100 QPS and need to increase your QPS limit, you can request an increase through this issue tracker.
 
Reply all
Reply to author
Forward
0 new messages