Falha na propagação do DNS no mundo inteiro

Não alterei nada relacionado à entrada DNS do serverfault.com , mas alguns usuários relataram hoje que o DNS do serverfault.com não consegue resolver o problema .

Fiz uma consulta justping e posso confirmar isso - o serverfault.com dns parece não conseguir resolver em vários países, por nenhuma razão específica que eu possa discernir. (também confirmado pelo What's My DNS, que faz alguns pings em todo o mundo de maneira semelhante, por isso é confirmado como um problema por duas fontes diferentes.)

• Por que isso estaria acontecendo, se eu não toquei no DNS para serverfault.com?

• nosso registrador é (gag) GoDaddy e, na maioria das vezes, eu uso as configurações de DNS padrão sem incidentes. Estou fazendo algo errado? Os deuses do DNS me abandonaram?

• Existe algo que eu possa fazer para corrigir isso? Alguma maneira de adiantar o DNS ou forçá-lo a se propagar corretamente em todo o mundo?

Atualização: a partir de segunda-feira às 3:30 PST, tudo parece correto. O site de relatórios JustPing está acessível em todos os locais. Obrigado pelas muitas respostas muito informativas, eu aprendi muito e vou me referir a este Q na próxima vez que isso acontecer ..

Este não é um problema diretamente do DNS, é um problema de roteamento de rede entre algumas partes da Internet e os servidores DNS do serverfault.com. Como os servidores de nomes não podem ser alcançados, o domínio para de ser resolvido.

Pelo que sei, o problema de roteamento está no roteador (Global Crossing?) Com endereço IP 204.245.39.50.

Como mostrado por @radius , pacotes para ns52 (tal como utilizado por stackoverflow.com ) passar daqui para 208.109.115.121e a partir daí trabalhar correctamente. No entanto, os pacotes para o ns22 vão para 208.109.115.201.

Como esses dois endereços são os mesmos /24e o anúncio BGP correspondente também é para /24isso , isso não deve acontecer .

Eu fiz traceroutes através da minha rede que, em última análise, usa o MFN Above.net em vez do Global Crossing para acessar o GoDaddy e não há sinais de truques de roteamento abaixo do /24nível - ambos os servidores de nomes têm traceroutes idênticos a partir daqui.

As únicas vezes em que vi algo parecido com isso foram o Cisco Express Forwarding (CEF). Este é um cache no nível do hardware usado para acelerar o roteamento de pacotes. Infelizmente, ocasionalmente, fica fora de sincronia com a tabela de roteamento real e tenta encaminhar pacotes pela interface errada. As entradas CEF podem descer para o /32nível mesmo que a entrada da tabela de roteamento subjacente seja para a /24. É difícil encontrar esse tipo de problema, mas uma vez identificados, normalmente são fáceis de corrigir.

Enviei um e-mail para a GC e também tentei falar com eles, mas eles não criarão um ticket para não-clientes. Se algum de vocês é cliente da GC, tente e relate isso ...

ATUALIZAÇÃO às 10:38 UTC Como Jeff observou, o problema foi resolvido. Os rastreadores para os dois servidores mencionados acima agora passam pelo 208.109.115.121próximo salto.

seus servidores DNS para serverfault.com [ns21.domaincontrol.com, ns22.domaincontrol.com. ] são inacessíveis. nas últimas 20 horas, pelo menos de alguns dos principais provedores da Suécia [ telia , tele2 , bredband2 ].

ao mesmo tempo, os servidores DNS 'vizinhos' para stackoverflow.com e superuser.com [ns51.domaincontrol.com, ns52.domaincontrol.com] são acessíveis.

exemplo de rastreamento para 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          

e para 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. ???

talvez tenha estragado a filtragem / alguém tenha acionado alguma proteção indesejada de ddos ​​e colocado na lista negra algumas partes da internet. provavelmente você deve entrar em contato com seu provedor de serviços de DNS - vá pai.

você pode verificar se o problema é [parcialmente] resolvido por:

1. verificando se godaddy reagiu e alterou os servidores de nomes - por exemplo, consulta serverfault.com em http://www.squish.net/dnscheck/ usando o tipo de recort: ANY
2. verifique se os servidores de nomes fornecidos respondem ao ping [não muito científico, pois os servidores de nomes podem funcionar bem e ainda bloquear o icmp, mas neste caso parece que o icmp é permitido para outros servidores] da telia através do espelho .

editar : traceroutes de locais de trabalho

Polônia

 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              

Alemanha

 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       

edit : tudo funciona bem agora, de fato.

Minhas sugestões: como explicado por Alnitak, o problema não é DNS, mas roteamento (provavelmente BGP). O fato de nada ter sido alterado na configuração do DNS é normal, pois o problema não estava no DNS.

O serverfault.com hoje possui uma configuração de DNS muito ruim, certamente insuficiente para um site importante como este:

• apenas dois servidores de nomes
• todos os ovos na mesma cesta (ambos estão no mesmo AS)

Acabamos de ver o resultado: uma falha de roteamento (algo bastante comum na Internet) é suficiente para fazer o serverfault.com desaparecer para alguns usuários (dependendo de seus operadores, não de seus países).

Sugiro adicionar mais servidores de nomes, localizados em outro AS. Isso permitiria resiliência a falhas. Você pode alugá-los para empresas privadas ou solicitar que os usuários com falha no servidor ofereçam hospedagem DNS secundária (pode ser apenas se o usuário tiver> 1000 representantes :-)

Confirmo que NS21.DOMAINCONTROL.COM e NS22.DOMAINCONTROL.COM também são inacessíveis do ISP Free.fr na França.
Como o pQd traceroute, o meu também termina após 208.109.115.201 para os ns21 e 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  * * *

Mas o ns52.domaincontrol.com (208.109.255.26) funciona e está na mesma sub-rede que o 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 você pode ver, desta vez após 204.245.39.50, vamos para 208.109.115.121 em vez de 208.109.115.201. E o pQd tem o mesmo traceroute. De um local de trabalho, não atravessei esse roteador 204.245.39.50 (Global Crossing).

Mais traceroute do local de trabalho e do não trabalho ajudaria, mas é altamente provável que a Global Crossing tenha uma entrada de roteamento falsa para 208.109.255.11/32 e 216.69.185.11/32 como 208.109.255.10, 208.109.255.12, 216.69.185.10, 216.69. 185.12 estão funcionando bem.

É difícil saber por que ela tem uma entrada de roteamento bloqueada. Provavelmente 208.109.115.201 (Go Daddy) está anunciando uma rota não útil para 208.109.255.11/32 e 216.69.185.11/32.

EDIT: Você pode telnet route-server.eu.gblx.net para conectar-se ao servidor de rota Global Crossing e fazer traceroute a partir da rede Global Crossing

EDIT: Parece que o mesmo problema já ocorreu com outros NS há alguns dias, consulte: http://www.newtondynamics.com/forum/viewtopic.php?f=9&t=5277&start=0

O que seria útil seria ver um rastreamento detalhado da resolução nos locais que estão falhando ... veja em qual camada do caminho da resolução está falhando. Não estou familiarizado com o serviço que você está usando, mas talvez seja uma opção em algum lugar.

Na falta disso, é mais provável que os problemas estejam "mais abaixo" na árvore, pois falhas na raiz ou nos TLDs afetariam mais domínios (você esperaria). Para aumentar a resiliência, você pode delegar para um segundo serviço DNS para garantir melhor redundância na resolução, se houver problemas com a (s) rede (s) do controle de domínio.

Estou surpreso por você não hospedar seu próprio DNS. A vantagem de fazê-lo dessa maneira é se o DNS estiver acessível, assim como (espero) o seu site.

Na UPC, pelo menos, recebo essa reação ao tentar obter seu registro A no servidor autoritário (ns21.domaincontrol.com).

; <<>> DiG 9.5.1-P2 <<>> @ns21.domaincontrol.com serverfault.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38663
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;serverfault.com.       IN  A

;; Query time: 23 msec
;; SERVER: 216.69.185.11#53(216.69.185.11)
;; WHEN: Sun Jul 19 12:09:40 2009
;; MSG SIZE  rcvd: 33

Quando tento a mesma coisa em uma máquina em uma rede diferente (OVH), recebo uma resposta

; <<>> DiG 9.4.2-P2 <<>> @216.69.185.11 serverfault.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33998
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;serverfault.com.               IN      A

;; ANSWER SECTION:
serverfault.com.        3600    IN      A       69.59.196.212

;; AUTHORITY SECTION:
serverfault.com.        3600    IN      NS      ns21.domaincontrol.com.
serverfault.com.        3600    IN      NS      ns22.domaincontrol.com.

;; Query time: 83 msec
;; SERVER: 216.69.185.11#53(216.69.185.11)
;; WHEN: Sun Jul 19 12:11:05 2009
;; MSG SIZE  rcvd: 101

Eu recebo um comportamento semelhante para alguns outros domínios, então suponho que o UPC (pelo menos) esteja silenciosamente redirecionando consultas DNS para seu próprio servidor de nomes de cache e falsificando as respostas. Se o seu DNS se comportar mal brevemente, isso pode explicar o fato de os servidores de nomes da UPC estarem em cache a resposta NXDOMAIN.