DNS как источник глобальной информации о Сети

Александр Венедюхин

Система доменных имён DNS и соответствующий ей сервис, обеспечивающий поиск, является частью фундаментальной инфраструктуры Интернета. Практически любое обращение к сервисам Интернета, будь то посещение веб-сайта, отправка электронной почты, сообщение мессенджера или открытие приложения на смартфоне, начинается с запроса к этой системе. А раз так – DNS представляет собой богатый источник данных для самых разных измерений в глобальной Сети.

Введение

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

Так, упомянутые выше роли DNS (система и сервис) позволяют рассматривать Сеть под разными углами: как с точки зрения инфраструктуры адресации, так и с точки зрения доступа конечного пользователя к узлам и ресурсам, адресуемым доменными именами.

Инфраструктура адресации, применительно к DNS, это иерархия имён, заданная на множестве авторитативных серверов. Авторитативным (иногда также используют русскоязычный термин «авторитетный») называется сервер имён, который уполномочен отвечать на запросы об адресации внутри той или иной доменной зоны, то есть пространства имён. Такие «полномочия» у сервера возникают из его отношений с другими авторитативными серверами DNS, в рамках операции делегирования, позволяющей одним авторитативным серверам делегировать другим авторитативным серверам управление подмножеством имён в своей зоне ответственности. Например, сервер A, отвечающий за доменную зону второго уровня test.ru, может делегировать зону третьего уровня name. test.ru серверу C. В таком случае для поиска DNS-записи с именем внутри name.test.ru, например, для long.name.test. ru, резолверу потребуется обратиться к серверу C.

Как сервис поиска, DNS решает задачу обнаружения в иерархии записей по известному ключу некоторого значения. Этот процесс принято называть рекурсивным резолвингом (англ. resolve, resolving). Чаще всего в пример приводят один из самых распространённых сценариев использования DNS: определение IP-адреса, соответствующего имени узла, или, в технических терминах, поиск адресной записи (A-записи или AAAA-записи) для имени хоста. Здесь ключом является символьное имя, например, google.com, а значением – IP-адрес, извлечённый из адресной записи. Для DNS важна возможность установить, что искомой DNS-записи в системе не задано. Это состояние в DNS отличается от состояния, когда запись по каким-то причинам не удалось найти. Подтверждённое отсутствие записи для заданного имени является одним из эффективных инструментов измерения, который позволяет, например, изучать те или иные сервисы, работающие в Сети.

Фундаментальным свойством DNS, со всех точек зрения, является кеширование значений DNS-записей. Именно кеширование делает данную систему распределённой и очень устойчивой. Само по себе кеширование не оказывает влияния на содержание DNS-записей, однако метод управления временем кеширования, использующий поля со значением TTL (Time To Live), может являться источником содержательной статистики. В частности, анализ значений TTL, передаваемых авторитативными серверами для разных DNS-записей и разных DNS-имён, позволяет исследовать настройки CDN и механизмов балансировки нагрузки.

Информация об инфраструктуре

Процессу делегирования в DNS соответствуют NS-записи. NS-запись содержит перечень имён серверов (авторитативных), которые должны отвечать на запросы о записях в данной зоне. Другими словами, NS-записи содержат списки ≪главных≫ серверов и позволяют сопоставить перечень NS каждой делегированной зоне. Делегирование начинается от корневого домена (он обозначается ≪пустым именем≫ или просто точкой, часто обозначение корневого домена просто опускают). На первом уровне делегирования находятся домены верхнего уровня: com., net., org., ru., su. и др. Второй уровень, соответственно, это всем привычные домены вида google.com., ididb.ru. и т. д. При рекурсивном поиске записей резолвер получает перечень серверов имён, которые могут предоставить ответ на искомый запрос. Если какая-то доменная зона опубликована в DNS, то ей должны соответствовать те или иные NS-записи (точнее, для этой зоны должно быть возможно обнаружить авторитативные серверы). При этом процесс регистрации доменного имени не обязательно связан с делегированием этого имени. Имя может быть зарегистрировано, но при этом быть недоступно в DNS. В таком случае говорят, что домен не делегирован. Итак, данные о делегировании доступны в глобальной DNS, а для корректно делегированных доменов всегда возможно получить некоторый набор имён авторитативных серверов: он возвращается серверами, находящимися уровнем выше, в ответ на DNS-запрос. Например, перечень авторитативных серверов для домена test.ru можно получить в ответ на запрос к авторитативным серверам домена ru. Это и есть базовый шаг алгоритма сбора сведений из DNS.

Система доменных имён (DNS — Domain Name System) и соответствующий ей сервис, обеспечивающий поиск записей (его тоже обозначают DNS, но только последняя буква обозначает Service), являются богатым источником исходных сведений для самых разных измерений в глобальной Сети.

Сбор сведений выполняется силами рекурсивного DNS-резолвера. Иногда это специально настроенный для решения конкретных задач сбора данных резолвер, на входе у которого обычно список  делегированных имён. Для зон верхнего уровня этот список можно получить различными способами, в зависимости от действующих политик. Например, для ≪новых доменов≫ верхнего уровня (New gTLD) ICANN поддерживает центральный сервис Centralized Zone Data Service, предоставляющий единый интерфейс для доступа к спискам имён. Сведения о делегировании являются источником важной информации о распределении имён, об административном делении доменного адресного пространства. Во многих случаях доменные имена делегируются на авторитативные серверы, принадлежащие провайдеру хостинга или доменному регистратору.

Как эти данные используются? Возьмём список делегированных имён второго уровня в домене ru. Для каждого имени получим список авторитативных DNS-серверов (это ответ на запрос NS-записей). Агрегируем полученные ответы по уникальным именам DNS-серверов и посчитаем количество имён, делегированных на каждый из авторитативных серверов – результат отражает распределение имён по различным провайдерам DNS-сервисов. Уже такая элементарная статистика позволяет получить следующие сведения:

• общее количество различных (по именам) авторитативных серверов. Этот показатель часто удивляет неспециалистов: например, в зоне ru делегировано около 4,7 миллиона зон (август 2019), при этом различных имён авторитативных серверов — лишь около 130 тысяч;

• рейтинг провайдеров: у каких провайдеров большое количество доменных зон на обслуживании (по именам DNS-серверов, которые можно сопоставить с провайдерами). Обычно лидерами такого рейтинга оказываются провайдеры бесплатного DNS-хостинга, регистраторы доменов и хостеры, а также крупные доменные парковки. Если дополнительно отобразить имена авторитативных серверов в IP-адреса и распределить их по автономным системам (AS), то получим рейтинг AS по числу размещённых доменных зон, таким способом, например, можно увидеть услуги DNS-хостинга типа Whitelabel, когда имена серверов соответствуют одному провайдеру, но физически сервис предоставляется другим.

• ≪степень разнообразия≫ серверов имён: какая доля от всех делегированных зон размещена на наиболее популярных авторитативных серверах (по именам). Например, в зоне ru около 30% имен второго уровня сосредоточены на серверах трёх-пяти крупных провайдеров, каждый из которых поддерживает сотни тысяч зон.

Интересно, что наличие имён авторитативных серверов в делегирующей зоне вовсе не означает, что указанные серверы действительно обслуживают делегированное имя. Более того, в некоторых случаях под указанным именем вовсе нет доступного DNS-сервера. «Дефектное имя» в делегирующей зоне может появиться из-за ошибки (простой опечатки), а также и по другим причинам.

DNS повсеместно используется для публикации адресов и другой информации, связанной с теми или иными сервисами, работающими под данным доменным именем. Самым важным и распространённым, конечно, является веб-сервис, использующий для адресации A- и AAAA-записи. Как известно, эти записи содержат IP-адреса, v4 и v6 соответственно. Раньше типовым способом публикации адреса веб-сервиса (веб-узла) являлось использование поддомена (префикса) www., например, вот так: www. example.com. Сейчас данная практика перестала быть повсеместной и веб-сервис обычно доступен по «базовому» имени: example.com. Нередко поддомен www. сохраняется в качестве синонима либо с www. выполняется HTTP-редирект на имя без этого префикса; возможна, впрочем, и обратная ситуация: так, google.com перенаправляет веб-запросы на www.google.com, аналогичным образом поступает и facebook.com. Тем не менее, общепринятый сейчас вариант — перенаправление с www. на имя без специального префикса. Это пример того, что уже алгоритм использования префикса www. администраторами доменных зон позволяет собирать сведения о том, как настроена адресация веб-сервиса для данного имени.

Нужно заметить, что A- или AAAA-записи вовсе не являются специально предназначенными для адресации веб-узлов, они несут только IP-адреса, без привязки к одному конкретному сервису. Например, эти записи могут адресовать почтовые серверы, авторитативные DNS-серверы, а также и любые другие. Тем не менее, в современном Интернете использование записей этого типа для адресации веб-узлов является очень распространённым сценарием. Анализ значений А- и AAAA-записей даёт много информации об инфраструктуре Сети:

• наличие AAAA-записей позволяет сделать предположение об IPv6-коннективности узла, адресуемого исследуемой зоной;
• IP-адреса можно сопоставить с номерами автономных систем, получив, таким образом, проекцию доменного пространства в административную структуру, то есть можно определить, у каких провайдеров хостинга размещены веб-узлы, адресуемые различными именами, или почтовые серверы;
• подсчёт «разнообразия» используемых IP-адресов позволяет определить, насколько доменные имена сконцентрированы на тех или иных узлах. Например, в случае веба один и тот же IP-адрес в A-записи нередко соответствует тысячам и десяткам тысяч имён.

Так как адресные (A-, AAAA-) записи позволяют сопоставить доменным именам IP-адреса, можно с их помощью исследовать BGP-маршруты, связанные с теми или иными доменными кластерами. Например, можно увидеть особенности маршрутизации различных CDN или обнаружить транзитные автономные системы, через которые проходит много трафика электронной почты.

Записи, размещаемые в DNS, сейчас довольно разнообразны. Практически все они служат источником интересной информации, если анализируются на достаточно большой выборке. Свежий пример: не так давно появилась технология ESNI (Encrypted Server Name Indication), позволяющая скрыть имя сервера, с которым клиент устанавливает TLS-соединение. Пока что (август 2019) эта технология имеет статус проекта (draft), но уже поддерживается браузером Mozilla Firefox на стороне клиента, а на стороне сервера – одним из крупнейших CDN-провайдеров: Cloudflare. ESNI существенным образом использует DNS — в доменной зоне публикуются криптографические ключи. Поэтому сканирование доменного пространства на предмет ESNI-записей позволяет обнаружить узлы, которые (потенциально) реализуют защищённую передачу имени сервера. При этом оказывается, что почти 100% таких узлов, адресуемых именами в домене .ru, размещены в сетях Cloudflare. Более того, они используют небольшое количество криптографических ключей, то есть многие узлы используют один и тот же ключ (это не является какой-то уязвимостью и полностью допускается спецификацией). Все эти сведения обнаруживаются при помощи анализа DNS-записей. А наличие ESNI-ключей является маркером, обнаружить который можно только при помощи сканирования DNS, несмотря на то что сама технология применима к TLS (защищённому протоколу обмена данными на базе TCP, который DNS не использует).

Отдельный интерес представляет DNSSEC — механизм защиты адресной информации, публикуемой в DNS. С данной технологией связаны специальные DNS-записи, которые позволяют опубликовать электронные подписи, удостоверяющие данные DNS, а также ключи, необходимые для проверки подписей. DNSSEC пока что используется очень редко, тем не менее, позволяет обнаружить безопасные (то есть удостоверенные) зоны, выявить зоны, настроенные с ошибками, классифицировать эти ошибки. Также полезной оказывается статистика используемых криптографических ключей и криптосистем. Например, исследование записей, относящихся к DNSSEC, позволяет обнаружить доменные зоны, которые были некорректно перенесены от одного провайдера DNS-хостинга к другому.

Отметим, что DNS также широко используется для хранения информации о соответствии IP-адресов именам хостов, то есть ключом в этом случае является IP-адрес. Выполнение этой функции обеспечивают так называемые обратные зоны. С их помощью можно определить символьное имя узла, зная только его IP-адрес (конечно, лишь в том случае, если соответствующая запись есть в обратной зоне). Этот инструмент применяется, например, в процессе доставки электронной почты – в качестве источника дополнительного признака «подлинности» узла-источника сообщения. Аналогичную роль обратные зоны играют в процессе авторизации удалённого пользователя SSH-серверами. С точки зрения исследований Интернета, обратные зоны позволяют получить информацию о том, как распределены площадки хостинга по провайдерам, в каких случаях для веб-узлов обратные зоны настроены в соответствии с прямыми, а в каких — нет (например, при размещении множества веб-узлов на общем IP-адресе).

В таблицах 1, 2 и 3 приведены некоторые данные, полученные путем измерения DNS.

Таблица 1. Top-20 автономных систем*.

*— В данных системах размещены веб-ресурсы, адресуемые доменами .ru, .рф, .su. Рейтинг построен путём
определения принадлежности блока IP-адресов из A-записей (июль 2019, источник: ididb.ru).

Таблица 2. Версии ПО**.

**— получены на основе анализа сигнатур в ответах авторитативных серверов имён для зоны .ru, по количеству уникальных IP-адресов (июль 2019, источник: statdom.ru)

Таблица 3. Количество уникальных IP-адресов***.

***— полученны для веб-узлов и TLS-узлов на основе анализа DNS российских национальных TLD (июль 2019, источник: ididb.ru).

Рис. 1. Схема измерения пользовательских резолверов.

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

Предположим, что это зона test.ru. Также настраивается веб-сервер, основная задача которого отправлять браузеру клиента код веб-страницы в составе ссылки на ресурс, специальное уникальное имя хоста, находящееся в зоне test.ru. (Сам веб-сервер может работать под адресом в любой другой зоне, это не важно.) Так как код веб-страницы ссылается на ресурс, расположенный в зоне test.ru., браузеру потребуется определить адрес (A- или AAAA-запись) для этого ресурса. Соответственно, браузер обратится к тому или иному резолверу, что, в конечном итоге, приведёт к отправке запросов к авторитативным серверам зоны test.ru. Авторитативные серверы зафиксируют источник запроса — его IP-адрес.

Отличить один запрос от другого авторитативный сервер может потому, что в составе запрашиваемого имени присутствует уникальная метка. Например, конкретное имя может выглядеть так:  e13f1732ab.test.ru. Здесь крайняя слева подстрока является таким уникальным кодом. В веб-страницу соответствующий код может быть встроен в составе ссылки на изображение, например, так: . Остаётся только получить веб-трафик (это и есть «праймер»), то есть пользователи должны открыть веб-страницу браузером.

Клиентская сторона

Типичный сценарий использования DNS на стороне клиента сводится к взаимодействию прикладных программ с системным резолвером, а через него — с рекурсивным резолвером провайдера доступа (системный резолвер чрезвычайно редко является полноценным рекурсивным). Сейчас распространена ситуация, когда вместо резолвера, предоставляемого провайдером доступа, пользователи настраивают открытые рекурсивные резолверы крупных DNS-сервисов. Примерами таких сервисов являются Google Public DNS (известен как 8.8.8.8) и Cloudflare DNS (1.1.1.1). В ряде случаев использование подобных «внешних» сервисов резолвинга прямо поддерживается прикладной программой. Например, современные версии браузера Mozilla Firefox могут непосредственно обращаться к такому резолверу, минуя системный (для этого используется протокол DNS-over-HTTPS).

Рекурсивный резолвер, обслуживающий того или иного пользователя, в общем случае определить не так просто. Сканирование адресного пространства, подобное тому, которое используется при анализе доменных зон, но только в отношении IP, не даёт нужного результата по двум основным причинам: во-первых, провайдерские рекурсивные резолверы обычно закрыты для доступа из других сетей, поэтому не видны снаружи; во-вторых, даже если список резолверов удалось построить, то это не означает, что тот или иной пользователь настроил в своей системе именно этот резолвер. Таким образом, измерение клиентских резолверов и их характеристик (например, типичного времени ответа, настроек кеширования) представляет собой отдельную интересную задачу.

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

Как работает данный метод?  Принцип работы и схема этого метода приведена на рисунке 1.

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

• распределение трафика DNS-запросов по провайдерам (в том числе, по провайдерам сервисов DNS-резолвинга);
• настройки времени кеширования резолверов;
• поддержка DNSSEC, в том числе, наличие валидации;
• время, затрачиваемое рекурсивным резолвером на получение ответа;
• географическое распределение резолверов, настройки внутренней балансировки для крупных провайдеров резолвинга.

Выводы

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

Источник: https://public.tableau.com/profile/rohit.sinha5535#!/ vizhome/Internet_15664048302500/Dashboard1

ИСПОЛЬЗОВЫВАНИЕ ВАЛИДАЦИИ ОТВЕТОВ DNS В РОССИИ

Источник: https://stats.labs.apnic.net/dnssec/RU

КОЛИЧЕСТВО СЕРТИФИКАТОВ LET’S ENCRYPT, ВЫПУЩЕННЫХ ЕЖЕДНЕВНО

Источник: https://letsencrypt.org/stats/#daily-issuance