RFC 9463 DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)

Internet Engineering Task Force (IETF)                 M. Boucadair, Ed.
Request for Comments: 9463                                        Orange
Category: Standards Track                                T. Reddy.K, Ed.
ISSN: 2070-1721                                                    Nokia
                                                                 D. Wing
                                                    Cloud Software Group
                                                                 N. Cook
                                                            Open-Xchange
                                                               T. Jensen
                                                               Microsoft
                                                           November 2023

DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)

Опции DHCP и Router Advertisement для обнаружения назначенных сетью распознавателей

PDF

Аннотация

В этом документе заданы новые опции DHCP и IPv6 Router Advertisement для обнаружения распознавателей DNS с шифрованием (например, DNS over HTTPS, DNS over TLS, and DNS over QUIC). Они позволяют, в частности, хосту узнавать имя домена аутентификации (Authentication Domain Name) вместе со списком IP-адресов и набором параметров сервиса для доступа к распознавателям DNS с шифрованием.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9463.

Авторские права

Авторские права (Copyright (c) 2023) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Revised BSD License).

1. Введение

Этот документ посвящён обнаружению распознавателей DNS с шифрованием, использующих такие протоколы, как DNS over HTTPS (DoH) [RFC8484], DNS over TLS (DoT) [RFC7858], DNS over QUIC (DoQ) [RFC9250] в локальных сетях. Документ, в частности, указывает, как подключённые хосты могут обнаружить локальный распознаватель DNS с шифрованием средствами DHCPv4 [RFC2132], DHCPv6 [RFC8415] и IPv6 Router Advertisement (RA) [RFC4861]. Эти опции предназначены для передачи имени домена аутентификации (ADN), списка адресов IP и набора параметров сервиса. Процедура называется обнаружением назначенных сетью распознавателей (Discovery of Network-designated Resolvers или DNR).

Заданные в этом документе опции могут быть внедрены в разных системах, например, в локальных сетях с оборудованием в помещениях заказчика (Customer Premises Equipment или CPE), которое может (не обязательно) управляться поставщиком услуг Internet (Service Provider или ISP), или в локальных сетях с узлами пересылки DNS (forwarder) или без них. Предоставление вариантов внедрения выходит за рамки документа. Не рассматриваются здесь и вопросы выбора распознавателей, а также политика (включая взаимодействие с пользователями).

2. Терминология

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

В этом документе применяются термины, определённые в [RFC8499], а также определённые ниже.

Authentication Domain Name (ADN) – имя домена аутентификации

ADN-only mode – режим с извлечением только ADN

Do53

DNR

Encrypted DNS – DNS с шифрованием

Encrypted DNS resolver – распознаватель DNS с шифрованием

Encrypted DNS options – опции DNS с шифрованием

DHCP

3. Обзор

Этот документ описывает, как клиент DNS может обнаружить локальные распознаватели DNS с шифрованием, используя опции DNS с шифрованием протоколов DHCP (разделы 4 и 5) и Neighbor Discovery (раздел 6). Эти опции задают ADN, список адресов IP и набор параметров сервиса распознавателя DNS с шифрованием. Дополнительные сведения об этих опциях приведены ниже.

3.1. Данные конфигурации для DNS с шифрованием

3.1.1. ADN как ссылочный идентификатор для аутентификации DNS

Для обеспечения возможности аутентификации распознавателя DNS клиенту на основе PKIX опции Encrypted DNS всегда включают ADN. Это имя представляется как ссылочный идентификатор для аутентификации DNS. Такое решение соответствует текущей практике выпуска сертификатов, как указано в параграфе 1.7.2 [RFC6125].

Некоторые удостоверяющие центры выпускают сертификаты на основе адресов IP, но предварительные данные показывают что такие сертификаты составляют очень малую (менее 1%) часть выдаваемых сертификатов.

3.1.2. Независимость от внешних распознавателей

Чтобы избежать при распознавании ADN зависимости от другого сервера, опции Encrypted DNS возвращают адрес(а) IP для распознавателя DNS с шифрованием. Такие распознаватели DNS могут размещаться на одном или разных адресах IP в зависимости от конкретного внедрения. Для оптимизации размера сообщений обнаружения, когда все распознаватели DNS размещаются по одному адресу IP, в ранних версиях этого документа рассматривалось применение механизмов обнаружения из [RFC2132], [RFC3646], [RFC8106] для получения списка адресов IP, по которым доступны распознаватели DNS. Однако токай подход требует от клиента, поддерживающего более одного протокола DNS с шифрованием (например, DoH и DoT), запрашивать этот список адресов IP. Чтобы избежать такого зондирования, опции, заданные в разделах 4 – 6 связывают протокол DNS с шифрованием и адрес IP. В результате зондирования не требуется.

3.1.3. Один или несколько адресов IP

Список адресов IP для доступа к распознавателю DNS с шифрованием может возвращаться в опции Encrypted DNS, чтобы приспособиться к имеющимся системам, полагающимися на первичный и резервный распознаватель. Кроме того, DNR можно использовать в контексте иных схем резервирования DNS (например, anycast из BCP 126 [RFC4786]).

Возврат одного или нескольких адресов IP в опции Encrypted DNS зависит от конкретной системы. Например, маршрутизатор со встроенным рекурсивным сервером или элементом пересылки (forwarder) будет включать один адрес IP, указывающий один из его интерфейсов в ЛВС. Обычно это приватный адрес IPv4, адрес Link-Local, уникальный локальный адрес IPv6 (Unique Local Address или ULA) или глобальный индивидуальный адрес (Global Unicast Address или GUA).

Если в опции Encrypted DNS возвращается несколько адресов IP, они упорядочиваются по приоритету для клиента.

3.1.4. Одна опция для ADN и адресов IP

Для передачи ADN и адресов IP используется одна опция, поскольку иначе потребовалось бы сопоставление передаваемого в опции адреса IP с ADN из другой опции (например, при наличии в сети более одного ADN).

3.1.5. Параметры сервиса

Поскольку в сети могут применяться разные протоколы DNS с шифрованием (например, DoT, DoH, DoQ) и некоторые из этих протоколов могут использовать настраиваемый номер порта вместо принятого по умолчанию, опции Encrypted DNS спроектированы для возврата набора параметров сервиса. Эти параметры кодируются по тем же правилам, что и SvcParams с использованием формата передачи, заданного в параграфе 2.2 [RFC9460]. Такое кодирование может увеличить размер опций, но его достоинством является использование имеющегося реестра IANA, что позволит использовать новые протоколы DNS с шифрованием и параметры сервиса, которые могут быть заданы в будущем. Реализации DNR должны поддерживать перечисленные ниже параметры сервиса.

alpn

port

Кроме того, рекомендуется поддерживать ещё один параметр.

dohpath

3.1.6. Режим ADN-Only

Следует применять режим, где хосту предоставляется ADN, список адресов IP и набор параметров сервиса распознавателя DNS с шифрованием, поскольку опции Encrypted DNS являются самодостаточными и не требуют дополнительных запросов DNS. В [RFC7969] представлен обзор расширенных возможностей, поддерживаемых серверами DHCP для заполнения данных конфигурации (например, запросы DNS).

В условиях, когда для запрашивающих хостов допустимы дополнительные сложности, можно рассмотреть возврат лишь ADN. Представленное имя ADN будет предеваться локальной библиотеке распознавания (обычно клиенту DNS), которая будет вносить запросы привязки сервиса (Service Binding или SVCB) [RFC9461]. Эти запросы SVCB могут передаваться самому обнаруженному распознавателю DNS с шифрованием или назначенному сетью распознавателю Do53. Отметим, что этот режим подвержен активным атакам, которые можно смягчить с помощью DNSSEC.

Передача ADN в локальную библиотеку распознавания зависит от реализации.

3.1.7. Упорядочение опций Encrypted DNS

Опции DHCP, заданные в разделах 4 и 5 упорядочиваются в соответствии с разделом 17 в [RFC7227], для опции RA (раздел 6) применяются рекомендации раздела 9 в [RFC4861].

3.1.8. Проверка действительности DNR

При получении опции Encrypted DNS клиент DHCP (или хост IPv6) выполняет указанные ниже проверки.

• Наличие ADN с кодированием в соответствии с разделом 10 в [RFC8415].

• При наличии дополнительных данных:

  • проверяется кодирование параметров сервиса в соответствии с правилами параграфа 2.2 в [RFC9460];

  • проверяется наличие хотя бы одного действительного адреса IP;

  • проверяется отсутствие в параметрах сервиса ipv4hint и ipv6hint.

При отрицательном результате любой из проверок получатель отбрасывает принятую опцию Encrypted DNS.

3.1.9. Другие механизмы для получения сведений DNR

Указанные в этом документе механизмы предоставления могут быть недоступны в конкретных сетях (например, в некоторых сотовых сетях применяются лишь опции настройки протокола (Protocol Configuration Options или PCOs) [TS.24008]) или не подходить в некоторых условиях (например, если требуется защищённое обнаружение). В таких случаях могут рассматриваться другие механизмы предоставления распознавателей DNS с шифрованием. Запрашивающим хостам рекомендуется предоставлять по меньшей мере указанные ниже сведения DNR.

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

• ADN (обязательный параметр).

• Список адресов IP для доступа к распознавателю DNS с шифрованием.

• Набор параметров сервиса.

3.2. Обработка конфликтов данных конфигурации

Если распознаватели DNS хост обнаруживает с помощью RA и DHCP, должны применяться правила параграфа 5.3.1 из [RFC8106].

Опции DHCP/RA для нахождения распознавателей DNS с шифрованием (включая шаблоны DoH URI) имеют преимущество перед DDR [RFC9462], так как в DDR применяется Do53 с внешним распознавателем DNS, подверженный внутренним и внешним атакам, а DHCP/RA обычно защищены (см. параграф 7.1).

Если клиент узнает Do53 и распознаватели DNS с шифрованием из одной сети и нет явной настройки, рекомендуется использовать для этой сети распознаватель DNS с шифрованием. Если клиент не может организовать защищённое и аутентифицированное соединение с распознавателем DNS с шифрованием, можно применять распознаватель Do53.

3.3. Проверка обнаруженных распознавателей

В этом параграфе описаны проверки для подтверждения соответствия распознавателя DNS с шифрованием полученному с помощью DNR (например, DHCP или RA). Эти проверки не предназначены для подтверждения безопасности механизмов предоставления DNR или доверительных отношений пользователя с сетью.

Если локальный клиент DNS поддерживает один из обнаруженных протоколв DNS с шифрованием, указанных идентификаторами протокола согласования прикладного уровня (Application-Layer Protocol Negotiation или ALPN) или иным параметром сервиса, указывающим механизм рассогласования протокола, клиент DNS организует шифрованную сессию DNS в соответствии с приоритетом обнаруженных распознавателей с шифрованием.

Клиент DNS проверяет соединение с помощью PKIX [RFC5280] из сертификата распознавателя DNS и применяет методы проверки [RFC6125] для сравнения ADN из опций Encrypted DNS с представленным сертификатом (параграф 8.1 в [RFC8310]). Клиент DNS использует привязки доверия системы или приложения PKI, если не заданы явные привязки доверия. Связанные с ALPN вопросы рассмотрены в параграфе 7.1 [RFC9460]. Вопросы, связанные с проверкой статуса отзыва сертификата распознавателя DNS с шифрованием, рассмотрены в разделе 10 [RFC8484].

3.4. Многодомные устройства

Устройства могут подключаться к нескольким сетям, каждая из которых обеспечивает свою конфигурацию DNS с помощью описанных здесь механизмов. Тем не менее, выбор DNS на многодомных устрйоствах выходит за рамки документа. Такие вопросы относятся к общим задачам обработки нескольких источников обеспечения и их не следует рассматривать отдельно, как это рекомендовано в разделе 12 [RFC7227].

В [RFC6731] рассматривается выбор DNS и приведён пример выбора распознавателя DNS на устройстве с несколькими интерфейсами. В [Local-DNS-Authority] рассмотрено применение DNR и ключа домена обеспечения (Provisioning Domain или PvD) dnsZones (параграф 4.3 в [RFC8801]) в средах с «расщеплением DNS» (раздел 6 в [RFC8499]).

4. Опция DHCPv6 в DNS с шифрованием

4.1. Формат опции

Формат опции DHCPv6 для DNS с шифрованием показан на рисунке 1.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       OPTION_V6_DNR           |         Option-length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Service Priority        |         ADN Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                   authentication-domain-name                  ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Addr Length           |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
~                        ipv6-address(es)                       ~
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
~                 Service Parameters (SvcParams)                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Опция DHCPv6 Encrypted DNS

Option-code

Option-length

Service Priority

ADN Length

authentication-domain-name (переменный размер)

+------+------+------+------+------+------+------+------+------+
| 0x04 |   d  |   o  |   h  |  1   | 0x07 |   e  |   x  |   a  |
+------+------+------+------+------+------+------+------+------+
|   m  |   p  |   l  |   e  | 0x03 |   c  |   o  |   m  | 0x00 |
+------+------+------+------+------+------+------+------+------+

Рисунок . Пример кодирования authentication-domain-name.

Addr Length

ipv6-address(es) (переменный размер)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                         ipv6-address                          |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ...                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Service Parameters (SvcParams) (переменный размер)

Поля Addr Length, ipv6-address(es) и Service Parameters (SvcParams) отсутствуют в режиме ADN-only (параграф 3.1.6).

4.2. Поведение клиента DHCPv6

Для обнаружения распознавателя DNS с шифрованием клиент DHCPv6 должен включить опцию OPTION_V6_DNR в опцию запроса опций (Option Request Option или ORO) в соответствии с параграфами 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, 21.7 в [RFC8415]. Клиент DHCPv6 должен быть готов получить несколько экземпляров опции OPTION_V6_DNR, каждый из которых считается представляющим отдельный распознаватель DNS с шифрованием. Эти экземпляры должны обрабатываться в соответствии с приоритетом сервиса (меньшее значение указывает больший приоритет).

Клиент DHCPv6 должен без уведомления отбрасывать любые опции OPTION_V6_DNR, не прошедшие проверку в соответствии с параграфом 3.1.8. Клиент DHCPv6 должен без уведомления отбрасывать групповые адреса и петлевые (loopback) адреса хоста, полученные в опции OPTION_V6_DNR.

5. Опция DHCPv4 в DNS с шифрованием

5.1. Формат опции

Формат опции DHCPv4 для DNS с шифрованием показан на рисунке 4.

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_V4_DNR |     Length    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~      DNR Instance Data #1     ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   ---
.              ...              .    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ необязательны
~      DNR Instance Data #n     ~    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   ---

Рисунок . Опция DHCPv4 Encrypted DNS.

Code

Length

DNR Instance Data

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    DNR Instance Data Length   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Service Priority        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ADN Length  |               |
+-+-+-+-+-+-+-+-+               |
~  authentication-domain-name   ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Addr Length  |               |
+-+-+-+-+-+-+-+-+               |
~        IPv4 Address(es)       ~
|               +-+-+-+-+-+-+-+-+
|               |               |
+-+-+-+-+-+-+-+-+               |
~Service Parameters (SvcParams) ~
|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

DNR Instance Data Length

Service Priority

ADN Length

authentication-domain-name (переменный размер)

Addr Length

IPv4 Address(es) (переменный размер)

0     8     16    24    32    40    48
+-----+-----+-----+-----+-----+-----+--
|  a1 |  a2 |  a3 |  a4 |  a1 |  a2 | ...
+-----+-----+-----+-----+-----+-----+--
  IPv4 Address 1          IPv4 Address 2 ...

Рисунок . Формат поля IPv4 Address.

Service Parameters (SvcParams) (переменный размер)

Поля Addr Length, IPv4 Address(es), Service Parameters (SvcParams) отсутствуют в режиме ADN-only (параграф 3.1.6).

Опция OPTION_V4_DNR требует конкатенации, поэтому должен применяться механизм [RFC3396], если OPTION_V4_DNR превышает максимальный размер опции DHCPv4 (255 октетов).

5.2. Поведение клиента DHCPv4

Для обнаружения распознавателя DNS с шифрованием клиент DHCPv4 запрашивает его включением опции OPTION_V4_DNR в опцию Parameter Request List [RFC2132]. Клиент DHCPv4 должен быть готов получить в опции OPTION_V4_DNR несколько записей DNR Instance Data, каждая из которых считается представляющей отдельный экземпляр распознавателя DNS с шифрованием. Эти записи должны обрабатываться в соответствии с приоритетом сервиса (меньшее значение указывает больший приоритет).

Клиент DHCPv4 должен без уведомления отбрасывать любые опции OPTION_V4_DNR, не прошедшие проверку в соответствии с параграфом 3.1.8. Клиент DHCPv4 должен без уведомления отбрасывать групповые адреса и петлевые (loopback) адреса хоста, полученные в опции OPTION_V4_DNR.

6. Опция IPv6 RA в DNS с шифрованием

6.1. Формат опции

В этом разделе определена новая опция обнаружения соседей (Neighbor Discovery) [RFC4861] – IPv6 RA Encrypted DNS. Опция полезна в условиях, похожих на рассмотренные в параграфе 1.1 [RFC8106].

Формат опции IPv6 RA Encrypted DNS показан на рисунке 7.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Length    |        Service Priority       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Lifetime                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          ADN Length           |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
~                   authentication-domain-name                  ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Addr Length           |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
~                        ipv6-address(es)                       ~
|                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |     SvcParams Length          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                 Service Parameters (SvcParams)                ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок . Опция RA.

Type

Length

Service Priority

Lifetime

ADN Length

authentication-domain-name (переменный размер)

Addr Length

ipv6-address(es) (переменный размер)

SvcParams Length

Service Parameters (SvcParams) (переменный размер)

Поля Addr Length, ipv6-address(es), SvcParams Length⁵ и Service Parameters (SvcParams) отсутствуют в режиме ADN-only (параграф 3.1.6).

Опция должна дополняться нулями до размера, кратного 8 октетам (параграф 4.6 в [RFC4861]).

6.2. Поведение хоста IPv6

Процедура настройки DNS такая же, как для других опций Neighbor Discovery [RFC4861]. Кроме того, хост следует процедуре из параграфа 5.3.1 в [RFC8106] при обработке опций Encrypted DNS с требованиями к форматированию из параграфа 6.1 проверками пригодности из параграфа 3.1.8, заменёнными проверкой размера и значений полей.

Хост должен быть готов получить несколько экземпляров опций Encrypted DNS в RA. Эти экземпляры должны обрабатываться в соответствии с приоритетом сервиса (меньшее значение указывает больший приоритет).

Хост должен без уведомления отбрасывать групповые адреса и петлевые (loopback) адреса хоста, полученные в опциях Encrypted DNS.

7. Вопросы безопасности

7.1. Атаки с подменой

Сообщения DHCP/RA не шифруются и не защищены от изменения внутри ЛВС. Если атаки с подменой не смягчены, как указано ниже, содержимое сообщений DHCP и RA может быть подделано или изменено активными атакующими, например, скомпрометированными устройствами в локальной сети. Активный атакующий (параграф 3.3 в [RFC3552]) может подделать отклик DHCP/RA предоставляя свой распознаватель DNS с шифрованием. Он может организовать и другие атаки, как отмечено в разделе 22 [RFC8415]. Злоумышленник может получить доменное имя с подтверждённым доменом путличным сертификатом от удостоверяющего центра (Certificate Authority или CA) и разместить там распознаватель DNS с шифрованием.

Для смягчения атак с поддельными или изменёнными откликами DHCP и сообщениями RA внутри локальной сети можно использовать указанные ниже механизмы.

Экран DHCPv6 [RFC7610]

RA-Guard [RFC7113]

Улучшение проверки адреса источника (Source Address Validation Improvement или SAVI) для DHCP [RFC7513]

Эти механизмы обеспечивают получение конечной точкой коррктных данных конфигурации распознавателей DNS, выбранных сервером DHCP (или отправителем RA), но не могут предоставить каких-либо сведений о сервере DHCP или объекте, на котором этот сервер DHCP (или отправитель RA) размещен.

Шифрованные сессии DNS с мошенническими распознавателями, подделывающими IP-адрес распознавателя DNS, будут сталкиваться с отказами, поскольку клиент DNS получит отказ при проверке подлинности мошеннического распознавателя на основе аутентификации PKIX [RFC6125], в частности для ADN в опции Encrypted DNS. Клиенты DNS, игнорирующие отказ при аутентификации и воспринимающие поддельные сертификаты, будут подвержены атакам (например, перенаправление на поддельные распознаватели или перехват конфиденциальных данных).

7.2. Атаки с удалением

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

Отметим, что атаки с удалением не являются спецификой DHCP/RA.

7.3. Пассивные атаки

Пассивный атакующий (параграф 3.2 в [RFC3552]) может определить использование хостом DHCP/RA для обнаружения распознавателя DNS с шифрованием и сделать вывод о способности хоста использовать DoH/DoT/DoQ для шифрования сообщений DNS. Однако он не сможет поддедать или изменить сообщения DHCP/RA.

7.4. Атаки с аутентификацией в беспроводных сетях

Беспроводные ЛВС (Wireless LAN или WLAN), часто используемые в локальных сетях (например, в домашних), уязвимы для различных атак (например, [Evil-Twin], [Krack], [Dragonblood]). По этой причине в беспроводных ЛВС доверяют лишь криптографически аутентифицированным коммуникациям. Это означает, что любые сведения (например, о серверах NTP, распознавателях DNS, списках доменоа для поиска), предоставляемые такими сетями через DHCP, DHCPv6, RA, являются недоверенными, поскольку подлинность сообщений DHCP и RA не проверяется.

Если заранее распределенные ключи (pre-shared key или PSK) совпадают у всех клиентов, подключённых к одной WLAN (например, Wi-Fi Protected Access Pre-Shared Key (WPA-PSK)), ключ будет доступен и злоумышленникам, что позволяет организовать активную атаку на пути. Такие атаки возможны внутри локальной сети, поскольку в этой форме аутентификации WLAN не проверяется подлинность партнёров. Это ведёт к необходимости предоставлять клиентам уникальные свидетельства (credentials). Конечным точка могут предоставляться уникальные свидетелства (обычно, имя пользователя и пароль), заданные администратором локальной сети, для взаимной аутентификации на локальной WLAN AP, например, 802.1x Wireless User Authentication в OpenWrt [dot1x], EAP⁶-pwd [RFC8146]. Не все конечные устройства (например, IoT⁷) поддерживают просителей 802.1x (supplicant) и им нужен другой механизм для подключения к локальной сети. Для снятия этого ограничения можно создать уникальный PSK для каждого такого устройства и использовать WPA-PSK (например, [IPSK]).

8. Вопросы приватности

Вопросы приватности, актуальные и для механизмов предоставления DNR, рассмотрены в разделе 23 [RFC8415] и в in [RFC7824]. Профили анонимности для клиентов DHCP рассмотрены в [RFC7844]. Определённые в этом документе механизмы можно применять для определения поддержки клиентом DHCP или хостом IPv6 опций Encrypted DNS, но эти механизмы не раскрывают возможности локальных клиентов DNS воспринимать эти опции и использовать шифрование. В остальном эти механизмы не раскрывают дополнительных приватных сведений по сравнению с опциями обнаружения Do53.

Как отмечено в [RFC9076], использование DNS с шифрованием не снижает уровень доступности данных в распознавателе DNS. Конкретные соображения по защите приватности для DNS с шифрованием приведены в разделе 8 [RFC8484] и разделе 7 [RFC9250].

9. Взаимодействие с IANA

9.1. Опция DHCPv6

Агентство IANA включило указанный в таблице 1 код опции DHCPv6 в реестр Option Codes [DHCPV6].

Таблица . Опция DHCPv6.

9.2. Опция DHCPv4

Агентсво IANA включило указанный в таблице 2 код опции DHCP в реестр BOOTP Vendor Extensions and DHCP Options [BOOTP].

Таблица . Опция DHCPv4.

9.3. Опция Neighbor Discovery

Агентство IANA включило указанный в таблице 3 тип опции IPv6 Neighbor Discovery Option в субреестр IPv6 Neighbor Discovery Option Formats реестра Internet Control Message Protocol version 6 (ICMPv6) Parameters [ND].

Таблица . Опция Neighbor Discovery.

10. Литература

10.1. Нормативные документы

[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>.

[RFC2132] Alexander, S. and R. Droms, “DHCP Options and BOOTP Vendor Extensions”, RFC 2132, DOI 10.17487/RFC2132, March 1997, <https://www.rfc-editor.org/info/rfc2132>.

[RFC3396] Lemon, T. and S. Cheshire, “Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)”, RFC 3396, DOI 10.17487/RFC3396, November 2002, <https://www.rfc-editor.org/info/rfc3396>.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6)”, RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.

[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, “IPv6 Router Advertisement Options for DNS Configuration”, RFC 8106, DOI 10.17487/RFC8106, March 2017, <https://www.rfc-editor.org/info/rfc8106>.

[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>.

[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”, RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.

[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, “Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)”, RFC 9460, DOI 10.17487/RFC9460, November 2023, <https://www.rfc-editor.org/info/rfc9460>.

[RFC9461] Schwartz, B., “Service Binding Mapping for DNS Servers”, RFC 9461, DOI 10.17487/RFC9461, November 2023, <https://www.rfc-editor.org/info/rfc9461>.

10.2. Дополнительная литература

[BOOTP] IANA, “BOOTP Vendor Extensions and DHCP Options”, <https://www.iana.org/assignments/bootp-dhcp-parameters/>.

[DHCPV6] IANA, “Option Codes”, <https://www.iana.org/assignments/dhcpv6-parameters/>.

[DNS-TLS-DHCPv6-Opt] Pusateri, T. and W. Toorop, “DHCPv6 Options for private DNS Discovery”, Work in Progress, Internet-Draft, draft-pusateri-dhc-dns-driu-00, 2 July 2018, <https://datatracker.ietf.org/doc/html/draft-pusateri-dhc-dns-driu-00>.

[dot1x] OpenWrt, “Introduction to 802.1X”, December 2021, <https://openwrt.org/docs/guide-user/network/wifi/wireless.security.8021x>.

[Dragonblood] Vanhoef, M. and E. Ronen, “Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and EAP-pwd”, 2020 IEEE Symposium on Security and Privacy (SP), San Francisco, pp. 517-533, DOI 10.1109/SP40000.2020.00031, May 2020, <https://ieeexplore.ieee.org/document/9152782>.

[Evil-Twin] Wikipedia, “Evil twin (wireless networks)”, November 2022, <https://en.wikipedia.org/wiki/Evil_twin_(wireless_networks)>.

[IPSK] Cisco, “8.5 Identity PSK Feature Deployment Guide”, December 2021, <https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-5/b_Identity_PSK_Feature_Deployment_Guide.html>.

[Krack] Vanhoef, M. and F. Piessens, “Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2”, CCS ’17: Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, pp. 1313-1328, DOI 10.1145/3133956.3134027, October 2017, <https://dl.acm.org/doi/10.1145/3133956.3134027>.

[Local-DNS-Authority] Reddy, T., Wing, D., Smith, K., and B. Schwartz, “Establishing Local DNS Authority in Validated Split-Horizon Environments”, Work in Progress, Internet-Draft, draft-ietf-add-split-horizon-authority-04, 8 March 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-add-split-horizon-authority-04>.

[ND] IANA, “IPv6 Neighbor Discovery Option Formats”, <https://www.iana.org/assignments/icmpv6-parameters/>.

[RFC3552] Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations”, BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.

[RFC3646] Droms, R., Ed., “DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”, RFC 3646, DOI 10.17487/RFC3646, December 2003, <https://www.rfc-editor.org/info/rfc3646>.

[RFC4786] Abley, J. and K. Lindqvist, “Operation of Anycast Services”, BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <https://www.rfc-editor.org/info/rfc4786>.

[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>.

[RFC6125] Saint-Andre, P. and J. Hodges, “Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)”, RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.

[RFC6731] Savolainen, T., Kato, J., and T. Lemon, “Improved Recursive DNS Server Selection for Multi-Interfaced Nodes”, RFC 6731, DOI 10.17487/RFC6731, December 2012, <https://www.rfc-editor.org/info/rfc6731>.

[RFC7113] Gont, F., “Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)”, RFC 7113, DOI 10.17487/RFC7113, February 2014, <https://www.rfc-editor.org/info/rfc7113>.

[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, “Guidelines for Creating New DHCPv6 Options”, BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <https://www.rfc-editor.org/info/rfc7227>.

[RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, “Source Address Validation Improvement (SAVI) Solution for DHCP”, RFC 7513, DOI 10.17487/RFC7513, May 2015, <https://www.rfc-editor.org/info/rfc7513>.

[RFC7610] Gont, F., Liu, W., and G. Van de Velde, “DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers”, BCP 199, RFC 7610, DOI 10.17487/RFC7610, August 2015, <https://www.rfc-editor.org/info/rfc7610>.

[RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, “Privacy Considerations for DHCPv6”, RFC 7824, DOI 10.17487/RFC7824, May 2016, <https://www.rfc-editor.org/info/rfc7824>.

[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, “Anonymity Profiles for DHCP Clients”, RFC 7844, DOI 10.17487/RFC7844, May 2016, <https://www.rfc-editor.org/info/rfc7844>.

[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>.

[RFC7969] Lemon, T. and T. Mrugalski, “Customizing DHCP Configuration on the Basis of Network Topology”, RFC 7969, DOI 10.17487/RFC7969, October 2016, <https://www.rfc-editor.org/info/rfc7969>.

[RFC8146] Harkins, D., “Adding Support for Salted Password Databases to EAP-pwd”, RFC 8146, DOI 10.17487/RFC8146, April 2017, <https://www.rfc-editor.org/info/rfc8146>.

[RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, “Usage Profiles for DNS over TLS and DNS over DTLS”, RFC 8310, DOI 10.17487/RFC8310, March 2018, <https://www.rfc-editor.org/info/rfc8310>.

[RFC8484] Hoffman, P. and P. McManus, “DNS Queries over HTTPS (DoH)”, RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.

[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, “DNS Terminology”, BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>.

[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, “Object Security for Constrained RESTful Environments (OSCORE)”, RFC 8613, DOI 10.17487/RFC8613, July 2019, <https://www.rfc-editor.org/info/rfc8613>.

[RFC8801] Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W. Shao, “Discovering Provisioning Domain Names and Data”, RFC 8801, DOI 10.17487/RFC8801, July 2020, <https://www.rfc-editor.org/info/rfc8801>.

[RFC9076] Wicinski, T., Ed., “DNS Privacy Considerations”, RFC 9076, DOI 10.17487/RFC9076, July 2021, <https://www.rfc-editor.org/info/rfc9076>.

[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, “DNS over Dedicated QUIC Connections”, RFC 9250, DOI 10.17487/RFC9250, May 2022, <https://www.rfc-editor.org/info/rfc9250>.

[RFC9462] Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T. Jensen, “Discovery of Designated Resolvers”, RFC 9462, DOI 10.17487/RFC9462, November 2023, <https://www.rfc-editor.org/info/rfc9462>.

[TS.24008] 3GPP, “Technical Specification Group Core Network and Terminals; Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (Release 18)”, version 18.4.0, September 2023, <https://www.3gpp.org/DynaReport/24008.htm>.

Благодарности

Большое спасибо Christian Jacquenet и Michael Richardson за их рецензии.

Спасибо Stephen Farrell, Martin Thomson, Vittorio Bertola, Stéphane Bortzmeyer, Ben Schwartz, Iain Sharp, Chris Box за их комментарии.

Спасибо Mark Nottingham за отклик по перенаправлению HTTP, обсуждаемому в черновых вариантах спецификации.

Использование протокола DHCP в качестве кандидата для извлечения ADN было упомянуто в параграфе 7.3.1 [RFC8310] и Internet-Draft, авторами которого являются Tom Pusateri и Willem Toorop [DNS-TLS-DHCPv6-Opt].

Спасибо Bernie Volz за рецензию по DHCP.

Christian Amsüss указал случай, когда параметр сервиса ALPN не может использоваться.

Спасибо Andrew Campling за рецензию Shepherd и Éric Vyncke за рецензию AD.

Спасибо Rich Salz за рецензии secdir, Joe Clarke за рецензию opsdir, Robert Sparks за рецензию artart, David Blacka за рецензию dnsdir.

Спасибо Lars Eggert, Roman Danyliw, Erik Kline, Martin Duke, Robert Wilton, Paul Wouters, Zaheduzzaman Sarker за рецензию IESG.

Участники работы

Адреса авторов

Перевод на русский язык

nmalykh@protokols.ru