Ontem troquei a hospedagem DNS do domínio bagtheweb.com de Godaddy para CloudFlare. A Cloudflare diz que a transferência foi bem-sucedida e que a resolução de DNS funciona muito bem em qualquer lugar, EXCETO no meu escritório. Às vezes funciona, às vezes recebo respostas SERVFAIL usando dig bagtheweb.com.
Meu computador do escritório está usando meu gateway AT&T para DNS. Olhei para o painel de controle do gateway e ele diz que está usando 68.94.156.9 e 68.94.157.9 para DNS.
Tentei pesquisar usando ambos os resolvedores de DNS diretamente: dig @68.94.156.9 bagtheweb.come dig @68.94.157.9 bagtheweb.com.
Aproximadamente metade das vezes o resultado é bom (vejo registros A apontando para endereços IP) e na metade das vezes recebo respostas SERVFAIL. Tentei várias vezes e continuo vendo as duas respostas aparentemente aleatoriamente. Já se passaram cerca de 20 horas desde que fiz a transferência e ainda estou vendo isso.
Tentei cavar os servidores DNS da CloudFlare theo.ns.cloudflare.com. e vita.ns.cloudflare.com. e funciona muito bem sempre. Também tentei cavar que o servidor DNS 8.8.8.8 do Google também funciona perfeitamente.
Portanto, minha única conclusão é que a AT&T é uma droga, e cada um desses IPs de servidores DNS é apoiado por um conjunto de servidores, alguns atualizados corretamente e outros confusos. Espero que 24 horas seja o limite mágico para a atualização desses servidores ruins.
Alguma ideia de por que isso está acontecendo? Há mais alguma coisa que eu possa fazer para investigar ou forçar uma atualização (além de ligar para a AT&T e perder 4 horas da minha vida)? Há algo que eu poderia ter feito antes da transferência de zona para eliminar esse problema? Sei que posso resolver o problema sozinho usando o DNS do Google, mas me pergunto se outros usuários por aí podem estar enfrentando o mesmo 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
Responder1
Há mais alguma coisa que eu possa fazer para investigar ou forçar uma atualização (além de ligar para a AT&T e perder 4 horas da minha vida)?
Não. Você fez sua parte configurando os registros com o provedor e o provedor realizou a transferência de zona solicitada.
Há algo que eu poderia ter feito antes da transferência de zona para eliminar esse problema?
Talvez? Vocêpoderconseguimos definir um TTL MUITO baixo, como 5 minutos, mas mesmo isso precisa ser replicado em toda a infraestrutura DNS antes que realmente importe.
AT&T é uma merda
É mais específico que a maioria dos DNS hospedados pelo ISP geralmente é uma porcaria. Eles não foram desenvolvidos para serem rápidos, mas para ajudar a eliminar a transferência desnecessária de dados por meio de outras redes (o que normalmente custa dinheiro); o que significa cache realmente grande e pesado. Também é mais fácil para eles hospedarem seus próprios DNS e fornecerem esses valores aos seus clientes via DHCP. Par para o curso.
Gostaria de saber se outros usuários por aí podem estar enfrentando o mesmo problema
Provavelmente isso é algo específico da infraestrutura DNS da AT&T e aposto que depois que os servidores DNS terminarem as atualizações, eles ficarão bem.
Sei que posso resolver o problema sozinho usando o DNS do Google, mas
Você provavelmente já deveria fazer isso. A propósito, o novo serviço DNS da IBM é normalmente MUITO rápido:9.9.9.9