Национальная система доменных имён: первый взгляд

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

Из уже упомянутой выше статьи по ссылкам можно найти оригинальное письмо РКН, из которого мы знаем что существуют:

• 194.85.254.37 — корневой DNS сервер позволяющий, помимо прочего, выполнять запрос AXFR, то есть получать корневую зону «как есть», но для этого надо попасть в список доверенных серверов и такой возможности у меня нет

• a.auth-nsdi.ru, b.auth-nsdi.ru — тоже корневые DNS, позволяющие не рекурсивно запрашивать записи из корневой зоны

• a.res-nsdi.ru, b.res-nsdi.ru — рекурсивные резолверы, позволяющие запрашивать любую запись

Сразу обращу ваше внимание на то, что система находится в очень подвижном состоянии, как и положено любой системе на начальном этапе эксплуатации, да и вообще системе в Интернет. И дотошный читатель наверняка уже нашёл, что существуют, например, c.auth-nsdi.ru и d.auth-nsdi.ru, пока не отвечающие на запросы. Но это значит, что через пару месяцев или недель ситуация, как она описывается в этой статье, может поменяться кардинально. Помните об этом.

Корневые серверы

194.85.254.37 принадлежит блоку 194.85.254.0/24, который появился отдельной строчкой в RIR и тогда же стал анонсироваться в глобальную таблицу Интернет маршрутизации меньше года назад — в августе 2020 года, источником анонсов является AS62135. Отвечает на CHAOS TXT запросы:

• version.bind — «PowerDNS Authoritative Server 4.4.0-alpha3.125.master.g6835270cd (built Nov 16 2020 18:13:24 by root@b6b5979d40d3)»

• id.server — mu.cmu.msk-ix.ru

Есть поддержка NSID — «mu.cmu.msk-ix.ru», и насколько можно судить по данным RIPE Atlas этот сервер представлен в единственной точке присутствия в центральной европейской части России.

На временные интервалы, здесь и дальше, следует ориентироваться с большой долей условности, из-за высокой динамичности. Для расчёта были отброшены четверть значений сверху, четверть снизу из оставшегося посчитано среднее.

a.auth-nsdi.ru и b.auth-nsdi.ru представлены в IPv4 и IPv6 и входят в блоки 195.208.6.0/24, 2a0c:a9c7:a::/48,195.208.7.0/24 и 2a0c:a9c7:b::/48, которые появились отдельными строчками в RIR и начали анонсироваться в конце осени, начале зимы 2020. Все от имени AS41740 c as-name NDNS. Всего с той же AS анонсируется 12 префиксов, которые мы ещё встретим дальше:

193.232.147.0/24, 193.232.253.0/24, 195.208.5.0/24, 195.208.4.0/24, 195.208.6.0/24, 195.208.7.0/24, 2a0c:a9c7:a::/48, 2a0c:a9c7:253::/48, 2a0c:a9c7:147::/48, 2a0c:a9c7:b::/48, 2a0c:a9c7:9::/48, 2a0c:a9c7:8::/48

Также поддерживается NSID и запрос CHAOS TXT id.version. На основе которых по отчётам RIPE Atlas (30376498, 30376499, 30376500, 30376501) можно сделать выводы что задействовано несколько точек присутствия и механизмы распределения трафика между ними.

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

auth1-ekt.ix.ru, auth1-khouse.ix.ru, auth1-kzn.ix.ru, auth1-nsk.ix.ru, auth1-rnd.ix.ru, auth1-spb.ix.ru, auth1-vlv.ix.ru, auth2-ekt.ix.ru, auth2-khouse.ix.ru, auth2-kzn.ix.ru, auth2-nsk.ix.ru, auth2-rnd.ix.ru, auth2-spb.ix.ru, auth2-vlv.ix.ru

Несмотря на то, что у меня нет возможности сделать AXFR запрос и сравнить корневые зоны на идентичность Root Zone File, можно сделать обычные запросы по каждой из записей в корневой зоне и сравнить результаты. Несколько однострочников в Bash, чтобы убедиться что корневая зона отдаваемая серверами НСДИ идентична эталонной. В этом мне помогла одна особенность на которую я обратил внимание, возможно, присущую конкретной версии используемых серверов и которая касается DNSSEC и записей NSEC. Не все корневые серверы, возвращают эту запись по прямому запросу, а только в случае NXDOMAIN,корневые НСДИ серверы — возвращают. Таким образом задача решается одним запросом dig +dnssec для каждой строчки из Root Zone File с последующим сравнением. Совсем чуть-чуть придётся поработать с представлением отдаваемых данных, например, привести адреса IPv6 к одному формату, в эталонном файле они приводятся без применения правил сокращения, запретить dig форматировать base64 строчки +nosplit и ещё не забыть про IDN — +noidnout. Результат, насколько я могу судить, не отличается от эталонного. Конечно, интересно было бы следить за этим постоянно, измерять, например, задержки между публикациями зоны и распределением её по серверам НСДИ, но оставим это для следующих авторов.

Рекурсивные резолверы

a.res-nsdi.ru и b.res-nsdi.ru — тоже представлены в IPv4 и IPv6: 195.208.4.0/24, 2a0c:a9c7:8::/48,195.208.5.0/24 и 2a0c:a9c7:9::/48 уже знакомой нам AS41740. В анонсах появились также в конце 2020. Поддерживается только CHAOS TXT id.version, NSID — нет. Но так как это рекурсивные серверы то можно воспользоваться сервисом предоставляемым PowerDNS, чтобы определить с какого реального адреса был отправлен запрос. Это даёт нам технически более строгий способ, так как мы выявляем адреса непосредственно участвующие в запросах со стороны НСДИ, а не идентификаторы, которые можно менять без каких-либо последствий. Опять смотрим на RIPE Atlas (30376488, 30376489, 30376490, 30376491, 30376492, 30376493, 30376494, 30376495).

Отметим ещё один момент.AAAA запросы используют IPv6 в качестве адреса источника, даже если обращения было сделано на клиентский публичный IPv4 адрес сервера. Для A запросов на IPv6 адрес это тоже верно. В таблице приведены уже преобразованные к доменным именам адреса, там где они были в PTR, каждый из них имеет и A и AAAA запись. Всего получилось 17 уникальных адресов доменных имён у каждого в наличии IPv4 и IPv6. Для двух адресов видимо забыли завести записи в обратную зону, хотя в прямой они есть (я их привёл в скобках).

193.232.139.82(res2-rnd-lb.ix.ru), 193.232.231.82(res2-ekt-lb.ix.ru), res1-ekt-lb.ix.ru, res1-khouse-lb.ix.ru, res1-kzn-lb.ix.ru, res1-msk-lb.ix.ru, res1-nsk-lb.ix.ru, res1-rnd-lb.ix.ru, res1-smr-lb.ix.ru, res1-spb-lb.ix.ru, res1-vlv-lb.ix.ru, res2-ekt-lb.ix.ru, res2-khouse-lb.ix.ru, res2-kzn-lb.ix.ru, res2-nsk-lb.ix.ru, res2-rnd-lb.ix.ru, res2-smr-lb.ix.ru, res2-spb-lb.ix.ru, res2-vlv-lb.ix.ru

Для примера, надеюсь остальное многие посмотрят сами, сошлюсь на RIPE DB для сети 193.232.139.0/24, запись о которой и маршруты появились в марте этого года, когда уже фактически провайдеры обязаны были использовать НСДИ в своей работе, что во многом говорит что мы находимся в моменте внедрения и обкатки системы, пусть и на хорошей базе. Не знаю какие планы в дальнейшем, но явно в некоторых точках страны видно провалы по задержкам ответов, другими словами есть много что ещё делать.

Для этих серверов уже действует ограничение на выдачу ресурсов присутствующих в списке запрещённых — NXDOMAIN в ответ.

На этом — всё. Как я уже сказал в самом начале, цель этой статьи начать техническое обсуждение построенной системы. Можно свободно использовать те измерения которые я реализовал в RIPE Atlas и ссылки на которые есть в статье, они останутся настолько долго, насколько не потеряют актуальность. Совсем незатронутым остался вопрос DNSSEC, также как и возможные пересечения с существующей системой поддержки национальных TLD. Можно порассуждать про обратные зоны в ARPA., которые не менее важны чем прямые, но они не реализованы в НСДИ, в отличие от прямой корневой зоны. Вопрос устойчивости и работы под нагрузкой, вопрос безопасности… Другими словами больше осталось за кадром, чем в статье — много интересной работы и вопросов, надеюсь, что кого-то я этим заинтересовал.