Год назад я написал статью про "Национальную систему доменных имён", в которой были рассмотрены некоторые технические аспекты её организации, в основном то что касается доступности узлов этой системы, а не аспектов работы DNS. Я не следил, но надеялся встретить за этот год больше информации изнутри, но мне она не попалась. Конференций и каких-то публичных технических мероприятий всё ещё было не очень много, где обычно такая информация появляется, но если кто-то что-то встретил просьба поделиться, я добавлю ссылки сюда и удовлетворю своё любопытство.

Я попробовал поискать в Google, но и там ничего не нашёл, кроме новостей, приказов об основании этой системы и редких ссылок на инструкцию по подключению, вот например на labs.ripe.net в PDF. На сайте Роскомнадзора мои усилия тоже закончились ничем. Подозреваю что какие-то документы есть внутри ЦМУ ССОП, но туда заходить я не стал.

При всём при этом НСДИ остаётся публичной системой, воспользоваться которой может, как минимум, каждый пользователь Интернет в России. Кроме того, за год накопились данные мониторинга с RIPE Atlas на созданных мною измерениях, используя которые мы и посмотрим к чему мы пришли. Мы не выйдем структурно за рамки прошлой статьи и наш взгляд будет всё равно поверхностный, но имея гораздо больший объём данных сможем посмотреть на это чуть пошире.

RIPE Atlas

Прежде чем смотреть на данные непосредственно о НСДИ накопившиеся с мая прошлого года надо посмотреть на зонды RIPE Atlas, доступность которых обеспечивается на добровольной основе и не все они могли пережить этот год. Изначально в измерениях я задавал 14 пробников, но один из них в Тюмени id 53716 не вошёл в прошлую выборку потому что сразу перестал отвечать по IPv6. Оставшиеся 13 это Калининград id 1000859, Санкт-Перербург id 31856, Ростов-на-Дону id 19858, Волжский id 50398, Самара id 28120, Казань id 19921, Пермь id 1001361, Екатеринбург id 53975, Челябинск id 25133, Омск id 53961, Новосибирск id 6538, Чита id 6624, Хабаровск id 6936. Далее я буду оперировать только названиями городов.

В работе была использована библиотека RIPE Atlas Sagan с элементарным набором функций, получающая на входе JSON по каждому измерению и выдающая форматированные данные в одном из типов Python. Для получения исходных данных на вкладке загрузки результата измерений следует выбрать формат nd-json.или format=txt при работе с API RIPE Atlas. Все результаты агрегированы мною с точностью до суток, в который вмещается до 24 попыток измерений. Если пробник не отвечает, то следовательно результатов будет меньше чем 24 за сутки, но это никак не отражается в моём анализе - зонд считается живым если в сутки попало хотя бы одно успешное измерение.

Также, помимо отсутствия данных они могут вернуться с ошибкой, которая может быть как внутренней ошибкой зонда, так и ошибкой запроса. Каждый час плюс/минус четверть часа делается запрос, ответ ожидается до 5 секунд, в случае ошибки запрос на повторяется. В подавляющем большинстве случаев это ошибки Timeout, которые можно интерпретировать по разному, как ошибки объекта измерения - вышел сервер из строя, так и ошибками доступности этого сервера по сети. В случае даже одной ошибки за сутки, все сутки помечаются ошибочными, что позволяет увидеть всплески недоступности если они будут. Оставшиеся ошибки встречаются двух видов "Нераспознанный ответ DNS", сюда попадают и ответы которые я не ожидал увидеть, например, NXDOMAIN. Второй тип - ошибка соединения сокета "Network Unreachable". В сумме ошибок отличных от Timeout меньше 10 на все результаты, поэтому я их игнорировал и далее под ошибкой понимается именно Timeout.

В дальнейшем мы будем использовать следующие измерения для анализа с 26 мая 2021 года по 26 мая 2022 года:

1. Запросы NSID к a.auth-nsdi.ru в IPv4 id 30376498 и в IPv6 id 30376500

2. Запросы NSID к b.auth-nsdi.ru в IPv4 id 30376499 и в IPv6 id 30376501

3. Рекурсивные запросы к a.res-nsdi.ru в IPv4 id 29957988 и в IPv6 id 29957993

4. Рекурсивные запросы к b.res-nsdi.ru в IPv4 id 29957990 и в IPv6 id 29957995

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

Итак, в первую очередь выясним живость зондов, для чего я сначала хотел объединить все IPv4 измерения в один график, а все IPv6 в другой, однако не стал этого делать, потому что это бы очень сильно смазало картину доступности, которая хотя и похожа, но всё же отличается для разных измерений:

a.auth-nsdi.ru

b.auth-nsdi.ru

a.res-nsdi.ru

b.res-nsdi.ru

Жирная линия (точка) - за сутки есть результаты измерений и нет ни одного Timeout. Тонкая полупрозрачная линия (точка) - есть результаты измерений за сутки, но хотя бы один из них был с Timeout. Отсутствие линии - нет результатов измерений за сутки, зонд не работал.

Результаты в табличном виде:

Два числа это Доступность - количество дней в году с результатами, когда зонд имеет хотя бы один успешный замер, к общему количеству дней, в процентах и Процент ошибок - количество дней с ошибками Timeout к количеству дней доступности, в процентах. Жирным выделены ячейка с наилучшими показателями Доступности.

Для меня ожидаемо, что в IPv4 доступность лучше. В IPv6 мы видим, что некоторые зонды хотя и были доступны ушли в постоянные ошибки Timeout. Тут я уверенно делаю вывод что сломалась IPv6 связность, намеренно или ненамеренно, но это не проблема построенной системы это всё ещё детские болезни IPv6. Ещё мы видим что некоторые пробники были выключены, кто-то большую часть года, не выполняя никаких измерений. Меньше всех был доступен зонд из Самары, а уже упомянутая Тюмень, хотя и совсем не была доступна по IPv6, в IPv4 запросах отработала треть выбранного времени. Радует что многие сохранили достаточную активность, в том числе со 100% доступностью. Обратите внимание на разность в результатах для *.auth-nsdi.ru и *.res-nsdi.ru по процентам ошибок, а также 3 из 4 лучших результата зонда в Перми по доступности в IPv6.

Оставшиеся ошибки появляющиеся в разные периоды для разных измерений по разным зондам уже не так очевидны. Как я сказал выше ошибки Timeout, в том виде который представлен в измерении, не позволяют судить о причине ошибки. Это может быть как ошибка сервера DNS так и ошибка доступности этого сервера по сети или чрезмерной загрузки зонда. Серия последовательных запросов могла бы прояснить картину, но на запросах я сэкономил, потому что каждый запрос стоит внутренней валюты и я боялся что её мне не хватит. Итого, ровно один запрос на каждый плюс/минус час не позволяет делать какие либо выводы. Понять природу Timeout, помогло бы сравнение результатов нескольких измерений и такую работу можно провести. Я приведу лишь один график с временем отклика на котором есть ошибки Timeout, на масштабе одного дня, по зонду в Новосибирске за 2 мая 2022:

Мы видим что отклик по всем серверам держится на одном уровне, видны всплески задержек и ошибки Timeout - значения меньше 0мс, всего их было 8 за день. Видно три момента когда были ошибки. Первые две ошибки это запросы к a.res-nsdi.ru и b.res-nsdi.ru в IPv6, вторые две это запросы к a.auth-nsdi.ru и к b.auth-nsdi.ru в IPv6 и оставшиеся 4 это запросы к a.res-nsdi.ru и b.res-nsdi.ru в IPv4 и IPv6. На таком масштабе не видно, но разница между запросами к *.auth-nsdi.ru и *.res-nsdi.ru серверами 15 минут, то есть эти измерения не являются контрольными друг другу, так как разница в 15 минут весьма существенна. Следовательно момент когда не получено ни одного ответа от серверов *.res-nsdi.ru после 20 часов не говорит нам что были проблемы именно с серверами *.res-nsdi.ru, так как в это же время могли быть и недоступны *.auth-nsdi.ru серверы, но их мы проверили только через 15 минут, кстати, увидев всплески задержки в IPv6. То же касается и первых двух моментов ошибок, определённо можно сказать что не работал IPv6, но была ли это проблема для конкретных серверов или вообще не работал IPv6 на данном зонде сказать нельзя. Единственный вывод - нам не хватает данных для подобного анализа, по причине что я написал немногим раньше.

Дальше будут графики с откликом, но усреднённые за сутки, по которым тоже можно судить о качестве доступности на большем масштабе и попытаться увидеть системные изменения поведения. Оценка доступности НСДИ, её устойчивость к нагрузкам, качество работы - это тема для одной или не одной, но целой и обстоятельной статьи, которая, я уверен, должна появиться, идеально если от ЦМУ ССОП.

Узлы НСДИ

У нас есть данные измерений за год, а не за месяц как было в прошлой статье и за этот год список участвующих в работе системы узлов значительно расширился. Напомню, для корневых серверов работает запрос NSID, для рекурсивных используется запрос к сервису PowerDNS, возвращающий источник запроса в TXT. Количество разных узлов НСДИ встречающихся за сутки:

a.auth-nsdi.ru

b.auth-nsdi.ru

a.res-nsdi.ru

b.res-nsdi.ru

Наверное, можно сделать вывод что система прирастает количеством узлов, по крайней мере встречающихся узлов в сутках становится больше к концу периода по некоторым измерениям. А в целом, мы видим одновременно и динамичность, количество идентификаторов меняется день ото дня и постоянство, структурность - идентификаторов конечное количество, даже в случае когда мы считаем разные IP адреса источники запроса, они постоянны. Лучше это будет видно когда мы их перечислим, сначала для корневых серверов по NSID:

Обращает на себя внимание, смотря на человеческие названия, что не для всех локаций в опросах попались по 6 разных NSID, в некоторых случаях есть пропуски в нумерации. Учитывая что некоторые NSID появились всего по разу, с некоторой вероятностью недостающие просто не попались в наши измерения, при выбранной частоте опроса и зная что не все зонды работали всё время, однако как мы увидим дальше, не все локации заполнены в полной мере, поэтому пропуски значат ровно то, что такого узла не существует. Отметим что редкие NSID в основном появлялись при опросе b.auth-nsdi.ru по IPv6. Также можно выделить основные узлы, которые встречаются чаще других при различных опросах, опять же делая скидку на выбранные зонды, их местоположение и работоспособность. Все локации - EKT, KHOUSE, KZN, M9P, NSK, RND, SMR, SPB, STD, VLV.

Для рекурсивных серверов, по IP с которого прилетает запрос до авторитарного сервера:

Здесь у нас IP адреса, поэтому возможностей для проверок чуть больше. Не для всех заведены PTR, но для всех заведены A и AAAA , по ним легко можно подобрать недостающие имена, что я и сделал сразу. Некоторые адреса пингуются, некоторые нет, в любом случае используя очевидную структуру имени можно выяснить есть ли рядом ещё такие адреса, которые не попались в измерениях, по крайней мере заведены ли они в DNS, чего нельзя было сделать с NSID в предыдущем случае для корневых серверов. Дополнительно нам попалась ещё одна локация MSK, которая на самом деле точная копия KHOUSE, точнее res1-khouse-lb.ix.ru.

Что касается организационной структуры и топологии, мы видим, скорее всего, по 6 возможных узлов в каждой локации. При этом узлы res1 и res2 имеют адресацию в одной подсети, а узлы res3, res4, res5, res6 в другой. Рассмотрим локацию NSK, в которой нам попались узлы от res1 до res4. При этом узлы res5 и res6 также присутствуют. Узлы res1 и res2 находятся в подсети 192.232.230.0/24 с адресами .81 и .82 и IPv6 сети 2001:67c:1211::/48 где младшая часть включает в себя полностью IPv4 адрес. res1-nsk-lb.ix.ru 192.232.230.81 и 2001:67c:1211:4000:192:232:230:81.

Узлы от res3 до res6 в подсети 192.232.240.0/24 с адресами от .48 до .51. IPv6 сеть 2a0c:a9c7:240::/48 в которой повторяется третий октет из IPv4 адреса, а сами узлы нумеруются от :101 до :104, начиная с res3. res3-nsk-lb.ix.ru 192.232.240.48 и 2a0c:a9c7:240:2000:1000::101. Каждая локация имеет свои подсети, при этом сохраняя структуру адреса, чуть особняком стоит STD с подсетью 2001:6d0:fffc::/48 в которой используется 4000 и 6000 в середине адреса, чтобы разделить res1 с одной стороны и res2 и res3 с другой, а в IPv4 адресах только одна подсеть. Для некоторых локаций, например M9P или KZN, присутствует только одна логическая часть.

Все префиксы которые были выявлены по локациям, включая не присутствующие в измерениях, а дополненные исходя из структуры адреса (отмечены курсивом):

Пинги

Как и в прошлый раз, время отклика ответа DNS было усреднено по следующему правилу - отбрасываем четверть самых долгих и четверть самых быстрых ответов за сутки, из оставшихся считаем среднее. Тогда мы считали одно значения за месяц, сейчас за сутки. Из результата выкинуты зонды которые не были доступны более 100 дней в году. Оставшиеся разделены на две части по каждому из серверов: одни, где максимальное время ответа за год меньше 100мс, другие где больше. Это позволило не загромождать графики значениями в разном масштабе и сравнивать их визуально. Значения меньше 0, в моменты когда зонд не был доступен или были Timeout.

a.auth-nsdi.ru

b.auth-nsdi.ru

a.res-nsdi.ru

b.res-nsdi.ru

Я не увидел в этих графиках ничего особенного, за что бы цеплялся взгляд. Для корневых серверов в IPv4 даже не пришлось выделять отдельный график за 100мс, всё уместилось на одном, может быть это связано с меньшей их нагрузкой в отличие от рекурсивных серверов. В отдельных случаях можно посетовать на покрытие, например для Читы со стабильно высоким откликом, при этом видно что что-то случилось с этим зондом в середине периода измерений, когда отклик сильно вырос. Но большинство значений в общей массе меньше 100мс, те всплески что мы видим имеют какую-ту другую природу не относящуюся к распределению узлов НСДИ по стране. Очень сильно не везёт Казани и Челябинску с выбором ближайшего IPv6 НСДИ узла, но тут я склоняюсь больше у проблемам поставщика IPv6 для данных зондов. Опять же, Челябинск почему-то резко увеличил время отклика до a.res-nsdi.ru и только до него. Поэтому, в общем и целом, я бы назвал картину стабильной и ожидаемой при опросе хостов в Интернете.

Все созданные мною измерения продолжают работать, пока это имеет смысл, если, конечно, сами зонды которые используются в измерениях останутся в строю. Тут вся надежда на их владельцев, скажем им большое спасибо. Полный список есть в прошлой статье, или можно воспользоваться поиском по полю Description на вкладке DNS в измерениях на сайте RIPE Atlas. Конечно, надо было ставить тэги, но теперь уже поздно.

В конце, два вопроса, которые мне кажутся актуальными и интересными сейчас. Мой ответ "Да" на оба. Ещё раз выражаю надежду на большую открытость в общении и более широком обсуждении, по факту, публичного и ключевого инструмента в Рунете, с бOльшим погружением в детали. Про, непосредственно, DNS, инфраструктуру, упомянутую уже доступность и отказоустойчивость, безопасность, работу с нагрузками. Другими словами про всё остальное, что скрылось от весьма поверхностного взгляда этой статьи.