Що відбувається з g.root-servers.net.?

Я щойно з’ясував, що 192.112.36.4( g.root-servers.net.) не відповідає ні на запити, ні на pings.

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

Я перевірив http://www.internic.net/domain/named.root , який є оновленим списком кореневих серверів і правильна IP-адреса. У мене завжди було враження, що ці кореневі сервери зайві до того, що неможливо, що є простої. За даними http://root-servers.org , у всьому світі існує шість локацій, де розміщені сервери, тож я би припустив, що я правдивий з цим припущенням.

Моє запитання, чи g.root-servers.net.якимось чином воно відрізняється від усіх інших, або спеціальне,
і якщо я ні з яких причин не отримаю відповідь DNS?

domain-name-system

— Даніель
джерело

G-root управляється американськими військовими.

— Майкл Хемптон

Отже, лише американські військові мають доступ до нього, або що ви хочете мені сказати?

— Даніель

Ви запитали, що в ньому відрізняється чи особливе.

— Майкл Хемптон

neither responds to requests, nor responds to pings- Пінг - це лише корисний інструмент, коли і якщо ви знаєте, що вам слід отримати відповідь від цілі. Ви заявляєте, що він не відповідає pings, означає, що ви думаєте, що вам слід отримати відповідь. Тепер, як виявляється, всі інші кореневі сервери відповідають на pings, тож це досить безпечне припущення, що має бути і g.root-servers.net, але все-таки це припущення. Використовуйте пінг лише тоді, коли ви абсолютно знаєте, що ціль повинна відповідати, інакше ви витрачаєте свій час, нахиляючись на вітряках.

— joeqwerty

FWIW, сервер g.root був в відповідь на DNS через TCP запити під час відключення електрики - це було тільки для UDP , що він був недоступний.

— Альнітак

Відповіді:

У мене завжди було враження, що ці кореневі сервери зайві до того, що неможливо, що є простої. За даними http://root-servers.org , у всьому світі існує шість локацій, де розміщені сервери, тож я би припустив, що я правдивий з цим припущенням.

Навіть якщо не було зареєстрованого відключення для G, це неправильне припущення:

IP-адреси Anycast можуть представляти кілька фізичних сайтів, але небажано, щоб події зловживань в одному регіоні перетворювались на збої в інших . Якщо сайт вивертається, цей трафік не збирається переносити на інший.
Спільні мережеві посилання, де є зловживання, спрямоване на кореневий сервер, можуть дуже задихатися, перш ніж інфраструктура наблизиться до кореневого сервера.

Нарешті, у нас є людська стихія. G був поперек борту , але офіційно не було оприлюднено причин того, чому в цей час. Поширений збій такого типу, як правило, вказує на навмисні дії або катастрофічний збій у центральній адміністрації.

Оскільки користувачі Serverfault не представляють адміністраторів кореневих серверів, найкраще слідкувати за офіційною заявою . Тим часом, наведене вище посилання є достатнім для того, щоб продемонструвати, що відбувся повний збій для G. Інтернет продовжував працювати, оскільки один корінь, який знаходиться вниз, не має суттєвого впливу на загальну картину.

Оновлення з 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

— Андрій Б
джерело

Я був з кимось із Ріпе на зустрічі вчора вдень, і моє перше враження після того, як вона показала мені проблеми, було те, що кореневі сервери страждали від неправильної конфігурації в брандмауері.

Те, що я помітив:

Відповіді TCP спрацювали чудово. ( 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 = обидва & dnsmon.isTcp = вірно )
Відповіді UDP були мертвими.
Усі зонди Ripe Atlas повідомили про одну і ту ж проблему. Проблема не була специфічною для одного регіону.
Маршрутизація BGP до мережі була просто чудова. Ніяких проблем там немає.

Той факт, що UDP не працював, а TCP працював, говорить про те, що хтось намагався блокувати пакети UDP вище певного розміру чи щось подібне.

Під час відключення я зробив кілька тестів, і всі тести UDP провалилися, не тільки тести, розмір відповіді яких перевищує 512 байт.

— принц Джан Хюго
джерело