Кратко

  • В сохранённой 11 сентября версии перечня Hosted DNS находятся 48 строк AuthDNS: 43 действующих и пять выведенных из эксплуатации. Это воспроизводимый учёт инфраструктуры, а не число групп резолверов, для которых путь стал короче или устойчивее.
  • Региональные измерения самого RIPE NCC дают важный контрпример: узел в Бахрейне преимущественно обслуживал зонды из Саудовской Аравии, тогда как зонды в бахрейнской сети Batelco почти никогда его не выбирали.

Зелёная строка — хороший, но узкий документ

Статус «Operational» полезен. Он связывает номер узла, сервис, город, принимающую организацию, имя хоста и, когда оно указано, дату завершения. Отдельно помечаются площадки, которые уже выведены из эксплуатации. Для распределённой системы это содержательнее карты без дат и ответственных сторон.

В зафиксированном списке 48 записей AuthDNS. Действующими обозначены 43, ещё пять — как decommissioned. Узел #523 в Милане, размещённый LAKENETWORKS, завершён 18 июня 2026 года. Для #520 в Берлине у BCIX Management GmbH указано 28 июля. Квартальный план был обновлён 11 июня.

Эта последовательность дат не устанавливает причинную связь. Публичные документы не сообщают, когда начались две заявки, были ли они следствием пункта Q3 и какой измеренный пробел должен был закрыть каждый узел. Нет и опубликованного приёмочного результата после запуска.

Поэтому число 43 уверенно отвечает только на вопрос о количестве строк Hosted AuthDNS со статусом работы на дату снимка. Оно не показывает, сколько сетей доступа сменили предпочтительное anycast-направление, сколько резолверов получили меньшую задержку или сколько независимых путей переживут отказ.

План уже говорит на языке маршрутизации

В плане DNS and K-root на третий квартал 2026 года RIPE NCC обещает улучшать покрытие AuthDNS там, где сервис представлен недостаточно. Организация хочет находиться внутри крупной сети доступа страны, в сети, пирингующейся с крупными сетями доступа, либо на порту IXP, позволяющем соединяться с несколькими участниками. Работа имеет статус «In progress».

Это критерии топологии. Сеть доступа агрегирует пользователей и рекурсивные резолверы. Пиринг способен сделать локальный маршрут предпочтительным. Сервер маршрутов IXP может открыть одной инсталляции прямой путь к нескольким автономным системам. Почтовый адрес машины не доказывает ни одно из этих свойств.

На странице нет открытого знаменателя недостаточно охваченных стран или сетей, целевой когорты, порога задержки и срока, после которого результат считается принятым. Это не доказательство отсутствия внутренней инженерной методики. Это граница публичной проверяемости: читатель видит ввод узла, но не может пересчитать его вклад в заявленную цель.

У сервиса два разных слоя

AuthDNS анонсирует 193.0.9.0/24 и 2001:67c:e0::/48 из AS197000. Он обслуживает зоны обратного DNS под in-addr.arpa и ip6.arpa, ripe.net, инфраструктурные зоны других RIR, зоны поддерживаемых организаций и вторичный DNS для некоторых национальных доменов.

Публичная архитектура различает четыре основных площадки — Амстердам, Лондон, Стокгольм и Токио — и размещённые экземпляры. На основных площадках маршрутизатор распределяет запросы между несколькими серверами с BIND, Knot DNS и NSD. Hosted-слой дополняет их одиночными серверами в сетях провайдеров или на Internet Exchange.

Размещённый узел может сократить путь, не получив разнообразия серверов и программной реализации основной площадки. Надёжная основная площадка, в свою очередь, может не быть предпочтительным адресатом для конкретной группы резолверов. Узел, сервер, площадка, catchment и отказоустойчивость — разные единицы учёта.

Бахрейн показывает, где заканчивается география

Метод проверки RIPE NCC уже публиковал. В исследовании RIPE Labs 2024 года зонды RIPE Atlas в Юго-Восточной Европе, Центральной Азии и на Ближнем Востоке каждые 30 минут запрашивали у 193.0.9.7 имя 150.6.0.193.in-addr.arpa. Обработка определяла ответивший сервер и агрегировала наблюдения по зондам и дням, включая медиану RTT.

В Юго-Восточной Европе многие зонды попадали в Амстердам. Локальные узлы преобладали в Боснии и Герцеговине и особенно в Румынии, однако некоторые зонды устойчиво выбирали Канзас-Сити или Бахрейн. В Центральной Азии, где тогда, по данным исследования, не было узла AuthDNS, большинство запросов отвечали Амстердам или Стокгольм.

Самый ясный результат был получен в Манаме. Узел STC Bahrain физически находился в Бахрейне, но преимущественно использовался саудовскими зондами. Зонды в бахрейнской Batelco, AS5416, почти никогда его не достигали. Зонды Saudi Telecom Company, AS25019, выбирали его на протяжении всего окна. Для них это был и хороший маршрут: медиана ниже 50 мс против примерно 100 мс до Европы и существенно более длинных путей до Венесуэлы или Гуама.

Это не сообщение о неисправности. Оно показывает, что фактический продукт anycast — зона притяжения BGP. Размещение создаёт возможность, а анонсы, предпочтения, пиринг и транзит решают, какая аудитория ею воспользуется.

Пиринговая политика раскрывает механизм

AS197000 придерживается в целом открытой пиринговой политики. На основных и размещённых IXP-узлах AuthDNS принимает через серверы маршрутов префиксы не длиннее минимальных размеров IPv4 /24 и IPv6 /48 и анонсирует через них свои сети. RIPE NCC рекомендует route server и фильтрующие сообщества. Прямой пиринг рассматривается на определённых условиях; для Hosted-узла на IXP — там, где серверов маршрутов нет.

Поэтому одна установка может привлечь широкий круг сетей или остаться полезной более узкой группе, чем обещает карта. Имя принимающей организации не является списком пиров. В реестре нет построчного ASN хост-сети, фактического участия в route server, распределения входящих резолверов и изменения этого распределения после запуска.

Раскрывать всю топологию не нужно. Частный пиринг, быстро меняющиеся маршруты и чувствительные детали могут оставаться закрытыми. Нужен агрегированный документ о цели, методе и результате.

Кэширование уменьшает правильный знаменатель

FAQ Hosted DNS предупреждает: большинство DNS-запросов получает ответ из кэша. В хорошо связанной сети эффект локального узла может быть скромным или незаметным, поскольку лишь небольшая доля запросов к соответствующим зонам действительно достигает root или AuthDNS. Ускорение этого потока важно, но его нельзя превращать в обещание ускорить весь DNS или заметно сэкономить внешнюю полосу.

Ответственность тоже разделена. Хост предоставляет требуемый сервер или достаточную VM, профессиональную площадку, резервное питание, физическую безопасность и связь и несёт расходы. RIPE NCC управляет сервером удалённо. Если обнаружена проблема узла или доступности, сервер отзывает префикс, чтобы запросы пошли к другим DNS-серверам.

Withdraw меняет catchment, не перемещая оборудование. Новый пиринг делает это без нового сервера. Инвентарный и сетевой результаты живут по разным часам.

Второй документ для покрытия

Текущий перечень стоит сохранить. Рядом нужен компактный документ о покрытии для каждого узла или региональной кампании. Он может связать ID с исходным пробелом и агрегированной целевой когортой, назвать измерение RIPE Atlas, правило выбора и окно наблюдения, сравнить отвечающие узлы и задержки до и после активации, зафиксировать условие приёмки, исключения и ограничения выборки.

Адреса отдельных резолверов и частные peerings в нём не требуются. Важно развести пять выводов. Инвентарь подтверждает наличие экземпляра. Доступность — ответ с одной точки. Catchment — выбранный BGP адресат. Задержка — путь в заданный период. Устойчивость — то, что остаётся при исчезновении узла или маршрута. Число 43 не заменяет эти пять проверок.

Зелёные строки не обвиняют программу. Это уже хороший первый реестр, которому нужна вторая, ориентированная на результат часть.

Источники