Повторение – мать учения, или Конференция TLDCON 2024 (5-6 сентября 2024, Минск)

Павел Храмцов

Аннотация:

На конференции TLDCON 2024 в Минске были впервые в основной сетке докладов представлены выпускные студенческие работы. Речь идёт о полноценных исследованиях и разработках перспективных программных инструментов исследований инфраструктуры Интернета. Полученные результаты вызвали неподдельный интерес у участников конференции. Организаторы планируют в рамках следующей конференции TLDCON 2025 организовать отдельную секцию студенческих работ.

В этом году сентябрь в Минске выдался тёплым и сухим. По Свислочи тянулись караваны сап-бордов. Около Центра водных видов спорта дети гоняли на шверботах класса «Оптимист». По набережной вдоль реки прогуливается молодежь и рассекают велосипедисты. И неожиданно там же на четвереньках, меж ног и колёс, скачут две девчушки-квадробера, изображая кошку и собачку. Это новое помешательство не обошло стороной и столицу Белоруссии.

Новые веяния, возможно, пришли ненадолго, а вот старые добрые традиции проведения отраслевых конференций в сентябре, к счастью, продолжаются. В тёплой и радушной обстановке с 5 по 6 сентября 2024 в Минске в отеле «Марриотт» проходила традиционная 17-я Международная конференция администраторов и регистраторов национальных доменов верхнего уровня стран СНГ, Центральной и Восточной Европы (TLDCON 2024).

Каждый год в доменной индустрии проходит несколько десятков международных семинаров и конференций по всему миру. Это три глобальных конференции ICANN (general, community, policy), несколько форумов DNS и множество конференций региональных сообществ регистратур, регистраторов и технических специалистов.

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

TLDCON 2024 отличали два важных обстоятельства: эта конференция была организована и проведена в гибридном формате, причём преимущественно с офлайн-участием, и впервые в основной сетке конференции в ходе секции «Исследования и их результаты» были представлены студенческие работы, выполненные в рамках сотрудничества Фонда развития сетевых технологий «ИнДата» и Московского института электроники и математики им. А.Н. Тихонова Национального исследовательского университета «Высшая школа экономики» (МИЭМ НИУ ВШЭ).

Справедливости ради стоит заметить, что сотрудничество конференции TLDCON c высшей школой началось не в Минске. Первые мастер-классы для студентов участники конференции провели в 2023 году на TLDCON 2023 в Петрозаводске. Но вот полноценное участие студентов и выпускников вузов в основной программе конференции – выступления с докладами – случилось впервые в Минске.

У организаторов, Координационного центра доменов .RU/.РФ, были обоснованные сомнения в успехе такой затеи, но, забегая вперед, скажу, что всё получилось, и есть высокая вероятность того, что на TLDCON 2025 в программе может появиться самостоятельная студенческая секция.

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

Чтобы не быть голословным, представлю сами работы, о которых было доложено в рамках конференции.

«Использование DNS-резолверов»

Анна Подгук исследовала проблему использования DNS-резолверов конечными клиентами интернет-провайдеров. Прежде чем углубиться в обсуждение презентации результатов, хотелось бы остановиться на значимости и актуальности самой проблемы.

Начнем со значимости. Есть такое словосочетание «Internet governance». Его часто у нас переводят, как «управление Интернетом». Я думаю, что это не совсем точно. Точнее, совсем не точно. На мой взгляд, в данном контексте речь идёт не об управлении, а о регламентировании: техническом, организационном, административном и т.п… При этом упор делается на общественные объединения (communities). Однако перевод устоявшийся, и даже ежегодную всемирную конференцию IGF принято называть Форумом по управлению Интернетом.

На сайте https://www.internetgovernance.org/ есть шкала развития процесса «управления» (Рис. 1).

Рис. 1. Временная шкала развития институтов «управления Интернетом».

Большинство событий на этой шкале связано с организациями, которые занимаются распределением уникальных идентификаторов (адресов, доменных имён, номеров), т.е. в более широком смысле выполняют IANA-функции.

Если принять за основу широко распространённое мнение, что доменные имена являются «человеческим» интерфейсом в мир номеров Интернета, то надёжность, доступность, безопасность поиска соответствий между именем и номером является ключевой проблемой «управления» Интернетом.

Система доменных имен (DNS) – это распределённая иерархическая информационная система, хранящая данные в виде соответствия «ключ/значение». Ключ – это доменное имя, а значение – всё что угодно, в том числе: номера, адреса, другие имена и даже правила преобразования ключей. Наиболее известным соответствием, в контексте которого упоминается DNS, является соответствие «доменное имя/IP-адрес».

В качестве распределенной СУБД в этой системе используются авторитетные серверы доменных имён, а в качестве инструмента поиска – кеширующие рекурсивные DNS-резолверы или просто – резолверы.

Ещё раз обращу внимание на то, что под «управлением» Интернетом чаще всего понимают распределение ограниченного ресурса – имён, адресов, номеров и т.п. Но поиск во всём этом многообразии не менее важен.

Долгое время конечный пользователь осуществлял поиск в DNS только с помощью резолверов провайдеров подключения к Интернету. Это было просто, логично и понятно. Адрес резолвера устройство конечного пользователя получало в момент подключения к Сети вместе с IP-адресом для этого устройства и IP-адресом шлюза, через который осуществляется доступ.

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

В этой конспирологической атмосфере (приватность, приватность и ещё раз приватность!) появились резолверы, которые не связаны с провайдерами доступа. Наиболее известные из них – это Google DNS, Amazon 53, Yandex DNS, CloudFlare DNS, Quad9, OpenDNS и другие.

Впрочем, не стоить слепо верить в то, что «хорошие ребята» из Google из-за альтруизма помогают всем нам бороться с «плохими парнями». Достаточно поглядеть в логи авторитетных DNS-серверов и обнаружить там любопытный факт – до 50% трафика в DNS-запросах совсем недавно составляли «мусорные» запросы платформы Chromium [1]. Как выяснилось, таким образом Google боролся и борется до сих пор с перехватом DNS-запросов к несуществующим доменам.

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

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

Впервые эту идею реализовали в Verisign 15 сентября 2003 года в проекте Site Finder [2] (ресурса на сайте Verisign не найти, но Интернет помнит все! ). Система официально была закрыта 4 октября 2003 года. Общественность заклеймила разработчиков как нарушителей стандартов ради коммерческой выгоды. Но сама идея жива до сих пор. И ряд провайдеров её эксплуатируют.

Но это же рекламный доход! А это деньги Google! И поэтому Google в два раза увеличил нагрузку на авторитетные серверы системы DNS ради защиты от тех, кто ищет коммерческую выгоду, типа, нарушая стандарты! Чудеса, да и только !

Стоит здесь упомянуть и ещё об одной особенности DNS в контексте достоверности DNS-данных, которые получает конечный пользователь Интернета. Речь идёт о расширении безопасности DNS-протокола – DNSSEC.

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

Собственно, эта особенность DNSSEC заложена в концепцию Hyper Local корпорации ICANN [3] и в концепцию «Национальной системы доменных имён» [4].

Раз источник не имеет значения, то главным элементом становится тот элемент системы, который проверяет достоверность. Таким элементом в концепции Hyper Local является DNS-резолвер.

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

Понятно, что и до «студенческого» исследования такие работы в мире проводились. Наиболее известная из них – исследование APNIC Labs [5]. Эта исследовательская платформа [6] являлась наиболее точной и репрезентативной, т.к. базируется на рекламных площадках Google. Вот в этом последнем утверждении скрывается подвох. Как увидим ниже, оно требует проверки.

В марте 2022 года было замечено резкое падение трафика в этой системе измерений с российских адресов (Рис. 2) и увеличение дисперсии измерений (Рис. 3). Как будто в России пропал Интернет. Но российские пользователи ни о каких «проблемах с Интернетом» в разных их проявлениях не сообщали.

Рис. 2. Изменение количества измерений в системе APNIC Labs для российских источников DNS-запросов.

Рис. 3. Увеличение разброса (дисперсии) доли различных DNS-резолверов в измерениях APNIC Labs.

Такое положение вещей поставило два актуальных вопроса:

• что является причиной такого изменения на графиках;
• является ли статистика APNIC Labs репрезентативной в случае конечных пользователей российских интернет-провайдеров.

Ответ на первый вопрос нашёлся достаточно быстро. И он следует из Google Publisher Policies (Рис. 4)

Рис. 4. Политика Google в отношении публикаций рекламы для российских пользователей.

Дело в том, что технология измерения DNS-трафика конечных пользователей в системе APNIC Labs опирается на рекламные площадки Google. Именно ресурсы Google позволяют определить адресный пул конечного пользователя и привязать его к автономной системе провайдера доступа в Интернет.

Понятно, что решение администрации Google повлияло на репрезентативность измерений. Вопрос только в том, насколько существенным оказалось это влияние.

Для ответа на этот вопрос нужно было повторить технологию измерений. Но вот только в качестве площадок измерений нужно было выбрать платформы, отличные от Google, и позаботиться о контроле репрезентативности.

Таким образом, целью «студенческой» работы было определение автономных систем резолверов, которыми пользуются пользователи российских автономных систем.

Агрегация площадок резолверов до уровня автономных систем следует из технологий, которые в данном случае применяются (anycast и CDN).

При этом следовало решить следующие задачи:

• получить запросы конечных пользователей;
• получить связанные с запросами конечных пользователей запросы от DNS-резолверов;
• установить однозначное соответствие между запросом конечного пользователя и запросом DNS-резолвера;
• собрать запросы конечных пользователей и связанные с ними запросы DNS в единую базу данных;
• реализовать регулярный сбор такой статистики;
• создать сайт проекта с отчётами по собранным данным.

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

Запросы конечных пользователей можно получить путем создания веб-сайта и анализа логов обращений к этому веб-сайту по протоколу HTTPS. Понятно, что к этому сайту кроме прямого обращения конечных пользователей будет получено множество обращений ботов, обращений через прокси и VPN, а также через различные коллекторы CDN, но и в измерениях APNIC это всё тоже присутствует.

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

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

В случае с APNIC Labs были использованы рекламные площадки Google. По замыслу авторов проекта, репрезентативность измерений обеспечивалась широкой популярностью ресурсов Google, на которых можно было разместить «рекламу» измерительной площадки.

Чисто теоретически, для студенческой работы можно было бы попробовать договориться с Yandex или VK. Но в этом случае на измерительную площадку обрушился бы чудовищный поток запросов, что потребовало бы существенных затрат на построение системы а-ля Big Data. Да и с точки зрения того, что это дипломная студенческая работа, необходимо было показать квалификацию дипломника не только как специалиста в области IT, но и как сформировавшегося исследователя. Поэтому было принято решение в пользу выбора множества не столь популярных площадок (площадок измерения) с контролем репрезентативности измерений по количеству конечных пользователей наиболее крупных автономных систем российских провайдеров.

Для цели контроля использовался проект iddb.ru [7] Фонда развития сетевых технологий «ИнДата» [8], где можно получить необходимую информацию по российским автономным системам и, более широко, о всей интернет-инфраструктуре.

В общем виде схема измерений выглядит следующим образом (Рис. 5):

1. Для получения запроса конечного пользователя достаточно, чтобы на страницу площадки измерения загружался фрагмент контента с веб-сайта измерений, чей лог доступен для сбора и обработки статистики обращений.
2. Таким фрагментом контента может являться JavaScript-фрагмент, который будет обращаться ĸ веб-сайту измерений для загрузки изображения, которое не будет отображаться в браузере конечного пользователя при загрузке страницы популярного веб-сайта.
3. Данный JavaScript-фрагмент должен обращаться ĸ веб-сайту измерений по имени домена измерений, чтобы авторитетный сервер DNS этого домена мог получить запрос от резолвера, который использует конечный пользователь.
4. Для того, чтобы однозначно связать запрос конечного пользователя ĸ популярному веб-сайту и запрос резолвера ĸ домену измерений, необходимо реализовать общий для этих двух запросов уникальный идентификатор.
5. Таким общим идентификатором может быть случайное уникальное имя поддомена домена измерений.
6. Это имя должно генерироваться в момент обращения ĸ веб-сайту измерений, загружаться в качестве адреса фрагмента контента популярного веб-сайта, чтобы резолвер конечного пользователя обратился ĸ авторитетному серверу домена измерений для разрешения этого имени.
7. При загрузке фрагмента контента происходит логирование запроса конечного пользователя на HTTP-сервере веб-сайта измерений.
8. При разрешении случайного доменного имени происходит логирование запроса резолвера на авторитетном сервере доменных имён домена измерений.
9. Раз в сутки по расписанию скрипты обработки логов HTTP-сервера веб- сайта измерений и авторитетного сервера DNS домена измерений выбирают метаданные обращений конечных пользователей из соответствующих логов и загружают эти данные в общую базу данных.
10. На основе полученных данных производится их анализ, верификация и получение статистических отчетов.

Диаграмма последовательностей изложенного выше алгоритма представлена ниже (Рис. 5.).

Рис. 5. Диаграмма последовательностей системы измерений.

Для выполнения исследования были развернуты HTTPS-сервер Apache; DNS-сервер bind; зарегистрированы и делегированы домены resolvers.net.ru и resolvers.org.ru; размещён сайт измерений на домене resolvers.net.ru, для сайта получены и установлены wild-card TLS-сертификаты; установлена СУБД PostgreSQL и в её среде развернута БД измерений; написаны скрипты сбора и обработки статистики; разработан сайт проекта [9], на котором транслируются результаты измерений.

Отдельно следует указать площадки измерений, с которыми достигнута договорённость о размещении измерительных скриптов.

В настоящее время необходимые договорённости достигнуты для сайтов и их синонимов:

• org.ru
• net.ru
• pp.ru
• taeping.ru
• netoscope.ru
• cctld.ru

Первые три – это домены третьего уровня, регистратурой которых является АНО «ЦВКС МСК-IX» [10], далее – регистратор доменов в этом реестре и два ресурса администратора национальных доменов Российской Федерации (.ru/.рф) – АНО «Координационный центр национального домена сети Интернет» (КЦ).

Домены третьего уровня довольно часто используются для целей поисковой оптимизации. В статистике обращений к авторитетным серверам зоны .ru они занимают значимую долю. Время жизни таких доменов невелико, поэтому их администраторы довольно часто посещают сайт регистратуры и регистратора.

В настоящее время в этой регистратуре зарегистрировано 14 регистраторов [11], в том числе и все крупные регистраторы национальных доменов РФ.

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

А вот сайт netoscope.ru стоит отметить отдельно. Здесь сведена статистика по репутации доменов второго уровня в национальных доменных зонах. Проект Netoscope был учрежден КЦ при участии уполномоченных компетентных организаций, которые занимаются вопросами информационной безопасности [12].

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

В описываемом исследовании этот момент важен с точки зрения репрезентативности измерений.

Согласно данным iddb, наиболее масштабные пулы IP-адресов имеют следующие российские AS [13]:

Рис. 6. Список российских aut-num. Источники данных – базы данных RIR.

Если теперь сравнить этот список со списком источников запросов из «студенческой» работы, то увидим, что все эти AS там есть (Рис. 7, отмечены галочками):

Рис. 7. AS-источники запросов к системе измерений использования резолверов.

При этом порядок расположения автономных систем в списке с рисунка 7 хорошо коррелирует с порядком расположения автономных систем в списке с рисунка 6, т.е. с количеством IP-адресов.

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

Конечно, результат был бы более надёжным, если бы для сравнения провести измерения с использованием рекламных площадок Yandex или VK на ограниченном промежутке времени, и такие измерения, возможно, будут проведены в будущем.

На текущий момент в рамках исследования были получены следующие результаты.

Список наиболее популярных резолверов для конечных пользователей российских AS (Рис. 8) по результатам измерений:

Рис. 8. Список наиболее популярных резолверов для конечных пользователей российских AS.

В то время как у APNIC Labs [14] (Рис. 9):

Рис. 9. Список наиболее популярных резолверов для российских пользователей по версии APNIC Labs.

Из представленных таблиц понятно, что у APNIC Labs список крупных российских AS не полон и списки используемых резолверов существенно отличаются. Резолверы в заголовке упорядочены по их популярности в мире. Для российских провайдеров этот порядок не соблюдается.

Есть ещё один важный момент, который заставляет сомневаться в репрезентативности данных APNIC Labs – там нет резолверов НСДИ (имена начинаются с «RIPN-…»). А это точно не соответствует действительности, т.к. использование НСДИ обязательно, и это подтверждается другой статистикой, например, статистикой обращений к авторитетным серверам национальных доменов.

Таким образом, вывод о нерепрезентативности измерений APNIC Labs подтверждается.

Любопытно, что насыщения списка автономных систем в данной системе измерений не достигнуто (Рис. 10):

Рис. 10. Насыщение списка автономных систем

Таким образом, потенциал роста этого списка, а с ним и потенциал увеличения репрезентативности измерений есть.

«Комбинированные краулеры»

Вторая представленная на конференции работа была посвящена комбинированным инструментам измерения. В рассмотренной выше работе Анны Подгук фактически проводились «пассивные» измерения. Но существует большой набор программ-инструментов, которые проводят «активные» измерения применения различных интернет-технологий. Такой вид программ принято называть краулерами.

Суть краулера в обходе информационных ресурсов Сети и сборе специфических технических параметров. Большинство современных интернет-сервисов построены по принципу «клиент/сервер», т.е. клиент посылает запрос, а сервер присылает ответ на данный запрос. Соответственно, под термином «обход» понимают опрос информационных ресурсов из заранее заданного или динамического списка по различным протоколам и сбор ответов с последующим их разбором.

Отдельной проблемой при интерпретации таких данных является их визуализация. Особенно это касается графической визуализации результатов исследований.

Целью работы Артёма Ождихина было исследование вариантов визуализации для «протокол-независимой» логики.

Вот цитата из его презентации, которая достаточно обще описывает смысл работы: «Сложность инфраструктуры, стоящей за современными интернет-сервисами, возникает как результат сопряжения различных сетевых протоколов, работающих на разных уровнях, но влияющих друг на друга. Например, использование HTTPS для доступа к DNS. При этом многие “технологические феномены” становятся хорошо видны только через достаточно общие методы визуализации, отталкивающиеся от “протокол-независимой” логики. DNS, являясь элементом фундамента Интернета, как раз предоставляет отличную точку старта для визуализации устройства прочих интернет-сервисов».

Нельзя сказать, что это первая работа такого рода. Хорошо известны, например, такие системы:

• IDDB.RU (графическое представление связности автономных систем);
• DNSViz (графическое представление структуры DNSSEC с верификацией протоколов);
• программный пакет HViz (визуализация трафика HTTPS).

Разрабатываемый краулер позволяет не только проверить наличие того или иного технического параметра у информационного ресурса, но также верифицирует применение той или иной интернет-технологии.

В качестве инструментов для написания кода в работе использовались:

• Golang (язык программирования);
• специализированные библиотеки meikg/dns (обращение к ресурсам Интернета по различным протоколам);
• стандартные библиотеки;
• GraphViz (для отображения результатов работы краулера).

На рисунке 11 представлен пример результатов анализа, разработанный краулером:

Рис. 11. Результат работы краулера по верификации структуры DNS и HTTPS для домена конференции.

В настоящее время данный инструмент используется в качестве прототипа в исследованиях Фонда «ИнДата». Работы ведутся в части расширения списка протоколов, расширения измерений на адресное пространство IPv6 и расширения API в сторону стандартизации в стиле REST API.

Важной особенностью данного инструмента является его переносимость и всеплатформенность. В отличие от перечисленных ранее инструментов, которые по сути являются сайтами (кроме последнего), разработанный студентом программный комплекс является прикладной программой, которую можно использовать вне связи с каким-либо сайтом.

Вместо заключения

Конференция в Минске была второй после пандемии, у которой был предусмотрен офлайн-формат. Если в 2023 году в Петрозаводск участники ехали с некоторой опаской, то в Минске собрался весь обычный состав участников за исключением наших прибалтийских коллег.

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

Практически не было проходных докладов. Все презентации вызывали живой интерес участников, тем отраднее было отметить, что работы наших студентов в этом контексте не выглядели чем-то второстепенным и неинтересным. И хотя все эти работы по своей сути можно описать фразой «повторение – мать учения», т.к. все они в той или иной степени повторяли разработки международных лабораторий, тем не менее, новизны и актуальности в них было достаточно, чтобы участники конференции их отметили.

Список литературы:

1. Matthew Thomas, «Chromium’s impact on root DNS traffic», https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-dns-traffic/, 21/08/2020
2. VeriSign’s Site Finder Implementation, https://web.archive.org/web/20041109202247/http://www.verisign.com/static/002702.pdf, 27/08/2003
3. Roy Arends and Nicolas Antoniello, «Hyperlocal Root Zone Technical Analysis», ОСТО-027, https://www.icann.org/en/system/files/files/octo-027-25aug21-en.pdf, 25/08/2021
4. «Национальная система доменных имен (НСДИ)», ГРЧЦ, https://portal.noc.gov.ru/ru/news/2022/08/25/nsdi/, 25/08/2022
5. Geoff Huston, «DNS resolver centrality», APNIC, https://blog.apnic.net/2019/09/23/dns-resolver-centrality/, 23/08/19
6. Use of DNS Resolvers for World (XA), APNIC, https://stats.labs.apnic.net/rvrs, 31/10/2024
7. IDDB, Фонд «ИнДата», https://www.ididb.ru/, 31/10/2024
8. Фонд развития сетевых технологий «ИнДата», https://www.indata.org.ru/, 31/10/2024
9. Проект «DNS Resolver Use», https://resolvers.net.ru/, 31/10/2024
10. АНО «ЦВКС МСК-IX», https://www.ccni.ru/, 31/10/2024
11. «Аккредитованные регистраторы в доменах NET.RU, PP.RU, ORG.RU», АНО «ЦВКС МСК-IX», https://org.ru/registrars.html, 31/10/2024
12. «Список компетентных организаций», АНО «Координационный центр национального домена сети Интернет», https://cctld.ru/help/safety/competent/, 31/10/2024
13. «Список российских aut-num», проект «IDDB», Фонд «ИнДата», https://www.ididb.ru/autnum/, 31/10/2024
14. «Use of DNS Resolvers for Russian Federation (RU)», APNIC, https://stats.labs.apnic.net/rvrs/RU?o=cXAw1l1s0t10x, 31/10/2024

Об авторе:
Храмцов Павел Брониславович, к.т.н., доцент, научный руководитель проектов фонда «ИнДата», Москва.