Cosa sta succedendo con g.root-servers.net.?

Ho appena scoperto che 192.112.36.4( g.root-servers.net.) non risponde alle richieste, né risponde ai ping.

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

Ho controllato http://www.internic.net/domain/named.root , che è un elenco aggiornato di server root e l'indirizzo IP è corretto. Ho sempre avuto l'impressione che quei server root siano ridondanti al punto in cui è impossibile che ci siano tempi di inattività. Secondo http://root-servers.org ci sono sei località in tutto il mondo in cui si trovano i server, quindi presumo di essere corretto con tale presupposto.

La mia domanda è se g.root-servers.net.è in qualche modo diverso da tutti gli altri, o speciale,
e se non dovrei ottenere una risposta DNS da essa per nessun motivo?

domain-name-system

— Daniel
fonte

G-root è gestito dai militari statunitensi.

— Michael Hampton

Quindi solo l'esercito degli Stati Uniti ha accesso ad esso, o cosa vuoi dirmi?

— Daniel,

Hai chiesto cosa sia diverso o speciale a riguardo.

— Michael Hampton

neither responds to requests, nor responds to pings- Il ping è solo uno strumento utile quando e se sai che dovresti ottenere una risposta dal bersaglio. Stai affermando che non risponde ai ping implica che pensi che dovresti ottenere una risposta. Ora, a quanto pare, tutti gli altri server root rispondono ai ping, quindi è un presupposto abbastanza sicuro che anche g.root-servers.net dovrebbe, ma è comunque un presupposto. Usa il ping solo quando sai perfettamente che il bersaglio dovrebbe rispondere, altrimenti stai perdendo tempo inclinandoti ai mulini a vento.

— joeqwerty,

FWIW, il server g.root stava rispondendo alle richieste DNS su TCP durante l'interruzione - era solo per UDP che non era disponibile.

— Alnitak,

Risposte:

Ho sempre avuto l'impressione che quei server root siano ridondanti al punto in cui è impossibile che ci siano tempi di inattività. Secondo http://root-servers.org ci sono sei località in tutto il mondo in cui si trovano i server, quindi presumo di essere corretto con tale presupposto.

Anche se non ci fosse un'interruzione non documentata per G, questo è un presupposto errato:

Gli indirizzi IP Anycast possono rappresentare più siti fisici, ma non è auspicabile che gli eventi di abuso in una regione si trasformino in guasti in altre . Se un sito si inarca, quel traffico non verrà spostato in un altro.
I collegamenti di rete condivisi in cui è presente un abuso diretto a un server root possono essere molto soffocati prima dell'infrastruttura più vicina a un server root.

Infine, abbiamo l'elemento umano. G era giù a tutti i livelli , ma al momento non è stato reso noto il motivo per cui. Un fallimento diffuso di questo tipo indica tipicamente un'azione deliberata o un fallimento catastrofico nell'amministrazione centrale.

Dato che gli utenti di Serverfault non rappresentano gli amministratori dei server root, la cosa migliore da fare è cercare una dichiarazione ufficiale . Nel frattempo, il link sopra è sufficiente per dimostrare che c'è stata un'interruzione totale per G. Internet ha continuato a funzionare perché una radice inattiva non ha un impatto significativo nel quadro generale.

Aggiornamento dalla scheda di rete 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

Ero con qualcuno di Ripe in un incontro ieri pomeriggio, e la mia prima impressione dopo che mi aveva mostrato i problemi era che i rooterver avevano un errore di configurazione nel firewall.

Le cose che ho notato:

Le risposte TCP hanno funzionato bene. ( 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 )
Le risposte UDP erano morte.
Tutte le sonde Ripe Atlas hanno riportato lo stesso problema. Il problema non era specifico per una regione.
Il routing BGP verso la rete andava bene. Nessun problema lì.

Il fatto che UDP non abbia funzionato e TCP abbia funzionato suggerisce che qualcuno ha cercato di bloccare i pacchetti UDP al di sopra di una certa dimensione o qualcosa del genere.

Durante l'interruzione ho fatto diversi test e tutti i test UDP hanno fallito, non solo i test con una dimensione di risposta superiore a 512 byte.

— Jan Hugo Prins
fonte