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

Автор статьи: Александр Венедюхин, ведущий аналитик ТЦИ

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

DNS является распределённой базой данных, в которой, действительно, можно сохранять пары «сетевой адрес – имя узла». Этому соответствуют A- и AAAA-записи (первые – для IPv4-адресов, вторые – для IPv6). Однако сама система доменных имён значительно шире, а набор записей, которые в ней можно размещать, гораздо богаче. Поэтому возможности DNS используются во многих сетевых протоколах разных уровней, а далеко не только при поиске IP-адресов для установления TCP-соединения.

Напомним основные принципы построения DNS: эта система (и сервис) позволяет отыскать данные по ключу, которым обычно является некоторая цепочка символьных строк, разделённых точками (всем привычные доменные имена: www.example.com). DNS-данные сохраняются в глобальной иерархической и распределённой структуре из серверов имён, а иерархия поиска как раз и задаётся порядком строк, составляющих ключ. Данные публикуются в записях различных типов: SOA, NS, MX и др. Типы определяют то, как интерпретируются данные, и позволяют для одного ключа (имени) размещать несколько наборов данных, различая их по типам. Так, для определения IPv4-адреса в DNS запрашивается запись типа A, например, для имени www.test.ru (в DNS существуют ещё и различные классы записей, но в этой статье мы рассматриваем только класс IN - Internet).

В принципе, DNS достаточно универсальна для того, чтобы несложным способом опубликовать в ней любые данные. Обычно для произвольных данных используют запись с типом TXT. Эта запись, как несложно догадаться по её названию, позволяет публиковать алфавитно-цифровые строки. Чтобы опубликовать ту или иную последовательность байтов, достаточно закодировать её подходящим образом, – например, в Base64, – и разместить результат в TXT-записи. TXT-записи можно компоновать как внутри одного имени (несколько TXT-записей), так и используя специальную иерархию имён. Это создаёт теоретическую возможность для размещения блоков данных любой мыслимой длины. На практике, конечно, использовать DNS для конденсированного размещения гигабайтов данных – довольно плохая идея: система предназначена для публикации и поиска коротких блоков информации.

TXT-записи повсеместно используются для публикации вспомогательных сведений, привязанных к доменной зоне, если соответствующий протокол по какой-то причине не имеет собственного типа записи. Хрестоматийный пример – политики SPF (Sender Policy Framework), защищающие электронную почту от спуфинга (подмены адресов). SPF представляет собой механизм авторизации, используемый при приёме сообщений почтовыми серверами. Авторизация основывается на публикации администратором доменной зоны сведений об IP-адресах узлов, которые могут отправлять почту из данного домена. У связки DNS и SPF интересная история. Изначально SPF-данные было предложено публиковать именно в TXT-записях, в виде текстовой строки определённого формата. Позже для продвижения новой технологии в DNS был добавлен отдельный тип – SPF-запись, – однако от использования этого нового типа быстро отказались, и сейчас для публикации политик SPF повсеместно используются TXT-записи (более того, спецификация предписывает применять только TXT).

TXT-записи для имени google.com, извлечённые при помощи утилиты dig

С электронной почтой связан целый набор специальных DNS-инструментов. Помимо только что описанного механизма SPF, используются также DKIM (Domain Keys Identified Mail) и DMARC (Domain-based Message Authentication, Reporting and Conformance). DKIM служит для криптографического подтверждения «подлинности» сервера-отправителя (и целостности текста сообщения), а DMARC позволяет управлять методом использования SPF и DKIM для защиты электронной почты. DKIM основан на электронной подписи, поэтому использует DNS для публикации открытых ключей, необходимых серверам-получателям при проверке подписей из технических конвертов почтовых сообщений. Данные DKIM тоже публикуются в TXT-записях, но используют специальное имя, включающее символ подчёркивания («_»), который запрещён в «обычных» DNS-именах. Это довольно занимательный аспект: действительно, для так называемых имён хостов (hostname) допустимы только буквы латинского алфавита, цифры и символ «минус» («-»), а в качестве разделителя используется точка («.»), поэтому доменная зона, содержащая в своём имени символы, отличные от перечисленных, будет считаться поименованной некорректно. Это, однако, не означает, что в DNS не может быть строк, содержащих другие символы набора ASCII. Поэтому символ подчёркивания применяется для имён, которые по своему назначению не могут быть именами хостов (интернет-узлов). Так, для размещения ключей DKIM используется имя _domainkey (пример: dkim._domainkey.test.ru).

Нередко требуется подтвердить, что некоторый аккаунт в том или ином сервисе действительно принадлежит администратору определённой доменной зоны. Например, для выпуска TLS-сертификата или для получения доступа к сведениям, соответствующим данному домену, в поисковой системе. В этом случае тоже широко используется система доменных имён и TXT-записи: обычный способ подтвердить право администрирования – размещение TXT-записи со значением идентификатора («токена»), который выдаёт система, запрашивающая проверку.

DNS хорошо подходит для размещения информации, необходимой другим коммуникационным протоколам при установлении соединения. Это исключительная особенность данной системы. В одной из прошлых статей описывается технология ESNI (или ECH), использующая DNS для публикации криптографических ключей, которые позволяют дополнительно защитить TLS-сессию от утечек информации. Размещение в DNS ключей для подобных задач обычно является оптимальным вариантом, поскольку клиент, использующий TLS для доступа к веб-ресурсу, всё равно должен выполнить запрос в DNS, чтобы определить IP-адрес сервера. ESNI-ключи сейчас размещаются в TXT-записях. Статистику по использованию ESNI для российских доменных зон можно посмотреть на сайте проекта Statdom.ru.

Вспомогательные сведения о криптографических ключах могут размещаться и в записях специального типа. Примером такой DNS-записи является SSHFP, которая предназначена для публикации отпечатков серверных SSH-ключей. Как известно, при использовании SSH для безопасного доступа к серверу клиент должен удостовериться, что открытый ключ, представленный сервером, совпадает с тем ключом, который связан с данным сервером на стороне клиента. Обычно отпечатки ключей известных серверов SSH-клиент сохраняет в специальном файле. Однако при первом подключении к ранее неизвестному серверу клиент вынужден либо доверять любому ключу, который предоставляет сервер, либо должен проверить отпечаток ключа каким-то способом вне SSH. DNS-запись SSHFP как раз предоставляет такой способ проверки: отпечаток серверного ключа публикуется под именем, соответствующим серверу, а для удостоверения подлинности используется DNSSEC.

Многие политики, применяемые в глобальной Сети, привязаны к доменным зонам. Одним из примеров является политика выпуска TLS-сертификатов для конкретных доменов. Так, сертификаты, используемые в вебе и электронной почте, привязаны к сетевому имени (реже – к IP-адресу), при этом удостоверяющие центры могут выпускать сертификаты для произвольного имени. Для того, чтобы администратор доменной зоны мог определить политику выпуска TLS-сертификатов, служит CAA-запись. Эта запись позволяет разместить в DNS-зоне идентификаторы тех УЦ, которым разрешено выпускать сертификаты для имён в зоне, а также указать сопроводительную информацию, например, контактный адрес администратора.

Другой пример, опять же связанный с TLS, - это DNS-запись TLSA, которая соответствует технологии DANE (DNS-Based Authentication of Named Entities). DANE – это механизм публикации криптографической информации в DNS, предназначенный для размещения сведений о серверных TLS-сертификатах (и ключах). Это довольно старая технология, основная идея которой состоит в использовании DNSSEC для удостоверения TLS-сертификатов вместо удостоверяющих центров или в качестве дополнения к ним. TLSA-записи по способу применения похожи на SSHFP. Отличие состоит в том, что TLSA предназначается для использования с TLS. Изначально DANE (и, соответственно, TLSA) разрабатывались с прицелом на HTTPS, однако сейчас данная технология с HTTPS почти не используется, но получила некоторое распространение в системах электронной почты, где TLS служит для защиты сессий при доставке сообщений (SMTP, STARTTLS и др.).

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

Например, идёт работа над черновиком (draft) спецификации для DNS-записей с рабочим названием SVCB/HTTPS. Предполагается, что эти записи будут использоваться для публикации данных, определяющих начальные настройки доступа к интернет-ресурсам под данным доменным именем. Отличие от уже имеющихся типов записей (например, от адресных записей) весьма существенное: записи SVCB/HTTPS позволят публиковать сразу набор сведений о нескольких «фронтендах», ответственных за соответствующий сервис (например, веб) под заданным именем; в этот набор включаются разнообразные дополнительные параметры, например, определяющие нестандартные номера портов TCP/UDP, на которых отвечают серверы, или криптографические ключи, позволяющие установить соединение со скрытым сервисом.

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

Возврат к списку