A resolução de DNS para meu domínio às vezes funciona, às vezes SERVFAIL

Question

Ontem eu mudei de hospedagem DNS para o domínio bagtheweb.com de Godaddy para CloudFlare. A Cloudflare afirma que a transferência foi bem-sucedida e a resolução de DNS funciona bem em todos os lugares EXCETO do meu escritório. Às vezes funciona, às vezes recebo respostas do SERVFAIL usando dig bagtheweb.com .

Meu computador de escritório está usando meu gateway AT & T para DNS. Eu olhei para o painel de controle do gateway e ele diz que está usando 68.94.156.9 e 68.94.157.9 para o DNS.

Eu tentei cavar usando esses dois resolvedores de DNS diretamente: dig @68.94.156.9 bagtheweb.com e dig @68.94.157.9 bagtheweb.com .

Aproximadamente metade do tempo que o resultado é bom (vejo registros A apontando para endereços IP) e metade do tempo recebo respostas SERVFAIL. Eu tentei um monte de vezes e eu continuo vendo as duas respostas aparentemente aleatoriamente. Já faz 20 horas desde que fiz a transferência e ainda estou vendo isso.

Eu tentei cavar os servidores DNS da CloudFlare theo.ns.cloudflare.com. e vita.ns.cloudflare.com. e funciona muito bem todas as vezes. Eu também tentei cavar o servidor DNS do Google 8.8.8.8 também funciona perfeitamente.

Portanto, a minha única conclusão é que o AT & A é uma droga, e cada um desses IPs do servidor DNS é apoiado por um conjunto de servidores, alguns que são atualizados corretamente e outros são confusos. Espero que 24 horas seja o limite mágico para os servidores ruins atualizarem.

Alguma idéia do porquê isso está acontecendo? Há mais alguma coisa que eu possa fazer para investigar ou forçar uma atualização (além de ligar para AT & T e desperdiçar 4 horas da minha vida)? Existe algo que eu poderia ter feito antes da transferência de zona para eliminar este problema? Eu sei que posso resolver o problema usando o DNS do Google, mas gostaria de saber se outros usuários por aí poderiam estar com o mesmo problema.

2 comandos de voltar para trás:

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

    

Answer 1

Is there anything else I can do to investigate or force an update (besides call AT&T and waste 4 hours of my life)?

Não. Você fez sua parte configurando os registros com o provedor e o provedor realizou a transferência de zona solicitada.

Is there something I could have done before the zone transfer to eliminate this problem?

Talvez? Você pode ter conseguido definir um TTL REALMENTE baixo, como 5 minutos, mas mesmo isso precisa ser replicado em toda a infra-estrutura do DNS antes que seja realmente importante.

AT&T sucks

É mais específico que a maior parte do DNS hospedado pelo ISP seja geralmente uma porcaria. Eles não são construídos para a velocidade, mas para ajudar a eliminar a transferência desnecessária de dados através de outras redes (que normalmente custa dinheiro); o que significa cache muito grande e pesado. Também é mais fácil para eles hospedar seu próprio DNS e fornecer esses valores para seus clientes via DHCP. Par do curso.

I wonder if other users out there could be experiencing the same problem

Isso é algo específico da infraestrutura de DNS da AT & T e estou apostando que depois que os servidores DNS concluírem suas atualizações, eles ficarão bem.

I know that I can fix the problem for myself by using Google's DNS, but

Você provavelmente já deve fazer isso. A propósito, o novo serviço DNS da IBM normalmente é MUITO rápido: 9.9.9.9