RFC 8484 · октябрь 2018
DNS-запросы через HTTPS (DoH)
Авторы: P. Hoffman, ICANN; P. McManus, Mozilla. Категория: процесс стандартизации. ISSN 2070-1721. Октябрь 2018.
Аннотация
Документ определяет протокол отправки DNS-запросов и получения DNS-ответов через HTTPS. Каждая пара DNS-запроса и ответа отображается в обмен HTTP.
Статус документа
Это документ процесса стандартизации Интернета.
Документ подготовлен Инженерной группой Интернета (IETF). Он отражает консенсус сообщества IETF, прошёл публичное обсуждение и одобрен к публикации Руководящей группой инженерных работ Интернета (IESG). Дополнительные сведения о стандартах Интернета приведены в разделе 2 RFC 7841.
Информация о текущем статусе документа, исправлениях и порядке отправки отзывов доступна по адресу https://www.rfc-editor.org/info/rfc8484.
Уведомление об авторских правах
Copyright (c) 2018 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.
На документ распространяются BCP 78 и Правовые положения IETF Trust, относящиеся к документам IETF (https://trustee.ietf.org/license-info), действовавшие на дату публикации. Внимательно ознакомьтесь с ними: они описывают ваши права и ограничения в отношении документа. Компоненты кода, извлечённые из документа, должны включать текст Упрощённой лицензии BSD, как описано в разделе 4.e Правовых положений Trust, и предоставляются без гарантий согласно Упрощённой лицензии BSD.
1. Введение
Документ определяет конкретный протокол DNS поверх HTTPS (DoH) для отправки DNS-запросов [RFC1035] и получения DNS-ответов через HTTP [RFC7540] с использованием URI https [RFC2818], а следовательно, защиты целостности и конфиденциальности посредством TLS [RFC8446]. Каждая пара DNS-запроса и ответа отображается в обмен HTTP.
Описанный подход представляет собой не просто туннель поверх HTTP. Он определяет типы медиаформатов по умолчанию для запросов и ответов, но использует обычные механизмы согласования содержимого HTTP для выбора альтернатив, которые конечные стороны могут предпочесть в расчёте на новые сценарии применения. Наряду с согласованием медиатипов подход согласован с возможностями HTTP, такими как кэширование, перенаправление, проксирование, аутентификация и сжатие.
Интеграция с HTTP обеспечивает транспорт, пригодный как для существующих DNS-клиентов, так и для нативных веб-приложений, которым необходим доступ к DNS.
При разработке протокола рассматривались два основных сценария: предотвращение вмешательства устройств на пути передачи в работу DNS и предоставление веб-приложениям безопасного доступа к сведениям DNS через существующие браузерные API способом, совместимым с Cross Origin Resource Sharing (CORS) [FETCH]. Специальных усилий для разрешения или предотвращения других применений не предпринималось. Документ посвящён взаимодействию DNS-клиентов, например конечных резолверов операционных систем, с рекурсивными резолверами.
2. Терминология
Сервер, поддерживающий этот протокол, называется «сервером DoH», чтобы отличать его от «DNS-сервера», который предоставляет службу DNS только через один или несколько других стандартизованных для DNS транспортных протоколов. Аналогично клиент, поддерживающий этот протокол, называется «клиентом DoH».
Ключевые слова MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY и OPTIONAL следует толковать согласно BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они написаны целиком прописными буквами, как показано здесь.
3. Выбор сервера DoH
Клиент DoH настраивается с помощью шаблона URI [RFC6570], описывающего, как построить URL для разрешения имён. Настройка, обнаружение и обновление шаблона URI выполняются вне этого протокола. Настройка может быть ручной, например пользователь вводит шаблоны URI в интерфейсе параметров, или автоматической, например шаблоны URI предоставляются в ответах DHCP либо аналогичных протоколов. Серверы DoH МОГУТ (MAY) поддерживать несколько шаблонов URI. Это позволяет конечным точкам иметь разные свойства, например разные требования к аутентификации или гарантии уровня обслуживания.
Клиент DoH использует конфигурацию для выбора URI и тем самым сервера DoH для разрешения имён. В [RFC2818] определено, как HTTPS проверяет подлинность сервера DoH.
Клиент DoH НЕ ДОЛЖЕН (MUST NOT) использовать другой URI только потому, что он обнаружен вне конфигурации клиента, например через HTTP/2 server push, или потому, что сервер предоставил незапрошенный ответ, который выглядит действительным ответом на DNS-запрос. Эта спецификация не предоставляет полномочия на разрешение DNS тем URI, которые клиент DoH не распознаёт как настроенные. Такие сценарии могут создавать дополнительные эксплуатационные риски, риски отслеживания и безопасности, для безопасного применения требующие ограничений. Будущая спецификация может поддержать этот сценарий.
4. Обмен HTTP
4.1. HTTP-запрос
Клиент DoH кодирует один DNS-запрос в HTTP-запрос с использованием метода HTTP GET или POST и в соответствии с остальными требованиями этого раздела. Сервер DoH определяет URI запроса посредством шаблона URI.
При методе HTTP POST определённый документом шаблон URI обрабатывается без переменных. При методе GET единственная переменная dns определяется как содержимое DNS-запроса согласно разделу 6, закодированное в base64url [RFC4648].
Будущие спецификации новых медиатипов DoH ОБЯЗАНЫ (MUST) определять переменные, используемые для обработки шаблона URI в этом протоколе.
Серверы DoH ОБЯЗАНЫ (MUST) реализовывать оба метода: POST и GET.
При использовании POST DNS-запрос включается в тело HTTP-запроса, а поле заголовка запроса Content-Type указывает медиатип сообщения. Запросы POST обычно меньше эквивалентных запросов GET.
Метод GET более удобен для многих реализаций HTTP-кэша.
Клиенту DoH СЛЕДУЕТ (SHOULD) включать поле заголовка HTTP-запроса Accept, чтобы указать, какой тип содержимого он способен обработать в ответе. Независимо от значения заголовка Accept клиент ОБЯЗАН (MUST) быть готовым обработать ответы application/dns-message, описанные в разделе 6, но МОЖЕТ (MAY) обрабатывать и другие полученные медиатипы, связанные с DNS.
Чтобы повысить эффективность HTTP-кэширования, клиентам DoH, использующим медиаформаты с полем ID заголовка DNS-сообщения, например application/dns-message, СЛЕДУЕТ (SHOULD) использовать DNS ID, равный 0, в каждом DNS-запросе. HTTP сопоставляет запрос с ответом, поэтому поле ID в таком медиатипе, как application/dns-message, не нужно. При изменяющемся DNS ID семантически эквивалентные DNS-запросы могут кэшироваться отдельно.
Клиенты DoH могут применять дополнение и сжатие HTTP/2 [RFC7540] так же, как и другие клиенты HTTP/2 — либо не применять их.
4.1.1. Примеры HTTP-запросов
В примерах используется форматирование в стиле HTTP/2 из [RFC7540].
В примерах служба DoH использует шаблон URI «https://dnsserver.example.net/dns-query{?dns}» для разрешения записей IN A.
Запросы представлены телами с медиатипом application/dns-message.
В первом примере метод GET используется для запроса www.example.com:
:method = GET :scheme = https :authority = dnsserver.example.net :path = /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB accept = application/dns-message
Тот же DNS-запрос для www.example.com с использованием POST:
:method = POST :scheme = https :authority = dnsserver.example.net :path = /dns-query accept = application/dns-message content-type = application/dns-message content-length = 33
<33 байта в следующем шестнадцатеричном представлении> 00 00 01 00 00 01 00 00 00 00 00 00 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01
В этом примере 33 байта представляют DNS-сообщение в сетевом формате DNS [RFC1035], начиная с DNS-заголовка.
Наконец, GET-запрос для a.62characterlabel-makes-base64url-distinct-from-standard-base64.example.com приведён, чтобы подчеркнуть отличие алфавита кодирования base64url от обычного base64 и отсутствие дополнения padding.
DNS-запрос в сетевом формате DNS состоит из следующих 94 байтов:
00 00 01 00 00 01 00 00 00 00 00 00 01 61 3e 36 32 63 68 61 72 61 63 74 65 72 6c 61 62 65 6c 2d 6d 61 6b 65 73 2d 62 61 73 65 36 34 75 72 6c 2d 64 69 73 74 69 6e 63 74 2d 66 72 6f 6d 2d 73 74 61 6e 64 61 72 64 2d 62 61 73 65 36 34 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01
:method = GET
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query? (без пробела или возврата каретки CR)
dns=AAABAAABAAAAAAAAAWE-NjJjaGFyYWN0ZXJsYWJl (без пробела или CR)
bC1tYWtlcy1iYXNlNjR1cmwtZGlzdGluY3QtZnJvbS1z (без пробела или CR)
dGFuZGFyZC1iYXNlNjQHZXhhbXBsZQNjb20AAAEAAQ
accept = application/dns-message
4.2. HTTP-ответ
Единственный тип ответа, определённый документом, — application/dns-message, но в будущем могут быть определены другие форматы ответа. Сервер DoH ОБЯЗАН (MUST) уметь обрабатывать запросы application/dns-message.
Разные медиатипы ответа предоставляют больше или меньше информации из DNS-ответа. Например, один тип ответа может включать информацию из байтов DNS-заголовка, а другой — опускать её. Объём и тип предоставляемой медиатипом информации определяются исключительно форматом, который данным протоколом не определяется.
Каждая пара DNS-запроса и ответа отображается в один обмен HTTP. Ответы могут обрабатываться и передаваться в любом порядке с использованием нескольких потоков HTTP (см. раздел 5 [RFC7540]).
В разделе 5.1 рассматривается взаимосвязь кэширования DNS- и HTTP-ответов.
4.2.1. Обработка ошибок DNS и HTTP
Коды ответа DNS указывают на успех или неудачу DNS-запроса. Успешный HTTP-ответ с кодом состояния 2xx (см. раздел 6.3 [RFC7231]) используется для любого действительного DNS-ответа независимо от его кода ответа DNS. Например, успешный код состояния HTTP 2xx используется даже для DNS-сообщения с кодом ответа DNS, указывающим на ошибку, например SERVFAIL или NXDOMAIN.
HTTP-ответы с неуспешными кодами состояния не содержат ответов на первоначальный DNS-вопрос из HTTP-запроса. Клиенты DoH должны обрабатывать неуспешные коды состояния HTTP с той же семантикой, что и другие HTTP-клиенты. Это может означать повтор запроса к тому же серверу DoH, например при ошибках авторизации: код состояния HTTP 401, раздел 3.1 [RFC7235]. Также это может означать повтор с другим сервером DoH, например при неподдерживаемом медиатипе: код HTTP 415, раздел 6.5.13 [RFC7231], либо если сервер не может создать подходящее клиенту представление: код HTTP 406, раздел 6.5.6 [RFC7231], и т. д.
4.2.2. Пример HTTP-ответа
Это пример ответа на запрос записей IN AAAA для www.example.com с включённой рекурсией. Ответ содержит одну запись с адресом 2001:db8:abcd:12:1:2:3:4 и TTL 3709 секунд.
:status = 200 content-type = application/dns-message content-length = 61 cache-control = max-age=3709
<61 байт в следующем шестнадцатеричном представлении> 00 00 81 80 00 01 00 01 00 00 00 00 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 1c 00 01 c0 0c 00 1c 00 01 00 00 0e 7d 00 10 20 01 0d b8 ab cd 00 12 00 01 00 02 00 03 00 04
5. Интеграция с HTTP
Этот протокол ОБЯЗАТЕЛЬНО (MUST) используется со схемой URI https [RFC7230].
Дополнительные вопросы интеграции с HTTP рассматриваются в разделах 8 и 9.
5.1. Взаимодействие с кэшем
Обмен DoH может проходить через иерархию кэшей, включающую как HTTP-, так и DNS-специфичные кэши. Они могут находиться между сервером и клиентом DoH либо на самом клиенте. HTTP-кэши по своей природе универсальны и не понимают этот протокол. Даже если клиент DoH модифицировал реализацию своего кэша для учёта семантики DoH, отсюда не следует, что это сделали все вышестоящие кэши, например промежуточные прокси, серверные шлюзы и сети доставки содержимого.
Поэтому серверам DoH необходимо тщательно выбирать метаданные HTTP-кэширования, отправляемые в ответ на GET-запросы. Ответы на POST-запросы нельзя кэшировать без определённых полей заголовков ответа; это редко реализуется и не рекомендуется для DoH.
В частности, серверам DoH СЛЕДУЕТ (SHOULD) задавать явное время актуальности HTTP-ответа (раздел 4.2 [RFC7234]), чтобы повысить вероятность использования клиентом DoH актуальных DNS-данных. Это требование связано с тем, что HTTP-кэши могут сами назначать эвристическое время актуальности, например согласно разделу 4.2.2 [RFC7234], из-за чего сервер DoH теряет контроль над содержимым кэша.
Назначенное время актуальности HTTP-ответа DoH ОБЯЗАТЕЛЬНО (MUST) меньше или равно наименьшему TTL в разделе Answer DNS-ответа. РЕКОМЕНДУЕТСЯ (RECOMMENDED) значение, равное наименьшему TTL в разделе Answer. Например, если HTTP-ответ содержит три набора ресурсных записей (RRset) с TTL 30, 600 и 300, время актуальности HTTP должно составлять 30 секунд; это можно указать как Cache-Control: max-age=30. Требование помогает предотвратить непреднамеренную выдачу из HTTP-кэша сообщений с истёкшими RRset.
Если в разделе Answer DNS-ответа нет записей, но в разделе Authority есть SOA-запись, время актуальности ответа НЕ ДОЛЖНО (MUST NOT) превышать значение поля MINIMUM этой SOA-записи (см. [RFC2308]).
Директивы Cache-Control stale-while-revalidate и stale-if-error [RFC5861] могут хорошо подходить для реализации DoH, если это допускается политикой сервера. По усмотрению сервера эти механизмы разрешают клиенту повторно использовать запись HTTP-кэша, срок актуальности которой истёк. В таком случае клиент использует кэшированную запись целиком либо не использует её вовсе.
Серверам DoH также необходимо учитывать HTTP-кэширование при формировании ответов, не являющихся общезначимыми. Например, если сервер DoH адаптирует ответ к идентичности клиента, он не захочет допустить его глобальное повторное использование. Этого можно достичь различными средствами HTTP, например Cache-Control с max-age, равным 0, либо полем заголовка ответа Vary (раздел 7.1.4 [RFC7231]) для задания вторичного ключа кэша (раздел 4.1 [RFC7234]).
Клиенты DoH ОБЯЗАНЫ (MUST) учитывать значение поля заголовка ответа Age [RFC7234] при вычислении DNS TTL ответа. Например, если RRset получен с DNS TTL 600, а заголовок Age указывает, что ответ находился в кэше 250 секунд, оставшееся время жизни RRset составляет 350 секунд. Требование относится как к HTTP-кэшам, так и к DNS-кэшам клиента DoH.
Клиенты DoH могут запрашивать некэшированную копию HTTP-ответа с помощью директивы no-cache заголовка запроса Cache-Control (раздел 5.2.1.4 [RFC7234]) и аналогичных средств. Некоторые кэши могут не соблюдать эти директивы из-за конфигурации или взаимодействия с обычными DNS-кэшами, не имеющими такого механизма.
Условные HTTP-запросы [RFC7232] могут быть ограниченно полезны для DoH: повторная проверка даёт выигрыш лишь в расходе полосы, тогда как DNS-транзакции обычно ограничены задержкой. Кроме того, поля HTTP-заголовка ответа, обеспечивающие повторную проверку, например Last-Modified и Etag, часто достаточно велики по сравнению с полным размером DNS-ответа, а их изменчивость создаёт постоянную нагрузку на словарь сжатия HTTP/2 [RFC7541]. Другие виды DNS-данных, например передачи зон, могут быть больше и получать от повторной проверки больше пользы.
5.2. HTTP/2
HTTP/2 [RFC7540] — минимальная РЕКОМЕНДУЕМАЯ (RECOMMENDED) версия HTTP для DoH.
Сообщения классического DNS на основе UDP [RFC1035] по своей природе неупорядочены и имеют небольшие накладные расходы. Для сопоставимой производительности конкурентоспособный HTTP-транспорт должен поддерживать изменение порядка, параллелизм, приоритеты и сжатие заголовков. Эти возможности были добавлены в HTTP/2 [RFC7540]. Более ранние версии HTTP способны передавать семантические требования DoH, но могут работать очень медленно.
5.3. Server Push
Прежде чем использовать данные ответа DoH для DNS-разрешения, клиент ОБЯЗАН (MUST) установить, что URI HTTP-запроса можно использовать для этого запроса DoH. Для HTTP-запросов, инициированных клиентом DoH, это подразумевается выбором URI. При HTTP server push (раздел 8.2 [RFC7540]) необходимо дополнительно убедиться, что предоставленный сервером URI совпадает с URI, на который клиент направил бы тот же запрос при его собственной инициации; это дополняет другие проверки безопасности, обычно необходимые для server push.
5.4. Согласование содержимого
Для максимальной совместимости клиенты и серверы DoH ОБЯЗАНЫ (MUST) поддерживать медиатип application/dns-message. Другие медиатипы МОГУТ (MAY) использоваться согласно механизму согласования содержимого HTTP (раздел 3.4 [RFC7231]). Эти медиатипы ОБЯЗАНЫ (MUST) быть достаточно гибкими, чтобы выразить любой DNS-запрос, обычно отправляемый через DNS поверх UDP, включая запросы и ответы с расширениями DNS, но исключая запросы, требующие нескольких ответов.
6. Определение медиатипа application/dns-message
Полезная нагрузка медиатипа application/dns-message — одно сообщение в сетевом формате DNS, определённом в разделе 4.2.1 [RFC1035], который, в свою очередь, ссылается на полный сетевой формат раздела 4.1 этого RFC.
Хотя [RFC1035] утверждает, что «сообщения, передаваемые через UDP, ограничены 512 байтами», позже это положение было обновлено [RFC6891]. Данный медиатип ограничивает максимальный размер DNS-сообщения 65535 байтами.
Сетевой формат этого медиатипа отличается от используемого в [RFC7858], где применяется формат раздела 4.2.2 [RFC1035] с двумя байтами длины.
Клиенты DoH, использующие этот медиатип, МОГУТ (MAY) включать в запрос один или несколько параметров механизмов расширения DNS (EDNS) [RFC6891]. Серверы DoH с этим медиатипом ОБЯЗАНЫ (MUST) игнорировать значение размера полезной нагрузки EDNS UDP в DNS-запросах.
При использовании GET полезная нагрузка медиатипа ОБЯЗАТЕЛЬНО (MUST) кодируется в base64url [RFC4648] и передаётся в раскрытие шаблона URI как переменная с именем dns. Символы дополнения base64url НЕ ДОЛЖНЫ (MUST NOT) включаться.
При использовании POST полезная нагрузка медиатипа НЕ ДОЛЖНА (MUST NOT) кодироваться и используется непосредственно как тело HTTP-сообщения.
7. Вопросы IANA
7.1. Регистрация медиатипа application/dns-message
Имя типа: application Имя подтипа: dns-message Обязательные параметры: не применимо Необязательные параметры: не применимо Особенности кодирования: это двоичный формат. Содержимое представляет собой DNS-сообщение согласно RFC 1035. Используемый формат — DNS поверх UDP, определённый схемами RFC 1035. Вопросы безопасности: см. RFC 8484. Содержимое является DNS-сообщением, а не исполняемым кодом. Вопросы совместимости: отсутствуют. Опубликованная спецификация: RFC 8484. Приложения, использующие медиатип: системы, которым необходимо обмениваться полными DNS-сообщениями.
Дополнительная информация: Устаревшие альтернативные имена типа: не применимо Магические числа: не применимо Расширения файлов: не применимо Коды типов файлов Macintosh: не применимо Контактное лицо и адрес электронной почты для дополнительной информации: Paul Hoffman <paul.hoffman@icann.org> Предполагаемое использование: COMMON (общее) Ограничения использования: не применимо Автор: Paul Hoffman <paul.hoffman@icann.org> Орган управления изменениями: IESG
8. Вопросы конфиденциальности
В [RFC7626] рассматриваются вопросы конфиденциальности DNS как «при передаче» (раздел 2.4 [RFC7626]), так и «на сервере» (раздел 2.5 [RFC7626]). Такое разделение полезно и для вопросов конфиденциальности DoH.
8.1. При передаче
DoH шифрует DNS-трафик и требует аутентификации сервера. Это снижает риски как пассивного наблюдения [RFC7258], так и активных атак, пытающихся перенаправить DNS-трафик на поддельные серверы (раздел 2.5.1 [RFC7626]). DNS поверх TLS [RFC7858] предоставляет аналогичную защиту, тогда как прямые транспорты на основе UDP и TCP уязвимы к этому классу атак. Экспериментальные рекомендации по выбору длины дополнения приведены в [RFC8467].
Кроме того, использование порта HTTPS по умолчанию 443 и возможность смешивать трафик DoH с другим HTTPS-трафиком в одном соединении могут препятствовать вмешательству не обладающих особыми привилегиями устройств на пути передачи в работу DNS и затруднять анализ DNS-трафика.
8.2. На сервере
Сетевой формат DNS [RFC1035] не содержит идентификаторов клиента; однако различные способы передачи DNS-запросов и ответов предоставляют данные, которые можно использовать для сопоставления запросов. HTTPS добавляет новые возможности сопоставления, например явные HTTP cookies и неявное определение отпечатка по уникальному набору и порядку полей заголовков HTTP-запроса.
Реализация DoH строится на IP, TCP, TLS и HTTP. Каждый уровень содержит одну или несколько распространённых возможностей, которые можно использовать для связывания запросов с одной идентичностью. Транспорты DNS обычно наследуют свойства конфиденциальности уровней, на которых они реализованы. Например, свойства IP, TCP и TLS применимы к реализациям DNS поверх TLS.
Вопросы конфиденциальности, связанные с уровнем HTTPS в DoH, дополняют вопросы DNS поверх TLS. Не известно, чтобы DoH порождал новые проблемы сверх тех, что связаны с HTTPS.
На уровне IP адрес клиента предоставляет очевидные сведения для сопоставления. Это можно смягчить использованием NAT, прокси, VPN или простой сменой адреса со временем. Проблема может усугубляться при использовании DNS-сервера, способного сопоставлять текущие адресные данные с другими персональными идентификаторами, например когда DNS-сервер и DHCP-сервер эксплуатируются одной организацией.
Реализации DNS, использующие одно TCP-соединение для нескольких DNS-запросов, непосредственно объединяют эти запросы. Долгоживущие соединения производительнее краткоживущих, однако объединяют больше запросов, что раскрывает больше информации для сопоставления и объединения. Решения на основе TCP могут также повышать производительность с помощью TCP Fast Open [RFC7413]. Используемые в TCP Fast Open cookies позволяют серверам сопоставлять TCP-сеансы.
Реализации на основе TLS часто улучшают производительность рукопожатия с помощью механизма возобновления сеанса, например описанного в разделе 2.2 [RFC8446]. Возобновление сеанса предоставляет серверу простой механизм связывания TLS-соединений друг с другом.
Возможности HTTP также можно использовать для идентификации и отслеживания различными способами. Например, поля заголовка запроса Authentication явно идентифицируют используемые профили, а HTTP cookies предназначены для явного отслеживания состояния между клиентом и обслуживающим сайтом и часто применяются для аутентификации.
Кроме того, поля заголовков запроса User-Agent и Accept-Language часто передают конкретную информацию о версии клиента или локали. Это облегчает согласование содержимого и эксплуатационные обходные решения для ошибок реализации. Поля заголовков запроса, управляющие кэшированием, могут раскрывать сведения о состоянии части истории клиента. Смешивание запросов DoH с другими HTTP-запросами в одном соединении также создаёт возможность более широкого сопоставления данных.
Конструкция протокола DoH позволяет приложениям использовать всю экосистему HTTP, включая возможности, не перечисленные здесь. Использование полного набора возможностей HTTP делает DoH чем-то большим, чем HTTP-туннель, но ценой подверженности реализаций всему набору вопросов конфиденциальности HTTP.
При решении, включать ли эти возможности, реализациям клиентов и серверов DoH необходимо учитывать их пользу, влияние на конфиденциальность и контекст развёртывания. Реализациям рекомендуется раскрывать минимальный набор данных, необходимый для желаемой функциональности.
Особенно важно определить, требуется ли реализации DoH поддержка HTTP cookies [RFC6265], поскольку они являются основным механизмом отслеживания состояния в HTTP. Клиентам DoH НЕ СЛЕДУЕТ (SHOULD NOT) принимать HTTP cookies, если они явно не требуются сценарием использования.
9. Вопросы безопасности
Работа DNS поверх HTTPS зависит от безопасности лежащего в основе HTTP-транспорта. Это снижает риск классических атак с усилением для DNS на базе UDP. Реализации, использующие HTTP/2, получают преимущества профиля TLS, определённого в разделе 9.2 [RFC7540].
Шифрование на уровне сеанса имеет известные слабости в отношении анализа трафика, которые могут быть особенно существенны для DNS-запросов. HTTP/2 содержит дополнительные рекомендации по использованию сжатия (раздел 10.6 [RFC7540]) и дополнения padding (раздел 10.7 [RFC7540]). Серверы DoH также могут добавлять DNS padding [RFC7830], если клиент DoH запрашивает его в DNS-запросе. Экспериментальные рекомендации по выбору длины дополнения приведены в [RFC8467].
HTTPS-соединение обеспечивает транспортную безопасность взаимодействия клиента и сервера DoH, но не обеспечивает целостность DNS-ответов, предоставляемую DNSSEC. DNSSEC и DoH — независимые, полностью совместимые протоколы, решающие разные задачи. Использование одного не уменьшает необходимости или полезности другого. Клиент сам выбирает: полностью проверять ответы с помощью DNSSEC либо доверить проверку серверу DoH и проверять бит AD (Authentic Data) в полученном сообщении, чтобы определить подлинность ответа. Как отмечено в разделе 4.2, разные медиатипы ответа предоставляют разный объём информации из DNS-ответа, поэтому этот выбор может зависеть от медиатипа.
В разделе 5.1 описано взаимодействие протокола с HTTP-кэшированием. Злоумышленник, способный управлять используемым клиентом кэшем, может влиять на представление этого клиента о DNS. Это ничем не отличается от последствий HTTP-кэширования для безопасности других протоколов, использующих HTTP.
При отсутствии информации DNSSEC сервер DoH может предоставить клиенту недействительные данные в ответ на DNS-запрос. Раздел 3 запрещает использовать DNS-ответы DoH, не исходящие от настроенных серверов. Этот запрет не гарантирует защиты от недействительных данных, но уменьшает риск.
10. Эксплуатационные вопросы
Локальные политики и подобные факторы приводят к тому, что разные DNS-серверы могут выдавать разные результаты на один запрос, например при раздельных конфигурациях DNS [RFC6950]. Отсюда логически следует, что выбранный сервер может влиять на конечный результат. Поэтому выбор клиентом DNS-сервера может влиять на получаемые ответы. Например, в случае DNS64 [RFC6147] выбор может определить, будет ли вообще работать преобразование между IPv6 и IPv4.
Канал HTTPS, используемый спецификацией, устанавливает защищённую двустороннюю связь между клиентом и сервером DoH. Системы фильтрации или проверки, которые полагаются на незащищённую передачу DNS, не будут работать в среде DNS поверх HTTPS из-за защиты конфиденциальности и целостности посредством TLS.
Некоторые реализации HTTPS-клиентов в реальном времени проверяют у третьей стороны статус отзыва сертификатов, используемых TLS. Если проверка выполняется при подключении к серверу DoH и сама требует DNS-разрешения для связи с третьей стороной, может возникнуть взаимная блокировка. Примеры — использование серверов Online Certificate Status Protocol (OCSP) [RFC6960] или Authority Information Access (AIA) для получения списка отзыва сертификатов CRL (раздел 4.2.2.1 [RFC5280]). Чтобы уменьшить вероятность взаимной блокировки, аутентификации серверов DoH НЕ СЛЕДУЕТ (SHOULD NOT) зависеть от DNS-ссылок на внешние ресурсы во время TLS-рукопожатия. Для OCSP сервер может включить статус сертификата в рукопожатие с помощью механизма, соответствующего версии TLS, например раздела 4.4.2.1 [RFC8446] для TLS 1.3. Блокировок AIA можно избежать, предоставив промежуточные сертификаты, которые иначе пришлось бы получать дополнительными запросами. Такие блокировки необходимо учитывать и для серверов, на которые сервер DoH может перенаправить клиента.
Клиент DoH может столкнуться с аналогичной проблемой первоначальной настройки, когда HTTP-запросу необходимо разрешить имя хоста из DNS URI. Подобно тому как адрес традиционного DNS-сервера нельзя первоначально определить с помощью этого же сервера, клиент DoH не может использовать свой сервер DoH для первоначального разрешения его имени в адрес. Возможные альтернативы: 1) включить первоначальное разрешение в конфигурацию; 2) использовать URI на основе IP-адреса и соответствующие IP-сертификаты для HTTPS; 3) разрешить имя хоста сервера DNS API через традиционный DNS или другой сервер DoH, при этом аутентифицируя результирующее соединение через HTTPS.
HTTP [RFC7230] — протокол прикладного уровня без сохранения состояния, поэтому реализации DoH не дают основанных на состоянии гарантий порядка между разными запросами. DoH нельзя использовать как транспорт для других протоколов, требующих строгого порядка.
Сервер DoH вправе отвечать на запросы любым действительным DNS-ответом. Например, действительный ответ может содержать установленный бит TC (усечение) DNS-заголовка, показывающий, что сервер не смог получить полный ответ и предоставляет лучший из доступных. Сервер DoH может отвечать HTTP-ошибкой на запросы, которые не может выполнить. В том же примере сервер DoH мог бы использовать HTTP-ошибку вместо неошибочного ответа с установленным битом TC.
За годы с использованием [RFC6891] были определены многие расширения DNS. Расширения, зависящие от выбранного транспорта, например [RFC7828], к DoH неприменимы.
11. Ссылки
11.1. Нормативные ссылки
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
<https://www.rfc-editor.org/info/rfc2308>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570,
DOI 10.17487/RFC6570, March 2012,
<https://www.rfc-editor.org/info/rfc6570>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
DOI 10.17487/RFC7232, June 2014,
<https://www.rfc-editor.org/info/rfc7232>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>.
[RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
<https://www.rfc-editor.org/info/rfc7541>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015,
<https://www.rfc-editor.org/info/rfc7626>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
11.2. Информационные ссылки
[FETCH] "Fetch Living Standard", August 2018,
<https://fetch.spec.whatwg.org/>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale
Content", RFC 5861, DOI 10.17487/RFC5861, May 2010,
<https://www.rfc-editor.org/info/rfc5861>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011,
<https://www.rfc-editor.org/info/rfc6147>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/info/rfc6891>.
[RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba,
"Architectural Considerations on Application Features in
the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013,
<https://www.rfc-editor.org/info/rfc6950>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>.
[RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
edns-tcp-keepalive EDNS0 Option", RFC 7828,
DOI 10.17487/RFC7828, April 2016,
<https://www.rfc-editor.org/info/rfc7828>.
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
DOI 10.17487/RFC7830, May 2016,
<https://www.rfc-editor.org/info/rfc7830>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms
for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
October 2018, <https://www.rfc-editor.org/info/rfc8467>.
Приложение A. Разработка протокола
В приложении описаны требования, использованные при проектировании DoH. Они приведены, чтобы помочь понять существующий протокол, а не ограничить его возможное будущее развитие. Приложение не является нормативным.
При проектировании протокола исходили из следующих требований:
— протокол должен использовать обычную семантику HTTP; — запросы и ответы должны быть достаточно гибкими, чтобы выразить каждый DNS-запрос, обычно передаваемый через DNS поверх UDP, включая использующие расширения DNS запросы и ответы, но исключая запросы, требующие нескольких ответов; — протокол должен допускать добавление новых форматов DNS-запросов и ответов; — протокол должен обеспечивать совместимость, определяя единый обязательный для реализации формат запросов и ответов. Этот формат должен поддерживать будущие изменения протокола DNS, включая один или несколько параметров EDNS, в том числе ещё не определённых; — протокол должен использовать защищённый транспорт, удовлетворяющий требованиям HTTPS.
Следующее не считалось требованиями:
— поддержка DNS64, специфичного для сети [RFC6147]; — поддержка иных специфичных для сети выводов из открытых DNS-запросов; — поддержка незащищённого HTTP.
Приложение B. Предыдущие работы по DNS поверх HTTP или в других форматах
Ниже приведён неполный список ранних работ, связанных с DNS поверх HTTP/1 или представлением DNS-данных в других форматах. В список включены ссылки на tools.ietf.org, поскольку срок действия всех указанных документов истёк, и на сайты программного обеспечения.
https://tools.ietf.org/html/draft-mohan-dns-query-xml https://tools.ietf.org/html/draft-daley-dnsxml https://tools.ietf.org/html/draft-dulaunoy-dnsop-passive-dns-cof https://tools.ietf.org/html/draft-bortzmeyer-dns-json https://www.nlnetlabs.nl/projects/dnssec-trigger/
Благодарности
Эта работа потребовала тесного сотрудничества экспертов в разных технологиях. Благодарим Ray Bellis, Stephane Bortzmeyer, Manu Bretelle, Sara Dickinson, Massimiliano Fantuzzi, Tony Finch, Daniel Kahn Gilmor, Olafur Gudmundsson, Wes Hardaker, Rory Hewitt, Joe Hildebrand, David Lawrence, Eliot Lear, John Mattsson, Alex Mayrhofer, Mark Nottingham, Jim Reid, Adam Roach, Ben Schwartz, Davey Song, Daniel Stenberg, Andrew Sullivan, Martin Thomson и Sam Weiler.
Адреса авторов
Paul Hoffman ICANN
Email: paul.hoffman@icann.org
Patrick McManus Mozilla
Email: mcmanus@ducksong.com
Перевод: RFCNET · rfcnet.ru
Original copyright notice
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Hoffman & McManus Standards Track [Page 1]
RFC 8484 DNS Queries over HTTPS (DoH) October 2018
Неофициальный перевод. При расхождениях см. оригинал.