Ayer cambié el alojamiento DNS para el dominio bagtheweb.com de Godaddy a CloudFlare. Cloudflare dice que la transferencia fue exitosa y que la resolución DNS funciona muy bien en todas partes, EXCEPTO en mi oficina. A veces funciona, a veces obtengo respuestas SERVFAIL usando dig bagtheweb.com.
La computadora de mi oficina está usando mi puerta de enlace de AT&T para DNS. Miré el panel de control de la puerta de enlace y dice que está usando 68.94.156.9 y 68.94.157.9 para DNS.
Intenté investigar usando ambos solucionadores de DNS directamente: dig @68.94.156.9 bagtheweb.comy dig @68.94.157.9 bagtheweb.com.
Aproximadamente la mitad de las veces el resultado es bueno (veo registros A que apuntan a direcciones IP) y la mitad de las veces obtengo respuestas SERVFAIL. Lo intenté varias veces y sigo viendo ambas respuestas aparentemente al azar. Han pasado unas 20 horas desde que hice la transferencia y sigo viendo esto.
Intenté buscar en los servidores DNS de CloudFlare, theo.ns.cloudflare.com. y vita.ns.cloudflare.com. y funciona muy bien en todo momento. También intenté buscar en el servidor DNS de Google 8.8.8.8 y también funciona perfectamente.
Entonces, mi única conclusión es que AT&T apesta, y cada una de esas IP de servidores DNS está respaldada por un grupo de servidores, algunos que se actualizaron correctamente y otros que están confusos. Espero que 24 horas sea el umbral mágico para que se actualicen esos servidores defectuosos.
¿Alguna idea de por qué sucede esto? ¿Hay algo más que pueda hacer para investigar o forzar una actualización (además de llamar a AT&T y perder 4 horas de mi vida)? ¿Hay algo que podría haber hecho antes de la transferencia de zona para eliminar este problema? Sé que puedo solucionar el problema por mí mismo utilizando el DNS de Google, pero me pregunto si otros usuarios podrían estar experimentando el mismo problema.
2 comandos consecutivos:
Marcels-iMac:~ marcel$ dig @68.94.157.9 bagtheweb.com
; <<>> DiG 9.9.7-P3 <<>> @68.94.157.9 bagtheweb.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58515
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;bagtheweb.com. IN A
;; Query time: 131 msec
;; SERVER: 68.94.157.9#53(68.94.157.9)
;; WHEN: Fri Mar 02 12:01:07 CST 2018
;; MSG SIZE rcvd: 42
Marcels-iMac:~ marcel$ dig @68.94.157.9 bagtheweb.com
; <<>> DiG 9.9.7-P3 <<>> @68.94.157.9 bagtheweb.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31350
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;bagtheweb.com. IN A
;; ANSWER SECTION:
bagtheweb.com. 60 IN A 184.73.200.185
bagtheweb.com. 60 IN A 23.23.171.5
bagtheweb.com. 60 IN A 50.17.234.140
bagtheweb.com. 60 IN A 174.129.203.239
bagtheweb.com. 60 IN A 204.236.236.192
bagtheweb.com. 60 IN A 107.22.233.200
bagtheweb.com. 60 IN A 23.21.55.239
bagtheweb.com. 60 IN A 23.23.215.144
;; Query time: 54 msec
;; SERVER: 68.94.157.9#53(68.94.157.9)
;; WHEN: Fri Mar 02 12:01:09 CST 2018
;; MSG SIZE rcvd: 170
Respuesta1
¿Hay algo más que pueda hacer para investigar o forzar una actualización (además de llamar a AT&T y perder 4 horas de mi vida)?
No. Usted ha hecho su parte al configurar los registros con el proveedor y el proveedor realizó la transferencia de zona solicitada.
¿Hay algo que podría haber hecho antes de la transferencia de zona para eliminar este problema?
¿Tal vez? TúpodríaHemos podido establecer un TTL REALMENTE bajo, como 5 minutos, pero incluso eso tiene que replicarse en toda la infraestructura DNS antes de que realmente importe.
AT&T apesta
Es más específico que la mayoría de los DNS alojados por ISP son generalmente una mierda. No están diseñados para ofrecer velocidad, sino para ayudar a eliminar la transferencia innecesaria de datos a través de otras redes (que normalmente cuesta dinero); lo que significa un almacenamiento en caché realmente grande y pesado. También les resulta más fácil alojar su propio DNS y proporcionar estos valores a sus clientes a través de DHCP. Par del curso.
Me pregunto si otros usuarios podrían estar experimentando el mismo problema.
Es probable que esto sea algo específico de la infraestructura DNS de AT&T y apuesto a que después de que sus servidores DNS terminen de actualizarse, estarán bien.
Sé que puedo solucionar el problema por mí mismo usando el DNS de Google, pero
Probablemente ya deberías hacer esto. Por cierto, el nuevo servicio DNS de IBM suele ser MUY rápido:9.9.9.9