Re: Google DNS --- Figuring out which DNS Cluster you are using

[Alejandro Acosta <alejandroacostaalamo () gmail com>]

Excellent, thanks for sharing.


El 23/8/17 a las 4:09 p.m., Erik Sundberg escribió:
> I sent this out on the outage list, with a lots of good feedback sent to me. So I figured it would be useful to share 
> the information on nanog as well.
>
>
> A couple months ago had to troubleshoot a google DNS issue with Google’s NOC. Below is some helpful information on 
> how to determine which DNS Cluster you are going to.
>
> Let’s remember that Google runs DNS Anycast for DNS queries to 8.8.8.8 and 8.8.4.4. Anycast routes your DNS queries 
> to the closes DNS cluster based on the best route / lowest metric to 8.8.8.8/8.8.4.4.   Google has deployed multiple 
> DNS clusters across the world and each DNS Cluster has multiple servers.
>
> So a DNS query in Chicago will go to a different DNS clusters than queries from a device in Atlanta or New York.
>
>
> How to get a list of google DNS Cluster’s.
> dig -t TXT +short locations.publicdns.goog. @8.8.8.8
>
> How to print this list in a table format. Script from: https://developers.google.com/speed/public-dns/faq
> ---------------
> #!/bin/bash
> IFS="\"$IFS"
> for LOC in $(dig -t TXT +short locations.publicdns.goog. @8.8.8.8)
> do
>   case $LOC in
>     '') : ;;
>     *.*|*:*) printf '%s ' ${LOC} ;;
>     *) printf '%s\n' ${LOC} ;;
>   esac
> done
> ---------------
>
> Which will give you a list like below. This is all of the IP network’s that google uses for their DNS Clusters and 
> their associated locations.
>
> 74.125.18.0/26 iad
> 74.125.18.64/26 iad
> 74.125.18.128/26 syd
> 74.125.18.192/26 lhr
> 74.125.19.0/24 mrn
> 74.125.41.0/24 tpe
> 74.125.42.0/24 atl
> 74.125.44.0/24 mrn
> 74.125.45.0/24 tul
> 74.125.46.0/24 lpp
> 74.125.47.0/24 bru
> 74.125.72.0/24 cbf
> 74.125.73.0/24 bru
> 74.125.74.0/24 lpp
> 74.125.75.0/24 chs
> 74.125.76.0/24 cbf
> 74.125.77.0/24 chs
> 74.125.79.0/24 lpp
> 74.125.80.0/24 dls
> 74.125.81.0/24 dub
> 74.125.92.0/24 mrn
> 74.125.93.0/24 cbf
> 74.125.112.0/24 lpp
> 74.125.113.0/24 cbf
> 74.125.115.0/24 tul
> 74.125.176.0/24 mrn
> 74.125.177.0/24 atl
> 74.125.179.0/24 cbf
> 74.125.181.0/24 bru
> 74.125.182.0/24 cbf
> 74.125.183.0/24 cbf
> 74.125.184.0/24 chs
> 74.125.186.0/24 dls
> 74.125.187.0/24 dls
> 74.125.190.0/24 sin
> 74.125.191.0/24 tul
> 172.217.32.0/26 lhr
> 172.217.32.64/26 lhr
> 172.217.32.128/26 sin
> 172.217.33.0/26 syd
> 172.217.33.64/26 syd
> 172.217.33.128/26 fra
> 172.217.33.192/26 fra
> 172.217.34.0/26 fra
> 172.217.34.64/26 bom
> 172.217.34.192/26 bom
> 172.217.35.0/24 gru
> 172.217.36.0/24 atl
> 172.217.37.0/24 gru
> 173.194.90.0/24 cbf
> 173.194.91.0/24 scl
> 173.194.93.0/24 tpe
> 173.194.94.0/24 cbf
> 173.194.95.0/24 tul
> 173.194.97.0/24 chs
> 173.194.98.0/24 lpp
> 173.194.99.0/24 tul
> 173.194.100.0/24 mrn
> 173.194.101.0/24 tul
> 173.194.102.0/24 atl
> 173.194.103.0/24 cbf
> 173.194.168.0/26 nrt
> 173.194.168.64/26 nrt
> 173.194.168.128/26 nrt
> 173.194.168.192/26 iad
> 173.194.169.0/24 grq
> 173.194.170.0/24 grq
> 173.194.171.0/24 tpe
> 2404:6800:4000::/48 bom
> 2404:6800:4003::/48 sin
> 2404:6800:4006::/48 syd
> 2404:6800:4008::/48 tpe
> 2404:6800:400b::/48 nrt
> 2607:f8b0:4001::/48 cbf
> 2607:f8b0:4002::/48 atl
> 2607:f8b0:4003::/48 tul
> 2607:f8b0:4004::/48 iad
> 2607:f8b0:400c::/48 chs
> 2607:f8b0:400d::/48 mrn
> 2607:f8b0:400e::/48 dls
> 2800:3f0:4001::/48 gru
> 2800:3f0:4003::/48 scl
> 2a00:1450:4001::/48 fra
> 2a00:1450:4009::/48 lhr
> 2a00:1450:400b::/48 dub
> 2a00:1450:400c::/48 bru
> 2a00:1450:4010::/48 lpp
> 2a00:1450:4013::/48 grq
>
> There are
> IPv4 Networks: 68
> IPv6 Networks: 20
> DNS Cluster’s Identified by POP Code’s: 20
>
> DNS Clusters identified by POP Code to City, State, or Country. Not all of these are Google’s Core Datacenters, some 
> of them are Edge Points of Presences (POPs). https://peering.google.com/#/infrastructure and 
> https://www.google.com/about/datacenters/inside/locations/
>
> Most of these are airport codes, it did my best to get the location correct.
> iad          Washington, DC
> syd         Sydney, Australia
> lhr          London, UK
> mrn        Lenoir, NC
> tpe         Taiwan
> atl          Altanta, GA
> tul          Tulsa, OK
> lpp          Findland
> bru         Brussels, Belgium
> cbf         Council Bluffs, IA
> chs         Charleston, SC
> dls          The Dalles, Oregon
> dub        Dublin, Ireland
> sin          Singapore
> fra          Frankfort, Germany
> bom       Mumbai, India
> gru         Sao Paulo, Brazil
> scl          Santiago, Chile
> nrt          Tokyo, Japan
> grq         Groningen, Netherlans
>
>
>
> Which Google DNS Server Cluster am I using. I am testing this from Chicago, IL
>
> # dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8
> "173.194.94.135"                     <<<<<<DNS Server IP, reference the list above to get the cluster, Council 
> Bluffs, IA
> "edns0-client-subnet 207.xxx.xxx.0/24"                                  <<<< Your Source IP Block
>
>
> Side note, the google dns servers will not respond to DNS queries to the Cluster’s Member’s IP, they will only 
> respond to dns queries to 8.8.8.8 and 8.8.4.4. So the following will not work.
> dig google.com @173.194.94.135
>
>
>
> Now to see the DNS Cluster load balancing in action. I am doing a dig query from our Telx\Digital Realty POP in 
> Atlanta, GA. We do peer with google at this location.
>
> I dig a dig query about 10 times and received the following unique dns cluster member ip’s as responses.
>
> dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8
> "74.125.42.138"
> "173.194.102.132"
> "74.125.177.5"
> "74.125.177.74"
> "74.125.177.71"
> "74.125.177.4"
>
> Which all are Google DNS Networks in Atlanta.
> 74.125.42.0/24
>
> atl
>
> 74.125.177.0/24
>
> atl
>
> 172.217.36.0/24
>
> atl
>
> 173.194.102.0/24
>
> atl
>
> 2607:f8b0:4002::/48
>
> atl
>
>
>
> Just thought it would be helpful when troubleshooting google DNS issues.
>
>
> ________________________________
>
> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it 
> may contain confidential information that is legally privileged. If you are not the intended recipient, or a person 
> responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, 
> distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. 
> If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You 
> must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.