Google DNS --- Averiguando cual Cluster estas utilizando

(this is -almost- a copy / paste of an email sent by Erik Sundberg to nanog mailing list on 

August 23). 

This post is being posted with his explicit permission.

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"                     <<<<<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.

(one more time: this is -almost- a copy / paste of an email sent by Erik Sundberg to nanog mailing 

list on August 23). This post is being posted with his explicit permission.

Solucion a: quagga vtysh " Exiting: failed to connect to any daemons."

Situacion:

  Al ejecutar el comando vtysh en el shell de linux para conectarse a los demonios de quagga (bgpd, ospfd, etc) da el siguiente error "Exiting: failed to connect to any daemons"

alejandro@miserver:~$ vtysh -d bgpd

Exiting: failed to connect to any daemons.

alejandro@miserver:~$ vtysh 

Exiting: failed to connect to any daemons.

Solucion:

  La solución es agregar al usuario con el que ejecutas vtysh al grupo quagga, para ello edita el archivo /etc/group.

  La linea en /etc/group debe quedar algo asi:

quagga:x:1003:alejandro

puedes especificar varios haciendo:

quagga:x:1003:alejandro, john

  Lo anterior es necesario porque la conexión a los demonios de quagga los realiza con UNIX domain socket y no todos los usuarios tienen acceso a dichos sockets.

Otra solución:

  Otra solución puede ser durante la compilación especificar el grupo para la creación de los sockets pasando lo siguiente durante el configure:

./configure --enable-vty-group=group

 

  Suerte, espero haya sido útil,

Script en Bash para conseguir errores 404 dentro de un servidor Web

Escenario:
Tengo mi servidor Web Apache sobre Linux y quiero revisar los errores 404 (página no encontrada) o broken link de los usuarios que acceden a mi servidor.

Solución:
Ejecutar un script mediante el crontab cerca de la media noche que revise el archivo access_log del Apache con el contenido 404 y envie un correo a un destinatario.

Script:
#El objectivo de este script es revisar errores 404 dentro de los logs del WebServer
#para de esta manera evitar "broken links". Alejandro Acosta
#Notese que se ejecuta casi a la media noche para conseguir TODOS los errores 404 del dia
FECHA=`date +"%d/%b/%Y"`
cat /usr/local/apache/logs/access_log | grep $FECHA | grep " 404 " > /tmp/404.txt
#Entra en el if unicamente en caso de conseguir errores 404
if [ $? = "0" ]; then
echo $?
mail -s "Errores 404 encontrados" micorreo@miproveedor.com < /tmp/404.txt
fi
\rm /tmp/404.txt

Crontab:
57 23 * * * /root/scripts/check_logs.sh

Bash Watchdog Script

Situación:
En algunas oportunidades es necesario tener un script que levante algún servicio/proceso cuando el mismo falla. Es decir, supongamos que tenemos un servidor web, mail, dns que falla, es necesario tener un script que sea capaz de levantarlo cuando sea necesario de manera automatica

Solución:
En mi caso, tengo el servicio snmpd que por alguna razón falla constantemente. Debido a que necesito tener el mismo levantando construí el siguiente script que luego coloqué en un crontab.

Ejemplo del SCRIPT:
#!/bin/bash
#FILENAME= /root/SCRIPTS/snmpd.Watchdog
# Reiniciar SNMPD cuando el servicio no se encuentra levantado
RESTART="/etc/init.d/snmpd restart"
#path to pgrep command
PGREP="/usr/bin/pgrep"
# Nombre del servicio (en en este caso snmpd)
SNMPD="snmpd"
# obtener el numero del PID del proceso
$PGREP ${SNMPD}
if [ $? -ne 0 ] # Si snmpd no esta corriendo
then
# reiniciar snmpd
$RESTART
fi

Ejemplo del crontab:
Cada minutos:
* * * * * /root/SCRIPTS/snmpd.Watchdog
Cada 5 minutos
*/5 * * * * /root/SCRIPTS/snmpd.Watchdog

Mas información:
El script anterior es basado en el que se encuentra en:
http://zedomax.com/blog/2008/07/28/linux-server-hack-how-to-setup-a-shell-script-to-auto-restart-apache-httpd-server/