DNS no se propaga por todo el mundo

No he cambiado nada relacionado con la entrada de DNS para serverfault.com , pero algunos usuarios informaron hoy que el DNS de serverfault.com no puede resolverlos .

Ejecuté una consulta simple y puedo confirmar esto: serverfault.com dns parece estar fallando en resolver en un puñado de países, sin ninguna razón en particular que pueda discernir. (también confirmado a través de What's My DNS, que hace algunos pings en todo el mundo de manera similar, por lo que es confirmado como un problema por dos fuentes diferentes).

• ¿Por qué sucedería esto si no he tocado el DNS para serverfault.com?

• nuestro registrador es (gag) GoDaddy, y uso la configuración predeterminada de DNS en su mayor parte sin incidentes. ¿Estoy haciendo algo mal? ¿Me han abandonado los dioses del DNS?

• ¿Hay algo que pueda hacer para arreglar esto? ¿Alguna forma de mejorar el DNS o forzar que el DNS se propague correctamente en todo el mundo?

Actualización: a partir del lunes a las 3:30 a.m. PST, todo parece correcto. Se puede acceder al sitio de informes de JustPing desde todas las ubicaciones. Gracias por las muchas respuestas informativas, aprendí mucho y me referiré a este Q la próxima vez que esto suceda.

Esto no es directamente un problema de DNS, es un problema de enrutamiento de red entre algunas partes de Internet y los servidores de DNS para serverfault.com. Como no se puede acceder a los servidores de nombres, el dominio deja de resolverse.

Por lo que puedo decir, el problema de enrutamiento está en el enrutador (Global Crossing?) Con dirección IP 204.245.39.50.

Como se muestra en @radius , los paquetes a ns52 (como los que utiliza stackoverflow.com ) pasan de aquí hacia 208.109.115.121y desde allí funcionan correctamente. Sin embargo, los paquetes a ns22 van a 208.109.115.201.

Dado que esas dos direcciones están en el mismo /24y el anuncio BGP correspondiente también es para /24esto , esto no debería suceder .

Hice traceroutes a través de mi red que finalmente usa MFN Above.net en lugar de Global Crossing para llegar a GoDaddy y no hay signos de ningún truco de enrutamiento por debajo del /24nivel: ambos servidores de nombres tienen traceroutes idénticos desde aquí.

Las únicas veces que he visto algo como esto se rompió Cisco Express Forwarding (CEF). Este es un caché de nivel de hardware utilizado para acelerar el enrutamiento de paquetes. Desafortunadamente, de vez en cuando no se sincroniza con la tabla de enrutamiento real e intenta reenviar paquetes a través de la interfaz incorrecta. Las entradas CEF pueden bajar al /32nivel incluso si la entrada de la tabla de enrutamiento subyacente es para a /24. Es complicado encontrar este tipo de problemas, pero una vez identificados, normalmente son fáciles de solucionar.

Envié un correo electrónico a GC y también traté de hablar con ellos, pero no crearán un boleto para los que no son clientes. Si alguno de ustedes es cliente de GC, intente informar esto ...

ACTUALIZACIÓN a las 10:38 UTC Como Jeff ha notado, el problema ahora se ha solucionado. Las rutas de seguimiento a los dos servidores mencionados anteriormente ahora pasan por el 208.109.115.121siguiente salto.

sus servidores dns para serverfault.com [ns21.domaincontrol.com, ns22.domaincontrol.com. ] son ​​inalcanzables. durante las últimas ~ 20 h, al menos de un par de grandes isps en Suecia [ telia , tele2 , bredband2 ].

Al mismo tiempo, los servidores DNS 'vecinos' para stackoverflow.com y superuser.com [ns51.domaincontrol.com, ns52.domaincontrol.com] son ​​accesibles.

muestra de traceroute a ns52.domaincontrol.com:

 1. xxxxxxxxxxx
 2. 83.233.28.193           
 3. 83.233.79.81            
 4. 213.200.72.5            
 5. 64.208.110.129          
 6. 204.245.39.50           
 7. 208.109.115.121         
 8. 208.109.115.162         
 9. 208.109.113.62          
10. 208.109.255.26          

y a ns21.domaincontrol.com

 1. xxxxxxxxxxxx
 2. 83.233.28.193      
 3. 83.233.79.81       
 4. 213.200.72.5       
 5. 64.208.110.129     
 6. 204.245.39.50      
 7. 208.109.115.201    
 8. ???

tal vez arruinó el filtrado / alguien activó alguna protección no deseada de ddos ​​y puso en la lista negra algunas partes de internet. probablemente deberías contactar a tu proveedor de servicios de dns - ve papi.

puede verificar si el problema se resuelve [parcialmente] mediante:

1. comprobar si godaddy ha reaccionado y cambiado los servidores de nombres, por ejemplo, busque serverfault.com en http://www.squish.net/dnscheck/ utilizando el tipo de recort: CUALQUIERA
2. verifique si los servidores de nombres provistos responden al ping [no es muy científico ya que los servidores de nombres pueden funcionar bien y aún bloquear icmp, pero en este caso parece que icmp está permitido a otros servidores] desde telia a través del espejo .

editar : traceroutes desde lugares de trabajo

Polonia

 1. xxxxxxxxxxxxxxx
 2. 153.19.40.254               
 3. ???
 4. 153.19.254.236              
 5. 212.191.224.205             
 6. 213.248.83.129              
 7. 80.91.254.171               
 8. 80.91.249.105               
    80.91.251.230
    80.91.254.93
    80.91.251.52
 9. 213.248.89.182              
10. 204.245.39.50               
11. 208.109.115.121             
12. 208.109.115.162             
13. 208.109.113.62              
14. 208.109.255.26              

Alemania

 1. xxxxxxxxxxxx
 2. 89.149.218.181       
 3. 89.149.218.2         
 4. 134.222.105.249      
 5. 134.222.231.205      
 6. 134.222.227.146      
 7. 80.81.194.26         
 8. 64.125.24.6          
 9. 64.125.31.249        
10. 64.125.27.165        
11. 64.125.26.178        
12. 64.125.26.242        
13. 209.249.175.170      
14. 208.109.113.58       
15. 208.109.255.26       

editar : todo funciona bien ahora de hecho.

Mis sugerencias: como explicó Alnitak, el problema no es DNS sino enrutamiento (probablemente BGP). El hecho de que no se haya cambiado nada en la configuración de DNS es normal, ya que el problema no estaba en el DNS.

serverfault.com tiene hoy una configuración de DNS muy pobre, ciertamente insuficiente para un sitio importante como este:

• solo dos servidores de nombres
• todos los huevos en la misma canasta (ambos están en el mismo AS)

Acabamos de ver el resultado: una falla de enrutamiento (algo que es bastante común en Internet) es suficiente para hacer que serverfault.com desaparezca para algunos usuarios (dependiendo de sus operadores, no de sus países).

Sugiero agregar más servidores de nombres, ubicados en otros AS. Esto permitiría la resistencia al fracaso. Puede alquilarlos a empresas privadas o solicitar a los usuarios predeterminados del servidor que ofrezcan alojamiento DNS secundario (puede ser solo si el usuario tiene> 1000 rep :-)

Confirmo que NS21.DOMAINCONTROL.COM y NS22.DOMAINCONTROL.COM también son inalcanzables desde ISP Free.fr en Francia.
Al igual que pQd traceroute, la mía también termina después de 208.109.115.201 tanto para ns21 como para ns22.

traceroute to NS22.DOMAINCONTROL.COM (208.109.255.11), 64 hops max, 40 byte packets
 1  x.x.x.x (x.x.x.x)  2.526 ms  0.799 ms  0.798 ms
 2  78.224.126.254 (78.224.126.254)  6.313 ms  6.063 ms  6.589 ms
 3  213.228.5.254 (213.228.5.254)  6.099 ms  6.776 ms *
 4  212.27.50.170 (212.27.50.170)  6.943 ms  6.866 ms  6.842 ms
 5  212.27.50.190 (212.27.50.190)  8.308 ms  6.641 ms  6.866 ms
 6  212.27.38.226 (212.27.38.226)  68.660 ms  185.527 ms  14.123 ms
 7  204.245.39.50 (204.245.39.50)  48.544 ms  19.391 ms  19.753 ms
 8  208.109.115.201 (208.109.115.201)  19.315 ms  19.668 ms  34.110 ms
 9  * * *
10  * * *
11  * * *
12  * * *

Pero ns52.domaincontrol.com (208.109.255.26) funciona y está en la misma subred que ns22.domaincontrol.com (208.109.255.11)

traceroute to ns52.domaincontrol.com (208.109.255.26), 64 hops max, 40 byte packets
 1  x.x.x.x (x.x.x.x)  1.229 ms  0.816 ms  0.808 ms
 2  78.224.126.254 (78.224.126.254)  12.127 ms  5.623 ms  6.068 ms
 3  * * *
 4  212.27.50.170 (212.27.50.170)  13.824 ms  6.683 ms  6.828 ms
 5  212.27.50.190 (212.27.50.190)  6.962 ms *  7.085 ms
 6  212.27.38.226 (212.27.38.226)  35.379 ms  7.105 ms  7.830 ms
 7  204.245.39.50 (204.245.39.50)  19.896 ms  19.426 ms  19.355 ms
 8  208.109.115.121 (208.109.115.121)  37.931 ms  19.665 ms  19.814 ms
 9  208.109.115.162 (208.109.115.162)  19.663 ms  19.395 ms  29.670 ms
10  208.109.113.62 (208.109.113.62)  19.398 ms  19.220 ms  19.158 ms
11  * * *
12  * * *
13  * * *

Como puede ver, esta vez después de 204.245.39.50 vamos a 208.109.115.121 en lugar de 208.109.115.201. Y pQd tiene el mismo traceroute. Desde un lugar de trabajo no crucé este enrutador 204.245.39.50 (Global Crossing).

Más traceroute desde el lugar de trabajo y el que no funciona ayudaría, pero es muy probable que Global Crossing tenga una entrada de enrutamiento falsa para 208.109.255.11/32 y 216.69.185.11/32 como 208.109.255.10, 208.109.255.12, 216.69.185.10, 216.69. 185.12 están funcionando bien.

Es difícil saber por qué tiene una entrada de enrutamiento falsa. Probablemente 208.109.115.201 (Go Daddy) está anunciando una ruta que no funciona para 208.109.255.11/32 y 216.69.185.11/32.

EDITAR: puede hacer telnet route-server.eu.gblx.net para conectarse al servidor de ruta de Global Crossing y hacer traceroute desde la red de Global Crossing

EDITAR: Parece que el mismo problema ya ocurrió con otros NS hace unos días, consulte: http://www.newtondynamics.com/forum/viewtopic.php?f=9&t=5277&start=0

Lo que sería útil sería ver un seguimiento de resolución detallado de las ubicaciones que están fallando ... ver en qué capa de la ruta de resolución está fallando. No estoy familiarizado con el servicio que está utilizando, pero quizás sea una opción en alguna parte.

De lo contrario, es muy probable que los problemas estén "más abajo" en el árbol, ya que las fallas en la raíz o los TLDs afectarían más dominios (es de esperar). Para aumentar la capacidad de recuperación, puede delegar en un segundo servicio DNS para garantizar una mejor redundancia en la resolución si hay problemas con las redes de control de dominio.

Me sorprende que no alojes tu propio DNS. La ventaja de hacerlo de esta manera es que si el DNS es accesible, también lo es (con suerte) su sitio.

Al menos de UPC, obtengo esta reacción cuando intento obtener su registro A de su servidor autorizado (ns21.domaincontrol.com).

; <<>> DiG 9.5.1-P2 <<>> @ns21.domaincontrol.com serverfault.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38663
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;serverfault.com.       IN  A

;; Query time: 23 msec
;; SERVER: 216.69.185.11#53(216.69.185.11)
;; WHEN: Sun Jul 19 12:09:40 2009
;; MSG SIZE  rcvd: 33

Cuando intento lo mismo desde una máquina en una red diferente (OVH), obtengo una respuesta

; <<>> DiG 9.4.2-P2 <<>> @216.69.185.11 serverfault.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33998
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;serverfault.com.               IN      A

;; ANSWER SECTION:
serverfault.com.        3600    IN      A       69.59.196.212

;; AUTHORITY SECTION:
serverfault.com.        3600    IN      NS      ns21.domaincontrol.com.
serverfault.com.        3600    IN      NS      ns22.domaincontrol.com.

;; Query time: 83 msec
;; SERVER: 216.69.185.11#53(216.69.185.11)
;; WHEN: Sun Jul 19 12:11:05 2009
;; MSG SIZE  rcvd: 101

Obtengo un comportamiento similar para un par de otros dominios, por lo que supongo que UPC (al menos) está redirigiendo silenciosamente las consultas DNS a su propio servidor de nombres de almacenamiento en caché y falsificando las respuestas. Si su DNS se ha comportado mal brevemente, esto podría explicarlo ya que los servidores de nombres de UPC pueden estar almacenando en caché la respuesta NXDOMAIN.