RFC 8109 | Инициализация DNS-резольвера с заполняющими запросами

RFC 8109 | Инициализация DNS-резольвера с заполняющими запросами

Аннотация

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

Скачать оригинальный документ на английском языке RFC 8109 PDF

 

Оглавление

1. Введение
2. Описание заполнения
3. Заполняющие запросы
3.1. Повторение запросов на заполнение
3.2. Выбор цели
3.3. DNSSEC с запросами заполнения
4. Ответы на заполнение
4.1. Ожидаемые свойства первичного отклика
4.2. Полнота ответа
5. Вопросы безопасности
6. Соображения IANA
7. Нормативные документы
Благодарности
Адреса авторов

 

Статус этой заметки

Эта памятка документирует лучшую текущую практику Интернета.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественное обозрение и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о ППГ доступна в Разделе 2 RFC 7841.

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

 

Уведомление об авторских правах

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

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

 

1. Введение

Рекурсивным распознавателям DNS необходима отправная точка для разрешения запросов. [RFC1034] описывает общий сценарий для рекурсивных распознавателей: они начинаются с пустого кэша и некоторой конфигурации для поиска имен и адресов корневых серверов DNS. [RFC1034] описывает эту конфигурацию как список серверов, которые будут давать достоверные ответы на запросы о корне. Это стало распространенным вариантом реализации для рекурсивных распознавателей и является темой этого документа.

Этот документ описывает шаги, необходимые для этого общего выбора реализации. Обратите внимание, что это не единственный способ запустить рекурсивный сервер имен с пустым кешем, но это единственный способ, описанный в [RFC1034]. Некоторые разработчики выбрали другие направления, некоторые из которых работают хорошо, а другие не работают (иногда катастрофически) в других условиях. Например, реализация, которая получает адреса корневых серверов имен только из конфигурации, а не из DNS, как описано в этом документе, будет иметь устаревшие данные, которые могут вызвать более медленное разрешение.

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119].

Этот документ имеет дело только с рекурсивными серверами имен (рекурсивные распознаватели, распознаватели) для класса IN.

 

2. Описание заполнения

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

Заправка описана в разделах 5.3.2 и 5.3.3 [RFC1034]. Сценарий, использованный в этом описании, сценарий рекурсивного сервера, который также является авторитетным, более не распространен.

Сконфигурированный список IP-адресов для корневых серверов обычно поступает от поставщика или распространителя рекурсивного серверного программного обеспечения. Этот список, как правило, правильный и полный при отправке, но со временем может устареть.

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

 

3. Заполняющие запросы

Заполняющий запрос — это DNS-запрос, используемый для получения информации корневого сервера в распознавателе. У него есть QNAME «.» и QTYPE NS, и отправляется на один из адресов в конфигурации для рекурсивного преобразователя. Заполняющий запрос может быть отправлен через UDP или TCP. Если запрос отправляется по UDP, порт источника СЛЕДУЕТ выбирать случайным образом (см. [RFC5452]). Бит Recursion Desired (RD) МОЖЕТ быть установлен на 0 или 1, хотя значение его, установленного на 1, не определено для запросов на инициализацию.

Рекурсивный распознаватель ДОЛЖЕН использовать EDNS (0) [RFC6891] для запросов на инициализацию и ДОЛЖЕН объявлять и обрабатывать размер повторной сборки не менее 1024 октетов [RFC3226]. Это позволяет получать ответы, которые охватывают размер полного ответа на заполнение (см. Раздел 4.2) для текущего набора корневых серверов. См. Раздел 3.3 для обсуждения установки бита DNSSEC OK (DO) (определено в [RFC4033]).

3.1. Повторение запросов на заполнение

Рекурсивный распознаватель СЛЕДУЕТ отправлять запрос на инициализацию только тогда, когда это необходимо, например, когда распознаватель запускается с пустым кешем и когда истек NS RRset для корневой зоны. Поскольку записи NS для корня не являются специальными, рекурсивный распознаватель истекает эти записи NS в соответствии с их значениями TTL. (Обратите внимание, что рекурсивный распознаватель МОЖЕТ предварительно извлечь NS RRset до истечения срока его действия.)

Если запрос на заполнение не получает ответ, рекурсивный распознаватель должен повторить запрос с другим целевым адресом из конфигурации.

3.2. Выбор цели

Чтобы распределить нагрузку по всем доменным именам корневого сервера, рекурсивный распознаватель ДОЛЖЕН выбрать цель для запроса инициализации случайным образом из списка адресов. Рекурсивный распознаватель может выбирать адреса IPv4 или IPv6, основываясь на своем знании того, имеет ли система, на которой он работает, адекватные подключения по любому типу адреса.

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

3.3. DNSSEC с запросами заполнения

Средство распознавания МОЖЕТ установить бит DNSSEC OK (DO). На момент публикации нет смысла выполнять проверку DNSSEC в запросе на инициализацию. В настоящее время все имена корневых серверов имен заканчиваются на «root-servers.net», а наборы AAAA и A RR для имен корневых серверов находятся в зоне «root-servers.net». Все корневые серверы также являются полномочными для этой зоны, что позволяет в ответах на инициализацию включать соответствующий корневой сервер имен A и AAAA RRsets. Но поскольку зона «root-servers.net» в настоящее время не подписана, эти наборы RR не могут быть проверены.

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

Если зона «root-servers.net» позднее подписана или корневые серверы названы в другой зоне, и эта зона подписана, может иметь смысл проверка DNSSEC для запросов заполнения.

 

4. Ответы на заполнение

Заполняющий запрос — это обычный DNS-запрос. Таким образом, корневой сервер имен не может отличить первичный запрос от любого другого запроса для корневого NS RRset. Таким образом, ответ корневого сервера также будет нормальным ответом DNS.

4.1. Ожидаемые свойства первичного отклика

Ожидается, что ответ на заполнение будет иметь RCODE из NOERROR и будет иметь установленный бит достоверного ответа (AA). Кроме того, ожидается, что в разделе «Ответ» есть набор RR-наборов NS (поскольку набор RR-наборов NS происходит из корневой зоны) и пустой раздел «Authority — Полномочия» (так как набор RR-наборов NS уже отображается в разделе «Ответ»). Также будет «Additional -Дополнительный» раздел с A и / или AAAA RRsets для корневых серверов имен, на которые указывает NS RRset.

Программное обеспечение Resolver ДОЛЖНО обрабатывать ответ на запрос инициализации как обычный ответ DNS, так же как оно будет использовать любые другие данные, передаваемые в его кэш. Программному обеспечению разрешения НЕ СЛЕДУЕТ ожидать ровно 13 NS RR, поскольку исторически некоторые корневые серверы возвращали меньше.

4.2. Полнота ответа

В настоящее время существует 13 корневых серверов. Все они имеют один IPv4-адрес и один IPv6-адрес. Даже не считая NS RRset, объединенный размер всех наборов A и AAAA RR превышает исходный предел полезной нагрузки в 512 октетов из [RFC1035].

В случае ответа, в котором в разделе «Дополнительно» пропущена определенная информация об адресе корневого сервера, повторная выдача запроса на заполнение не помогает с теми корневыми серверами имен, которые отвечают с фиксированным порядком адресов в разделе «Дополнительные». Вместо этого рекурсивный распознаватель должен выдавать прямые запросы для A и AAAA RRsets для оставшихся имен. В настоящее время эти наборы RR будут официально доступны на корневых серверах имен.

 

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

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

Злоумышленник, находящийся на пути, который видит первичный запрос, исходящий от распознавателя, может ввести ложные ответы, прежде чем корневой сервер сможет дать правильные ответы. Если ответы злоумышленника приняты, это может настроить возможность давать дальнейшие ложные ответы для будущих запросов распознавателю. Ложные ответы для корневых серверов более опасны, чем, скажем, ложные ответы для доменов верхнего уровня (TLD), потому что корень является высшим узлом DNS. См. Раздел 3.3 для дальнейшего обсуждения.

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

6. Соображения IANA

Этот документ не требует никаких действий IANA.

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

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, DOI 10.17487/RFC1034,
November 1987, <http://www.rfc-editor.org/info/rfc1034>.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://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,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC3226] Gudmundsson, O., «DNSSEC and IPv6 A6 aware server/resolver message size requirements», RFC 3226, DOI 10.17487/RFC3226, December 2001,
<http://www.rfc-editor.org/info/rfc3226>.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «DNS Security Introduction and Requirements», RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>.

[RFC5452] Hubert, A. and R. van Mook, «Measures for Making DNS More Resilient against Forged Answers», RFC 5452, DOI 10.17487/RFC5452, January 2009,
<http://www.rfc-editor.org/info/rfc5452>.

[RFC6891] Damas, J., Graff, M., and P. Vixie, «Extension Mechanisms for DNS (EDNS(0))», STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013,
<http://www.rfc-editor.org/info/rfc6891>.

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

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

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

Peter Koch
DENIC eG
Kaiserstrasse 75-77
Frankfurt 60329
Germany
Phone: +49 69 27235 0
Email: pk@DENIC.DE

Matt Larson
ICANN
Email: matt.larson@icann.org
Paul Hoffman
ICANN
Email: paul.hoffman@icann.org