no he cambiadocualquier cosarelacionado con la entrada DNS para serverfault.com, pero algunos usuarios informaron hoy queel DNS de serverfault.com no se resuelve para ellos.
corrí unconsulta justpingy puedo confirmar esto: serverfault.com dns parece no resolverse en un puñado de países, sin ninguna razón en particular que pueda discernir. (también confirmado vía¿Cuál es mi DNS?que hace algunos pings en todo el mundo de manera similar, por lo que dos fuentes diferentes confirman que es un problema).
¿Por qué sucedería esto si no he tocado el DNS de serverfault.com?
nuestro registrador es (gag) GoDaddy, y uso la configuración DNS predeterminada en su mayor parte sin incidentes. ¿Estoy haciendo algo mal? ¿Me han abandonado los dioses del DNS?
¿Hay algo que pueda hacer para solucionar este problema? ¿Alguna forma de hacer avanzar el DNS o forzar que el DNS se propague correctamente en todo el mundo?
Actualización: a partir del lunes a las 3:30 am PST, todo parece correcto. Se puede acceder al sitio de informes JustPing desde todas las ubicaciones. Gracias por las muchas respuestas tan informativas, aprendí mucho y me referiré a esta pregunta la próxima vez que esto suceda.
Respuesta1
Esto no es directamente un problema de DNS, es un problema de enrutamiento de red entre algunas partes de Internet y los servidores DNS de serverfault.com. Como no se puede acceder a los servidores de nombres, el dominio deja de resolverse.
Hasta donde puedo decir, el problema de enrutamiento está en el enrutador (¿Global Crossing?) con dirección IP 204.245.39.50.
Comomostradopor@radio, paquetes a ns52 (como los usastackoverflow.com) pasar de aquí hacia 208.109.115.121y desde allí funciona correctamente. Sin embargo, los paquetes a ns22 van a 208.109.115.201.
Dado que esas dos direcciones están en la misma /24y el anuncio BGP correspondiente también es para /24estono debería suceder.
He realizado 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 señales 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 así estaba roto.Reenvío expreso de Cisco(CEF). Se trata de una caché a nivel de hardware que se utiliza para acelerar el enrutamiento de paquetes. Desafortunadamente, ocasionalmente no está sincronizado 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 un archivo /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 intenté hablar con ellos, pero no crearon un ticket para los que no son clientes. Si alguno de ustedessonun cliente de GC, por favor intente informar esto...
ACTUALIZACIÓN a las 10:38 UTC Como Jeff ha señalado, el problema ya se ha solucionado. Las rutas de seguimiento a ambos servidores mencionados anteriormente ahora pasan por el 208.109.115.121siguiente salto.
Respuesta2
sus servidores DNS para serverfault.com [ns21.domaincontrol.com, ns22.domaincontrol.com. ] son inalcanzables. durante las últimas ~20 h, al menos desde un par de isps importantes en Suecia [telia,tele2,banda cruzada2].
al mismo tiempo, se puede acceder a los servidores DNS 'vecinos' para stackoverflow.com y superuser.com [ns51.domaincontrol.com, ns52.domaincontrol.com].
traceroute de muestra 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 contra DDOS no deseada y puso en la lista negra algunas partes de Internet. Probablemente deberías comunicarte con tu proveedor de servicios DNS, ve papá.
Puede verificar si el problema se resuelve [parcialmente] mediante:
- comprobar si godaddy ha reaccionado y ha cambiado los servidores de nombres; por ejemplo, busque serverfault.com enhttp://www.squish.net/dnscheck/usando el tipo de registro: CUALQUIER
- compruebe si los servidores de nombres proporcionados responden al ping [no es muy científico ya que los servidores de nombres pueden funcionar bien y aun así bloquear icmp, pero en este caso parece que icmp está permitido en otros servidores] desde telia a través deespejo.
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.
Respuesta3
Mis sugerencias: como lo explica Alnitak, el problema no es el DNS sino el 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 en día una configuración de DNS muy pobre, ciertamente insuficiente para un sitio importante como este:
- sólo dos servidores de nombres
- todos los huevos en la misma canasta (ambos están en el mismo AS)
Acabamos de ver el resultado: un error de enrutamiento (algo bastante común en Internet) es suficiente para 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 resiliencia ante fallos. Puede alquilarlos a empresas privadas o pedir a los usuarios de serverfault que ofrezcan alojamiento DNS secundario (puede ser sólo si el usuario tiene > 1000 representantes :-)
Respuesta4
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ás utilizando, pero quizás sea una opción en alguna parte.
De lo contrario, lo más probable es que los problemas estén "más abajo" en el árbol, ya que las fallas en la raíz o en los TLD afectarían a más dominios (es de esperar). Para aumentar la resiliencia, puede delegar a un segundo servicio DNS para garantizar una mejor redundancia en la resolución si hay problemas con las redes de domaincontrol.