Es imprescindible entender el código correctamente previamente a utilizarlo a tu proyecto y si ttienes algo que aportar puedes dejarlo en la sección de comentarios.
Solución:
Solución 1:
Esto no es directamente un problema de DNS, es un problema de enrutamiento de red entre algunas partes de Internet y los servidores DNS para serverfault.com. Dado que 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 lo muestra @radius, los paquetes a ns52 (como lo usa stackoverflow.com) pasan de aquí a 208.109.115.121 y a partir de ahí trabajar correctamente. Sin embargo, los paquetes a ns22 van a 208.109.115.201.
Dado que esas dos direcciones están en la misma /24 y el anuncio de BGP correspondiente también es para un /24 esta no debería suceder.
He hecho traceroutes a través de mi red que, en última instancia, usa MFN Above.net en lugar de Global Crossing para llegar a GoDaddy y no hay señales de ningún truco de enrutamiento debajo del /24 nivel: ambos servidores de nombres tienen rutas de seguimiento idénticas desde aquí.
Las únicas veces que he visto algo como esto no funcionaba con Cisco Express Forwarding (CEF). Se trata de un caché de nivel de hardware que se utiliza para acelerar el enrutamiento de paquetes. Desafortunadamente, solo ocasionalmente se desincroniza con la tabla de enrutamiento real e intenta reenviar paquetes a través de la interfaz incorrecta. Las entradas de CEF pueden bajar al /32 nivel incluso si la entrada de la tabla de enrutamiento subyacente es para un /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 crearán un ticket para los no clientes. Si alguno de ustedes están un cliente de GC, intente informar esto …
ACTUALIZAR a las 10:38 UTC Como ha señalado Jeff, el problema ha desaparecido. Las rutas de seguimiento a los dos servidores mencionados anteriormente ahora van a través del 208.109.115.121 siguiente salto.
Solucion 2:
sus servidores dns para serverfault.com [ ns21.domaincontrol.com, ns22.domaincontrol.com. ] son inalcanzables. durante las últimas ~ 20 horas, al menos de un par de importantes proveedores de servicios de Internet en Suecia [ telia, tele2, bredband2 ].
al mismo tiempo, servidores dns ‘vecinos’ para stackoverflow.com y superuser.com [ ns51.domaincontrol.com, ns52.domaincontrol.com ] son accesibles.
ejemplo 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 un filtrado arruinado / alguien activó alguna protección ddos no deseada y puso en la lista negra algunas partes de Internet. probablemente debería comunicarse con su proveedor de servicios de dns, vaya papá.
puedes verificar si el problema es [partialy] resuelto por:
- comprobar si godaddy ha reaccionado y cambiado los servidores de nombres, por ejemplo, busque serverfault.com en http://www.squish.net/dnscheck/ usando el tipo de recort: ANY
- compruebe si los servidores de nombres proporcionados responden al ping [not very scientific since name servers can work fine and still block icmp, but in this case it seems that icmp is allowed to other servers ] de telia a través de un espejo.
editar: trazar rutas 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.
Solución 3:
Mis sugerencias: como 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 del 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 pedir a los usuarios predeterminados del servidor que ofrezcan alojamiento de DNS secundario (puede ser solo si el usuario tiene> 1000 representantes 🙂
Solución 4:
Confirmo que NS21.DOMAINCONTROL.COM y NS22.DOMAINCONTROL.COM también son inalcanzables desde ISP Free.fr en Francia.
Al igual que pQd traceroute, el mío también termina después de 208.109.115.201 para ns21 y 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 del lugar de trabajo y del lugar de trabajo ayudaría, pero es muy probable que Global Crossing tenga una entrada de ruta 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 boged. 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 rutas 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
Solución 5:
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 tal vez 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 los TLD afectarían a más dominios (es de esperar). Para aumentar la resiliencia, puede delegar en un segundo servicio DNS para garantizar una mejor redundancia en la resolución si hay problemas con la (s) red (s) de control de dominio.
Reseñas y calificaciones
Recuerda que puedes mostrar este escrito si si solucionó tu problema.