Mailing List Archive

Google DNS --- Figuring out which DNS Cluster you are using
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.
Re: Google DNS --- Figuring out which DNS Cluster you are using [ In reply to ]
This is great.  Thanks for sharing . 

Sent from Yahoo Mail on Android

On Wed, Aug 23, 2017 at 1:11 PM, Erik Sundberg<ESundberg@nitelusa.com> wrote: 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.
Re: Google DNS --- Figuring out which DNS Cluster you are using [ In reply to ]
On Wed, Aug 23, 2017 at 4:37 PM, i mawsog via NANOG <nanog@nanog.org> wrote:

>
> This is great. Thanks for sharing .
>
> Sent from Yahoo Mail on Android
>
> On Wed, Aug 23, 2017 at 1:11 PM, Erik Sundberg<ESundberg@nitelusa.com>
> wrote: 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
>
>
isn't this list also here:
https://developers.google.com/speed/public-dns/faq#locations

I mean, you could read the docs first to get the same answer, I think...
right?
I'm also pretty sure there are RIPE Atlas measurements of 8.8.8.8/8.8.4.4
that could tell you from which source-asn a backend sees traffic from..
right? (or with a tiny bit of thought one could be proposed/executed)


> 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.
>
>
Re: Google DNS --- Figuring out which DNS Cluster you are using [ In reply to ]
Gee Chris, that's kind of an asinine response. Erik took the time to let
us know about what he had found out, with a nice code snippet too. I don't
have time in my job to just go surfing around google.com to see what is
there. His mail took me about 2 minutes to read and now I know that such
info exists.

Thank you Erik!

--
Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474

On Wed, Aug 23, 2017 at 5:10 PM, Christopher Morrow <morrowc.lists@gmail.com
> wrote:

> On Wed, Aug 23, 2017 at 4:37 PM, i mawsog via NANOG <nanog@nanog.org>
> wrote:
>
> >
> > This is great. Thanks for sharing .
> >
> > Sent from Yahoo Mail on Android
> >
> > On Wed, Aug 23, 2017 at 1:11 PM, Erik Sundberg<ESundberg@nitelusa.com>
> > wrote: 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
> >
> >
> isn't this list also here:
> https://developers.google.com/speed/public-dns/faq#locations
>
> I mean, you could read the docs first to get the same answer, I think...
> right?
> I'm also pretty sure there are RIPE Atlas measurements of 8.8.8.8/8.8.4.4
> that could tell you from which source-asn a backend sees traffic from..
> right? (or with a tiny bit of thought one could be proposed/executed)
>
>
> > 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.
> >
> >
>
Re: Google DNS --- Figuring out which DNS Cluster you are using [ In reply to ]
On Wed, Aug 23, 2017 at 8:30 PM, Joe Hamelin <joe@nethead.com> wrote:

> Gee Chris, that's kind of an asinine response. Erik took the time to let
> us know about what he had found out, with
>

sure, except I think the link has even been posted to nanog in the past.
My point was really: it's documented, so you don't have to do the work.

-chris

a nice code snippet too. I don't have time in my job to just go surfing
> around google.com to see what is there. His mail took me about 2 minutes
> to read and now I know that such info exists.
>
>
Thank you Erik!
>
> --
> Joe Hamelin, W7COM, Tulalip, WA, +1 (360) 474-7474 <(360)%20474-7474>
>
> On Wed, Aug 23, 2017 at 5:10 PM, Christopher Morrow <
> morrowc.lists@gmail.com> wrote:
>
>> On Wed, Aug 23, 2017 at 4:37 PM, i mawsog via NANOG <nanog@nanog.org>
>> wrote:
>>
>> >
>> > This is great. Thanks for sharing .
>> >
>> > Sent from Yahoo Mail on Android
>> >
>> > On Wed, Aug 23, 2017 at 1:11 PM, Erik Sundberg<ESundberg@nitelusa.com
>> >
>> > wrote: 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
>> >
>> >
>> isn't this list also here:
>> https://developers.google.com/speed/public-dns/faq#locations
>>
>> I mean, you could read the docs first to get the same answer, I think...
>> right?
>> I'm also pretty sure there are RIPE Atlas measurements of 8.8.8.8/8.8.4.4
>> that could tell you from which source-asn a backend sees traffic from..
>> right? (or with a tiny bit of thought one could be proposed/executed)
>>
>>
>> > 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.
>> >
>> >
>>
>
>
Re: Google DNS --- Figuring out which DNS Cluster you are using [ In reply to ]
If Google was being sensible the servers would just return the
information along with the answer. They all support EDNS.

e.g. dig +nsid @8.8.8.8

This is the type of thing the NSID (RFC 5001) was designed to do.
It just requires Google to configure the servers to return a id.
You would then back something like this. In this case the nsid is
the hostname but it can be anything you like it to be. A value
that makes sense to most people or a value that only make sense
to a Google.

; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> +nsid .
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38770
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; NSID: 72 6f 63 6b 2e 64 76 2e 69 73 63 2e 6f 72 67 ("rock.dv.isc.org")
; COOKIE: f58c358da14bc19476e2331f599e21c452df41a06367d78d (good)
;; QUESTION SECTION:
;. IN A

;; AUTHORITY SECTION:
. 10773 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2017082301 1800 900 604800 86400

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 24 10:45:56 AEST 2017
;; MSG SIZE rcvd: 150


--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Re: Google DNS --- Figuring out which DNS Cluster you are using [ In reply to ]
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.
Re: Google DNS --- Figuring out which DNS Cluster you are using [ In reply to ]
On Wed, 23 Aug 2017 20:09:49 +0000
Erik Sundberg <ESundberg@nitelusa.com> wrote:

> 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

Worth noting, this record has TTL 60 and caching can cause unexpected
responses; you may have to try a few times to get the correct data. My
first attempt gave me an unrecognized "edns0-client-subnet" and a Google
IP from Finland when I was querying from Atlanta.

-s
RE: Google DNS --- Figuring out which DNS Cluster you are using [ In reply to ]
Shaun, Good catch!!!

I would be nice if this was lowered to 1 second.

#dig o-o.myaddr.l.google.com -t txt @8.8.4.4
;; ANSWER SECTION:
o-o.myaddr.l.google.com. 51 IN TXT "74.125.80.4"
o-o.myaddr.l.google.com. 51 IN TXT "edns0-client-subnet 14.161.5.0/24" <<< Not my ip but someone from this IP did query this 9 seconds ago.




-----Original Message-----
From: Shaun [mailto:nanog@shat.net]
Sent: Wednesday, August 23, 2017 11:21 PM
To: Erik Sundberg
Cc: nanog@nanog.org
Subject: Re: Google DNS --- Figuring out which DNS Cluster you are using

On Wed, 23 Aug 2017 20:09:49 +0000
Erik Sundberg <ESundberg@nitelusa.com> wrote:

> 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

Worth noting, this record has TTL 60 and caching can cause unexpected responses; you may have to try a few times to get the correct data. My first attempt gave me an unrecognized "edns0-client-subnet" and a Google IP from Finland when I was querying from Atlanta.

-s

________________________________

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.
RE: Google DNS --- Figuring out which DNS Cluster you are using [ In reply to ]
All.. You're welcome for the info.

Let's remember what NANOG is about "mailing list is established to provide a forum for the exchange of technical information and the discussion of specific implementation issues that require cooperation among network service providers."

I sent this out to educate everyone and share the knowledge about how Google's Recursive DNS servers are setup for 8.8.8.8 / 8.8.4.4. Yes, some people already know how google handles their DNS service and have read the Google DNS FAQ page where this information is buried in the middle of the page. But if you never had to really troubleshoot in depth an issue with Google's DNS Server you probably never read that article. (https://developers.google.com/speed/public-dns/faq)

We still get the email on the various lists whether it's Nanog or the Outages with the subject "OMG 8.8.8.8 IS DOWN!!!!" (Yes I admitted I was responsible for one of these email threads when we had the issues with Google DNS servers in the Atlanta Area a couple months ago). Then everyone starts responding with, mine works and I am in New York, London, Chicago, Dallas, and etc. And the original reporter of this issue has no idea why they are down and no one else is down to 8.8.8.8. At least this way someone might be able to take the troubleshooting step further and narrowing down the issue to a Google DNS Cluster or a Server in the cluster. Maybe giving a Google Network or DNS admin lurking on the forum some more information go off of, which might make them take a more serious look at the outage report.

I also don’t run a blog or anything, but let's not forget our posts do get indexed by Google's search engines. And this thread is already the 3rd result for "Google DNS Cluster" which might help some lone network admin that is not apart of NANOG troubleshooting google dns issues. They might even open a more informative ticket with their service provider's NOC.

Anyways I am just another network engineer running my little corner of this global experiment that we call the "Internet" sharing some knowledge.

-Erik


-----Original Message-----
From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Alejandro Acosta
Sent: Wednesday, August 23, 2017 9:40 PM
To: nanog@nanog.org
Subject: Re: Google DNS --- Figuring out which DNS Cluster you are using

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.


________________________________

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.
Re: Google DNS --- Figuring out which DNS Cluster you are using [ In reply to ]
On Thu, Aug 24, 2017 at 10:53:58AM +1000,
Mark Andrews <marka@isc.org> wrote
a message of 39 lines which said:

> If Google was being sensible the servers would just return the
> information along with the answer. They all support EDNS.

I fully agree with you that NSID (RFC 5001) is great and Google should
really deploy it. However:

> e.g. dig +nsid @8.8.8.8

I assume that Google wants also to be debuggable by people who work on
inferior operating systems, and have no dig. Hence this trick. For
instance, L.root-servers.net has both NSID and a special name,
identity.l.root-servers.org (see RFC 7108).
Re: Google DNS --- Figuring out which DNS Cluster you are using [ In reply to ]
Stephane Bortzmeyer <bortzmeyer@nic.fr> writes:

> On Thu, Aug 24, 2017 at 10:53:58AM +1000,
> Mark Andrews <marka@isc.org> wrote
> a message of 39 lines which said:
>
>> If Google was being sensible the servers would just return the
>> information along with the answer. They all support EDNS.
>
> I fully agree with you that NSID (RFC 5001) is great and Google should
> really deploy it.

+1 for NSID! Should be mandatory for anycast DNS, IMHO. I don't
understand why Google haven't enabled it.


> However:
>
>> e.g. dig +nsid @8.8.8.8
>
> I assume that Google wants also to be debuggable by people who work on
> inferior operating systems, and have no dig. Hence this trick. For
> instance, L.root-servers.net has both NSID and a special name,
> identity.l.root-servers.org (see RFC 7108).

As you state, there is no problem providing both. Or an infinite number
of special names if they like. But NSID provides something none of the
special names can. Quoting the justification in the intro of RFC5001:

Given that a DNS query is an idempotent operation with no retained
state, it would appear that the only completely reliable way to
obtain the identity of the name server that responded to a particular
query is to have that name server include identifying information in
the response itself.


Sometimes it just isn't enough to know which server answered the
previous or next requests.



Bjørn