Что происходит с g.root-servers.net.?

Я только что узнал, что 192.112.36.4( g.root-servers.net.) не отвечает ни на запросы, ни на пинг.

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

Я проверил http://www.internic.net/domain/named.root , который представляет собой список корневых серверов up2date, и IP-адрес правильный. У меня всегда было впечатление, что эти корневые серверы избыточны до такой степени, что невозможно простои. Согласно http://root-servers.org , во всем мире есть шесть мест, где расположены серверы, поэтому я предполагаю, что я прав в этом предположении.

У меня вопрос, отличается ли g.root-servers.net.он от всех остальных или особенный,
и если я по какой-либо причине не должен получить от него ответ DNS?

domain-name-system

— Даниил
источник

G-root находится в ведении военных США.

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

Так что только американские военные имеют к нему доступ, или что вы хотите мне сказать?

— Даниэль

Вы спросили, что в этом особенного или особенного.

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

neither responds to requests, nor responds to 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

— Андрей Б
источник

Я был с кем-то из Ripe на встрече вчера днем, и мое первое впечатление после того, как она показала мне проблему, было то, что корневые серверы пострадали от неправильной конфигурации в брандмауэре.

Вещи, которые я заметил:

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 = both & dnsmon.isTcp = true )
Ответы UDP были мертвы.
Все зонды Ripe Atlas сообщили об одной и той же проблеме. Проблема не была характерна для одного региона.
BGP маршрутизация к сети была просто прекрасна. Там нет проблем.

Тот факт, что UDP не работает, а TCP работает, говорит о том, что кто-то пытался заблокировать пакеты UDP выше определенного размера или что-то в этом роде.

Во время сбоя я провел несколько тестов, и все тесты UDP не прошли, а не только тесты с размером ответа больше 512 байт.

— Джан Хьюго Принс
источник