Кратко

  • UIXP перечисляет две сети DNS AFRINIC, напрямую подключённые к пиринговой сети: AFDSP/NS2 под AS37177 и DotARPA под AS37181. Руководство AFRINIC назначает каждой собственные префиксы IPv4 и IPv6.
  • NS2 предоставляет вторичный DNS и не определяет содержимое зоны. DotARPA относится к отдельной цепочке обратного DNS. Наблюдение одной службы ничего автоматически не доказывает о другой.
  • Каталоги UIXP и PeeringDB, а также RDAP подтверждают идентификаторы и интерфейс обмена. Они не подтверждают текущее объявление BGP, участие в route server, локальное попадание запроса, задержку, доступность или устойчивость.
  • Проверяемая квитанция нужна для каждой службы отдельно: ASN, объявленные префиксы, способ пиринга, состояние запуска и здоровья, обслуживаемые пространства имён, точка наблюдения, ответивший экземпляр и время.

Две строки на одной площадке

UIXP сообщает, что сети в каталоге напрямую подключены к его peering LAN. Строка «AFRINIC - DNS - AFDSP» содержит ASN 37177, открытую политику пиринга и 2025 год как год присоединения. Отдельная строка «AFRINIC - DNS - DotARPA» содержит ASN 37181, ту же общую политику и тот же год. Организация одна, но сетевые идентификаторы и названия служб различаются.

На той же странице UIXP устанавливает важное ограничение: чтобы выяснить, использует ли сеть серверы маршрутов и какие префиксы объявляет, надо обратиться к looking glass. Каталог не является снимком BGP. Он показывает интерфейс, через который можно обмениваться маршрутами, но не состояние сессии в конкретный момент, не фильтры, не принявших маршрут соседей и не путь, который получит определённый резолвер.

Публичный API PeeringDB даёт второй каталоговый ракурс. В зафиксированных данных обе автономные системы присутствуют на UIXP с идентификатором ix_id 422. У AS37177 адреса peering LAN заканчиваются на .5 в IPv4 и на ::5 в IPv6. У AS37181 окончания .6 и ::6. Это адреса для обмена маршрутами на IXP, а не Anycast-префиксы самой DNS-службы.

Два типа адресов отвечают на разные вопросы. Пиринговый адрес показывает, где могут разговаривать маршрутизаторы. Сервисный префикс показывает, какая цель может стать достижимой в результате этого разговора. Смешение превращает зарегистрированный интерфейс в мнимое доказательство того, что служба объявлена, здорова и отвечает.

Публичная карта вправе показать партнёрскую площадку одной отметкой в Кампале. Операционный журнал должен сохранить две строки. Именно расхождение между ними станет первым полезным сигналом, если одна служба продолжит работать, а другая нет.

AS37177 ведёт к NS2

Руководство AFRINIC связывает NS2 с AS37177, префиксом IPv4 196.216.168.0/24 и префиксом IPv6 2001:43f8:120::/48. Страница программы описывает эту сеть как Anycast-инфраструктуру для вторичного обслуживания африканских национальных доменов и других региональных задач DNS.

Слово «вторичный» обозначает границу полномочий. AFRINIC описывает AfDSP как secondary, или в старой терминологии slave DNS. Данные зоны передаются с первичного сервера. AFRINIC не управляет содержимым зоны. Служба может давать дополнительную авторитетную копию и распределённый путь ответа, но не получает право определять имена и ресурсные записи.

Такое разделение не уменьшает ценность NS2. Корректно работающая вторичная копия может добавить путь доступности и изолировать часть отказов. Различие нужно, чтобы не смешивать полномочия над содержимым и доставкой. Если неверны данные зоны, расследование начинается с первичного источника и трансфера; если копия не отвечает — с приложения, маршрута и хостовой инфраструктуры.

Поэтому эта статья не повторяет подсчёт размещённых ccTLD. Реестр зон отвечает, какие делегации или адреса связываются с префиксами NS2. Вопрос UIXP другой: видны ли сервисные префиксы AS37177 через угандийскую точку обмена, какие сети их получают и какие запросы действительно доходят до местного экземпляра. Принадлежность зоны к службе не доказывает состояние отдельного сайта.

RDAP AFRINIC связывает AS37177 и опубликованные блоки с организационной записью AFRINIC. Это устойчивое доказательство регистрационной идентичности, а не живая маршрутизационная телеметрия. RDAP не показывает, были ли 196.216.168.0/24 или 2001:43f8:120::/48 видимы в looking glass UIXP при сборе материалов. Он не называет route server, двустороннюю сессию или экземпляр, ответивший на запрос.

Между идентификатором и DNS-ответом несколько переходов: префикс объявлен, сосед его принял, политика выбрала путь, Anycast направил пакет к экземпляру, приложение здорово, требуемая зона загружена. Открытые страницы хорошо объясняют идентификаторы. Они не позволяют перескочить через ненаблюдаемые переходы.

AS37181 ведёт к DotARPA

Для DotARPA руководство публикует другой набор: AS37181, IPv4 196.216.169.0/24 и IPv6 2001:43f8:110::/48. Значения похожи на NS2, но не совпадают. Близость чисел помогает сделать компактную таблицу и одновременно повышает риск ошибки при копировании. Она не создаёт операционного единства.

Функция тоже иная. AFRINIC связывает AS37181 с инфраструктурой обратного DNS, описанной в RFC 5855. Этот документ ввёл отдельные идентификаторы серверов для IN-ADDR.ARPA и IP6.ARPA. Разделение убирает ненужные общие зависимости с прочими функциями DNS, чтобы посторонний сбой не становился сопутствующим отказом обратного дерева. Отдельный ASN и собственные префиксы делают границу заметной в маршрутизации.

Из этого не следует, что любой PTR-запрос из Африки попадёт в данный экземпляр. DNS следует делегациям, перенаправлениям и кэшам. Anycast добавляет выбор экземпляра по маршрутам, видимым от источника. Результат зависит от имени, состояния кэша резолвера, маршрутной политики и здоровья выбранного сервера.

DotARPA нельзя смешивать и с копией корневого сервера. AFRINIC описывает отдельную программу root-server-copy как содействие размещению копий, которыми управляют организации корневых серверов, и не называет себя оператором копии. У программ может быть общая цель распределения критичной DNS-инфраструктуры, но это не переносит полномочия и эксплуатационную ответственность.

RDAP и PeeringDB подтверждают публичную идентичность AS37181 и его интерфейс на UIXP. Они не показывают живой маршрут или ответ. Практическое правило просто: успешный запрос NS2 под AS37177 не заполняет поле здоровья DotARPA, а маршрут AS37181 ничего не говорит о NS2.

В Anycast слово «локальный» требует точки и времени

Anycast позволяет нескольким экземплярам объявлять один сервисный адрес, после чего маршрутизация выбирает экземпляр для каждого источника. Это распределяет службу без выбора площадки клиентом, но придаёт фразе «служба находится в Уганде» несколько разных смыслов.

В стране может стоять физическая или виртуальная машина. ASN может иметь интерфейс на UIXP. Угандийская сеть может получать сервисные префиксы. Запрос определённого резолвера может быть обработан угандийским экземпляром. Все четыре утверждения связаны, но не равны. Машина может существовать без объявления; маршрут — оставаться при отказе приложения; здоровое приложение — не выбираться политикой сети; кэш — вообще не допустить обращения к авторитетному серверу.

RFC 4786 явно разделяет BGP-достижимость и здоровье приложения. Если DNS-процесс остановился, а префикс продолжает объявляться, маршрутизация эффективно доставит трафик в неработающий экземпляр. Поэтому оператору нужна связь между проверкой здоровья и отзывом маршрута либо другим способом прекратить привлечение запросов. Зелёный статус BGP не является тестом DNS.

Возможна и обратная асимметрия. Приложение здорово, но локальная сеть не учит маршрут, потому что не пользуется route server, не установила двустороннюю сессию, фильтрует префикс или предпочитает другой путь. Anycast не гарантирует географически ближайшую площадку. Он выбирает согласно топологии и политикам, которые видит BGP.

RFC 7094 поэтому рассматривает выбор экземпляра и производительность как задачу распределённых измерений. Looking glass показывает представление одного коллектора. Один DNS-запрос показывает опыт одного источника в одну минуту. Для регионального вывода нужны разные точки, повторение во времени и способ определить ответивший экземпляр. Без идентификатора низкая задержка не доказывает Уганду; без временного ряда единичный успех не доказывает доступность.

AFRINIC называет производительность и устойчивость целями программы. Архитектура делает такие эффекты правдоподобными. Но зафиксированный пакет источников не содержит сравнения до и после UIXP, испытания переключения, ряда uptime или распределения запросов по площадкам. Он не доказывает отсутствие пользы и не доказывает измеренную пользу. Цель, подключение и результат должны храниться в разных полях.

Ответственность также разделена

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

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

Если маршрут остаётся при отказе DNS, надо проверить сигнал здоровья и логику отзыва, хотя причина может быть в программе, виртуализации, питании или связи. Если DNS здоров, а участник не получает маршрут, важны сессия, route server, фильтр и политика. Если NS2 отвечает, а DotARPA нет, общий индикатор «узел работает» скрывает половину события. Если IPv4 работает, а IPv6 нет, уровень ASN тоже слишком агрегирован.

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

Пять слоёв доказательств не заменяют друг друга

Открытые записи удобно разделить на пять слоёв. Документы программы объясняют цель и конструкцию. RDAP объясняет регистрацию ресурсов. UIXP и PeeringDB объясняют заявленный интерфейс обмена. Looking glass и RIB участников могли бы объяснить наблюдавшиеся маршруты. Измерения DNS могли бы объяснить запросы, ответы и экземпляры.

В пакете есть первые три слоя, последние два не зафиксированы. Их отсутствие не опровергает идентичность и подключение. Наличие первых слоёв не создаёт маршрут или ответ. Такое разделение защищает и от вывода «без измерения узла нет», и от вывода «раз каталог заполнен, эффект доказан».

«Открытая» политика пиринга выражает готовность, а не перечень всех установленных сессий. «Прямое подключение» описывает интерфейс на fabric, а не текущие сервисные префиксы. 2025 год — поле каталога, а не автоматически дата установки, активации, первого объявления или первого запроса. Время должно оставаться связано с событием, которое оно описывает.

Маршрутный слой должен называть префикс и семейство. Для AS37177 надо искать два блока NS2, для AS37181 — два блока DotARPA. Видимость только IPv4 не доказывает полный dual stack. Представление только route server не доказывает выбор каждого участника. Слой DNS должен содержать имя и тип запроса, рекурсивный или авторитетный режим, код ответа, способ определения экземпляра и время. Задержка сама по себе не является идентификатором.

После разделения слоёв различия превращаются в рабочие вопросы: изменилась регистрация, упала сессия, отфильтрован префикс, заболело приложение, отсутствует зона или резолвер выбрал другой сайт?

Две квитанции для одного публичного присутствия

Квитанция NS2 начинается с AS37177, 196.216.168.0/24 и 2001:43f8:120::/48. Квитанция DotARPA — с AS37181, 196.216.169.0/24 и 2001:43f8:110::/48. Адреса UIXP .5/::5 и .6/::6 сохраняются отдельно как пиринговые интерфейсы.

Маршрутная часть разделяет IPv4 и IPv6 и записывает ожидаемый префикс, видимость, коллектор, соседа или route server и время. Прикладная часть называет класс службы или пространство имён, состояние здоровья и связь с отзывом маршрута. Наблюдение содержит точку, режим резолвера, имя и тип запроса, код, задержку, идентификатор экземпляра и время. Хэш серии связывает сводку с исходными данными.

Ни одно поле не является коротким путём. «Активировано» не доказывает текущий маршрут. Маршрут не доказывает здоровье DNS. Правильный ответ не доказывает все ожидаемые зоны. Низкая задержка в одной точке не доказывает региональное улучшение. Ценность квитанции в том, что она сохраняет переходы.

Сегодня обоснован сильный, но ограниченный вывод: две по-разному адресованные DNS-службы AFRINIC перечислены как прямые подключения к UIXP и имеют отдельные опубликованные цепочки ресурсов. Источники не доказывают, что все релевантные запросы остаются в Уганде или что задержка и устойчивость измеримо улучшились. Когда такой результат появится, он должен быть оформлен двумя эксплуатационными квитанциями, а не сиянием одной точки на карте.

Источники

  1. Руководство AFRINIC по DNS Anycast: https://dns.afrinic.net/deployment-guide/
  2. Программа DNS AFRINIC: https://dns.afrinic.net/
  3. Подключённые сети UIXP: https://www.uixp.co.ug/networks
  4. Службы и серверы маршрутов UIXP: https://www.uixp.co.ug/services
  5. Вторичная служба AfDSP: https://afrinic.net/dns-support.html
  6. Программа копий корневых серверов: https://afrinic.net/root-server-copy.html
  7. RFC 5855: https://www.rfc-editor.org/rfc/rfc5855.html
  8. RFC 4786: https://www.rfc-editor.org/rfc/rfc4786.html
  9. RFC 7094: https://www.rfc-editor.org/rfc/rfc7094.html
  10. RFC 1034: https://www.rfc-editor.org/rfc/rfc1034.html
  11. AFRINIC RDAP, AS37177: https://rdap.afrinic.net/rdap/autnum/37177
  12. AFRINIC RDAP, AS37181: https://rdap.afrinic.net/rdap/autnum/37181
  13. RDAP, 196.216.168.0/24: https://rdap.afrinic.net/rdap/ip/196.216.168.0
  14. RDAP, 196.216.169.0/24: https://rdap.afrinic.net/rdap/ip/196.216.169.0
  15. RDAP, 2001:43f8:120::/48: https://rdap.afrinic.net/rdap/ip/2001:43f8:120::
  16. RDAP, 2001:43f8:110::/48: https://rdap.afrinic.net/rdap/ip/2001:43f8:110::
  17. API PeeringDB, AS37177: https://www.peeringdb.com/api/netixlan?asn=37177
  18. API PeeringDB, AS37181: https://www.peeringdb.com/api/netixlan?asn=37181