Co się dzieje z g.root-servers.net.?

Właśnie odkryłem, że 192.112.36.4( g.root-servers.net.) ani nie odpowiada na żądania, ani na pingi.

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

Sprawdziłem http://www.internic.net/domain/named.root , która jest listą serwerów głównych up2date, a adres IP jest poprawny. Zawsze miałem wrażenie, że te serwery root są nadmiarowe do tego stopnia, że nie ma możliwości przestoju. Według http://root-servers.org istnieje sześć lokalizacji na całym świecie, w których zlokalizowane są serwery, więc zakładam, że zgadzam się z tym założeniem.

Moje pytanie brzmi: czy g.root-servers.net.w jakikolwiek sposób różni się od wszystkich innych, czy jest wyjątkowy,
i czy mam otrzymać odpowiedź DNS z jakiegokolwiek powodu?

domain-name-system

— Daniel
źródło

G-root jest prowadzony przez wojsko USA.

— Michael Hampton

Czyli tylko wojsko USA ma do niego dostęp, a co chcesz mi powiedzieć?

— Daniel

Zapytałeś, co jest w tym specjalnego lub specjalnego.

— Michael Hampton

neither responds to requests, nor responds to pings- Ping jest użytecznym narzędziem tylko wtedy, gdy wiesz, że powinieneś otrzymać odpowiedź od celu. Twoje stwierdzenie, że nie reaguje na pingi oznacza, że uważasz, że powinieneś otrzymać odpowiedź. Teraz, jak się okazuje, wszystkie inne serwery root reagują na pingi, więc jest to całkiem bezpieczne założenie, że g.root-servers.net powinien również, ale to założenie. Używaj polecenia ping tylko wtedy, gdy absolutnie wiesz, że cel powinien zareagować, w przeciwnym razie marnujesz czas na przechylanie wiatraków.

— joeqwerty 14.04.16

FWIW serwer g.root został odpowiadając na żądania DNS TCP podczas przerwy - to było tylko dla UDP, że był niedostępny.

— Alnitak,

Odpowiedzi:

Zawsze miałem wrażenie, że te serwery root są nadmiarowe do tego stopnia, że nie ma możliwości przestoju. Według http://root-servers.org istnieje sześć lokalizacji na całym świecie, w których zlokalizowane są serwery, więc zakładam, że zgadzam się z tym założeniem.

Nawet gdyby nie było nieudokumentowanego wyłączenia dla G, jest to błędne założenie:

Adresy IP Anycast mogą reprezentować wiele fizycznych witryn, ale niepożądane zdarzenia w jednym regionie mogą kaskadować się w awarie w innych . Jeśli witryna się zawiesi, ruch ten nie zostanie przeniesiony na inny.
Udostępniane łącza sieciowe, w których występują nadużycia skierowane na serwer główny, mogą się bardzo udławić, zanim infrastruktura bliżej serwera głównego.

Wreszcie mamy element ludzki. G był na całej planszy , ale w tej chwili nie ma oficjalnie ujawnionego powodu. Powszechna tego typu porażka zwykle wskazuje na celowe działanie lub katastrofalną awarię w administracji centralnej.

Ponieważ użytkownicy Serverfault nie reprezentują administratorów serwerów głównych, najlepszym rozwiązaniem jest zwrócenie uwagi na oficjalne oświadczenie . W międzyczasie powyższy link jest wystarczający, aby wykazać, że nastąpiła całkowita awaria G. Internet nadal działał, ponieważ wyłączenie jednego roota nie ma znaczącego wpływu na szerszy obraz.

Aktualizacja z DoD NIC:

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.
źródło

Byłem z kimś z Ripe na spotkaniu wczoraj po południu, a moje pierwsze wrażenie po tym, jak pokazała mi problemy, polegało na tym, że rootserver cierpiał z powodu błędnej konfiguracji zapory.

Rzeczy, które zauważyłem:

Odpowiedzi TCP działały dobrze. ( 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 = zarówno & dnsmon.isTcp = true )
Odpowiedzi UDP były martwe.
Wszystkie dojrzałe sondy Atlas zgłosiły ten sam problem. Problem nie był specyficzny dla jednego regionu.
Routing BGP do sieci był w porządku. Nie ma tam problemów.

Fakt, że UDP nie działał i działał TCP, sugeruje, że ktoś próbował zablokować pakiety UDP powyżej określonego rozmiaru lub coś w tym rodzaju.

Podczas awarii wykonałem kilka testów i wszystkie testy UDP zakończyły się niepowodzeniem, nie tylko testy o rozmiarze odpowiedzi większym niż 512 bajtów.

— Jan Hugo Prins
źródło