O que está acontecendo com o g.root-servers.net.?

Acabei de descobrir que 192.112.36.4( g.root-servers.net.) não responde a solicitações nem responde a pings.

.                        3600000      NS    G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4

Eu verifiquei http://www.internic.net/domain/named.root , que é uma lista up2date de servidores raiz e o endereço IP está correto. Eu sempre tive a impressão de que esses servidores raiz são redundantes ao ponto em que é impossível que haja tempo de inatividade. De acordo com http://root-servers.org, existem seis locais em todo o mundo onde os servidores estão localizados, então eu suponho que estou correto com essa suposição.

Minha pergunta é se g.root-servers.net.é de alguma forma diferente de todas as outras, ou especiais,
e se devo receber uma resposta de DNS por algum motivo?

domain-name-system

— Daniel
fonte

A raiz G é administrada pelos militares dos EUA.

— Michael Hampton

Então, apenas os militares dos EUA têm acesso a ele, ou o que você quer me dizer?

— Daniel

Você perguntou o que é diferente ou especial sobre isso.

— Michael Hampton

neither responds to requests, nor responds to pings- O ping é apenas uma ferramenta útil quando e se você souber que deve receber uma resposta do alvo. Sua afirmação de que ela não responde aos pings implica que você acha que deve obter uma resposta. Agora, como todos os outros servidores raiz respondem aos pings, é uma suposição bastante segura que o g.root-servers.net também deveria, mas essa é uma suposição. Use o ping apenas quando você souber que o alvo deve responder, caso contrário, estará perdendo tempo inclinando-se nos moinhos de vento.

— joeqwerty

FWIW, o servidor g.root estava respondendo às solicitações DNS sobre TCP durante a interrupção - era apenas para o UDP que ele não estava disponível.

— Alnitak

Respostas:

Eu sempre tive a impressão de que esses servidores raiz são redundantes ao ponto em que é impossível que haja tempo de inatividade. De acordo com http://root-servers.org, existem seis locais em todo o mundo onde os servidores estão localizados, então eu suponho que estou correto com essa suposição.

Mesmo que não houvesse uma interrupção indevida para G, essa é uma suposição incorreta:

Os endereços IP do Anycast podem representar vários sites físicos, mas é indesejável que eventos de abuso em uma região se transformem em falhas em outras . Se um site ceder, esse tráfego não será transferido para outro.
Os links de rede compartilhados nos quais estão presentes os abusos direcionados a um servidor raiz podem se sufocar muito antes da infraestrutura mais próxima de um servidor raiz.

Por fim, temos o elemento humano. G caiu de cabeça para baixo , mas não há nenhuma razão oficialmente divulgada para isso no momento. Uma falha generalizada desse tipo normalmente aponta para uma ação deliberada ou uma falha catastrófica na administração central.

Como os usuários do Serverfault não representam os administradores dos servidores raiz, sua melhor aposta é prestar atenção a uma declaração oficial . Enquanto isso, o link acima é suficiente para demonstrar que houve uma interrupção total de G. A internet continuou a funcionar porque uma raiz em queda não tem um impacto significativo no cenário geral.

Atualização da NIC do DoD:

Regarding yesterday's G-root outage:

Like many outages, this one resulted from a series of unfortunate events.
These unfortunate events were operational errors;  steps have been taken to
prevent any reoccurrence, and to provide better service in the future.

https://lists.dns-oarc.net/pipermail/dns-operations/2016-April/014765.html

— Andrew B
fonte

Eu estava com alguém de Ripe em uma reunião ontem à tarde, e minha primeira impressão depois que ela me mostrou os problemas foi que os servidores de raiz sofreram de uma configuração incorreta no firewall.

As coisas que eu notei:

As respostas do TCP funcionaram bem. ( https://atlas.ripe.net/dnsmon/group/root?dnsmon.session.color_range_pls=0-66-66-99-100&dnsmon.session.exclude-errors=true&dnsmon.type=server-probes&dnsmon.server=192.112 .36.4 & dnsmon.zone = root & dnsmon.startTime = 1460573400 & dnsmon.endTime = 1460649600 & dnsmon.ipVersion = both & dnsmon.isTcp = true )
As respostas do UDP estavam mortas.
Todas as sondas Ripe Atlas relataram o mesmo problema. O problema não era específico para uma região.
O roteamento BGP em direção à rede foi ótimo. Sem problemas lá.

O fato de o UDP não funcionar e o TCP funcionar sugere que alguém tentou bloquear pacotes UDP acima de um determinado tamanho ou algo parecido.

Durante a interrupção, fiz vários testes e todos os testes UDP falharam, não apenas testes com um tamanho de resposta maior que 512 bytes.

— jan hugo prins
fonte