eu não mudeiqualquer coisarelacionado à entrada DNS para serverfault.com, mas alguns usuários relataram hoje queo DNS serverfault.com não consegue resolvê-los.
Eu corri umconsulta justae posso confirmar isso - o DNS do serverfault.com parece não estar conseguindo resolver em alguns países, por nenhuma razão específica que eu possa discernir. (também confirmado viaQual é o meu DNSque faz alguns pings em todo o mundo de maneira semelhante, por isso foi confirmado como um problema por duas fontes diferentes.)
Por que isso estaria acontecendo se eu não toquei no DNS de serverfault.com ?
nosso registrador é (gag) GoDaddy, e eu uso as configurações de DNS padrão na maior parte do tempo sem incidentes. Estou fazendo algo errado? Os deuses do DNS me abandonaram?
há algo que eu possa fazer para corrigir isso? Existe alguma maneira de impulsionar o DNS ou forçar o DNS a se propagar corretamente em todo o mundo?
Atualização: a partir de segunda-feira às 3h30 PST, tudo parece correto. O site de relatórios JustPing pode ser acessado de todos os locais. Obrigado pelas muitas respostas muito informativas, aprendi muito e irei me referir a este Q na próxima vez que isso acontecer.
Responder1
Este não é diretamente um problema de 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.
Comomostrandopor@raio, pacotes para ns52 (conforme usado porstackoverflow.com) passam daqui para 208.109.115.121lá e funcionam corretamente. No entanto, os pacotes para ns22 vão para 208.109.115.201.
Como esses dois endereços são iguais /24e o anúncio BGP correspondente também é para /24estenão deveria acontecer.
Eu fiz traceroutes através da minha rede, que usa MFN Above.net em vez de Global Crossing para chegar ao GoDaddy e não há sinal de qualquer truque de roteamento abaixo do /24nível - ambos os servidores de nomes têm traceroutes idênticos a partir daqui.
As únicas vezes que vi algo assim estava quebradoEncaminhamento Expresso Cisco(CEF). Este é um cache de nível de hardware usado para acelerar o roteamento de pacotes. Infelizmente, apenas ocasionalmente ele fica fora de sincronia com a tabela de roteamento real e tenta encaminhar pacotes através da interface errada. As entradas CEF podem descer para o /32nível mesmo se a entrada da tabela de roteamento subjacente for para um arquivo /24. É complicado encontrar esse tipo de problema, mas uma vez identificados, eles normalmente são fáceis de corrigir.
Mandei um e-mail para o GC e também tentei falar com eles, mas eles não criam ticket para não clientes. Se algum de vocêssãoum cliente da GC, tente relatar isso...
ATUALIZAÇÃO às 10:38 UTC Como Jeff observou, o problema foi resolvido. Os rastreamentos para ambos os servidores mencionados acima agora passam pelo 208.109.115.121próximo salto.
Responder2
seus servidores DNS para serverfault.com [ns21.domaincontrol.com, ns22.domaincontrol.com. ] estão inacessíveis. nas últimas aproximadamente 20h, pelo menos de alguns grandes provedores da Suécia [telia,tele2,banda2].
ao mesmo tempo, servidores DNS 'vizinhos' para stackoverflow.com e superuser.com [ns51.domaincontrol.com, ns52.domaincontrol.com] estão acessíveis.
exemplo de traceroute 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 acionou alguma proteção contra ddos indesejada e colocou algumas partes da Internet na lista negra. provavelmente você deveria entrar em contato com seu provedor de serviços de DNS - vá, papai.
você pode verificar se o problema foi [parcialmente] resolvido por:
- verificando se godaddy reagiu e mudou os servidores de nomes - por exemplo, procure serverfault.com emhttp://www.squish.net/dnscheck/usando tipo de registro: QUALQUER
- 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 viaespelho.
editar: traceroutes dos 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
editar: tudo funciona bem agora, de fato.
Responder3
Minhas sugestões: conforme 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.
serverfault.com tem hoje 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 com que serverfault.com desapareça para alguns usuários (dependendo de suas operadoras, não de seus países).
Sugiro adicionar mais servidores de nomes, localizados em outros AS. Isso permitiria resiliência a falhas. Você pode alugá-los para empresas privadas ou pedir aos usuários serverfault que ofereçam hospedagem DNS secundária (pode ser apenas se o usuário tiver> 1000 representantes :-)
Responder4
O que seria útil seria ver um rastreamento detalhado da resolução dos locais que estão falhando... ver em qual camada do caminho de 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.
Caso contrário, é 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) de controle de domínio.