RFC 8482 | Предоставление ответов минимального размера на DNS-запросы с QTYPE=ANY

Аннотация

Система доменных имен (DNS) определяет тип запроса (QTYPE) «ANY». Оператор авторитетного DNS-сервера может решить не отвечать на такие запросы по соображениям локальной политики, мотивированным соображениями безопасности, производительности или другими причинами.

Спецификация DNS не содержит конкретных рекомендаций по поведению DNS-серверов или клиентов в этой ситуации. Этот документ призван обеспечить такое руководство.

Этот документ обновляет RFC 1034 [#] и RFC 1035 [#].

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

1. Введение
1.1. Терминология
2. Мотивация использования запросов ANY
3. Общий подход
4. Поведение DNS-ответчиков
4.1. Ответ с подмножеством доступных RRsets
4.2. Ответ с синтезированным HINFO RRset
4.3. Ответь с наилучшим предположением о намерении
4.4. Транспортные соображения
5. Поведение DNS-инициаторов
6. HINFO Соображения
7. Обновления к RFC 1034 и 1035
8. Опыт внедрения
9. Вопросы безопасности
10. Соображения IANA
11. Ссылки
11.1. Нормативные ссылки
11.2. Информационные ссылки
Благодарности
Адреса авторов

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

Это документ по отслеживанию стандартов Интернета.

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

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

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

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

1. Введение

Спецификация DNS [RFC1034] [RFC1035] не содержит конкретных рекомендаций по поведению DNS-серверов или клиентов в этой ситуации. Этот документ призван обеспечить такое руководство.

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

В этом документе используется терминология, характерная для Системы доменных имен (DNS), описания которой можно найти в [RFC8499 #].

[RFC1035] определил тип 255 как «*». Тем не менее, реализации DNS обычно используют ключевое слово «ANY» для ссылки на код этого типа; этот документ следует этому общему использованию.

В этом документе «ANY запрос» относится к мета-запросу DNS с QTYPE = ANY. «ANY ответ» — это ответ на такой запрос.

В этом документе «обычный ANY ответ» означает ANY ответ, который создается в соответствии с алгоритмом, описанным в разделе 4.3.2 [RFC1034], и конкретно без реализации какого-либо из механизмов, описанных в этом документе.

При обмене сообщениями DNS между двумя узлами этот документ ссылается на узел, отправляющий запрос DNS, в качестве «инициатора», а узел, отправляющий ответ DNS, в качестве «ответчика».

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

2. Мотивация использования запросов ANY

Запросы ANY законно используются для отладки и проверки состояния DNS-сервера для определенного имени.

Запросы ANY иногда используются как попытка уменьшить количество запросов, необходимых для получения информации, например, для получения наборов записей ресурсов MX, A и AAAA (RRsets) для почтового домена в одном запросе. Однако для этого варианта использования нет документированного руководства, и было отмечено, что некоторые реализации не функционируют так, как ожидали их разработчики. Если разработчики предполагают, что ANY запрос в конечном итоге будет получен авторитетным сервером и извлечет все существующие наборы RR, они должны включить резервный механизм, который следует использовать, когда этого не происходит.

Запросы ANY часто используются для использования потенциала усиления DNS-серверов и распознавателей с использованием поддельных адресов источников и транспорта UDP (см. [RFC5358 #]). Возможность возврата небольших ответов на такие запросы делает DNS-серверы менее привлекательными усилителями.

Запросы ANY иногда используются для того, чтобы помочь только авторизованным DNS-серверам для данных зоны, поскольку ожидается, что они будут возвращать все наборы RR для определенного имени запроса. Если операторы DNS предпочитают уменьшать вероятность утечки информации, они могут не отправлять большие ANY ответы.

Некоторые реализации только для авторитетных DNS-серверов требуют дополнительной обработки для отправки обычного ANY ответа; избегать таких затрат на обработку может быть желательно.

3. Общий подход

Это предложение предоставляет механизм для авторитетного DNS-сервера, чтобы сигнализировать, что обычные ANY запросы не поддерживаются для конкретного QNAME. Он делает это способом, который совместим с немодифицированными клиентами (например, преобразователями DNS) и запускает желаемое поведение.

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

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

4. Поведение DNS-ответчиков

Ниже представлены три различных режима поведения респондентов DNS при обработке запросов с существующими QNAME, QCLASS = IN и QTYPE = ANY. Операторы и исполнители могут выбирать любой механизм, который лучше всего подходит для их среды.

Ответчик DNS может выбрать один или большее подмножество доступных наборов RR в QNAME.
DNS-респондент может вернуть синтезированную запись ресурса HINFO. См. Раздел 6 для обсуждения использования HINFO.
Решатель может попытаться выдать наиболее вероятные записи, которые хочет запрашивающий. Это не всегда возможно, и результатом может быть большой отклик.

За исключением случаев, описанных ниже в этом разделе, DNS-ответчик ДОЛЖЕН следовать стандартным алгоритмам при построении ответа.

4.1. Ответ с подмножеством доступных RRsets

Ответчик DNS, который получает ANY запрос, МОЖЕТ отклонить предоставление обычного ANY ответа или МОЖЕТ вместо этого отправить ответ с одним набором RR (или большим подмножеством доступных наборов RR) в разделе ответов.

Наборы RR, возвращаемые в разделе ответа ответа, МОГУТ состоять из одного набора RRset, которому принадлежит имя, указанное в QNAME. Там, где существует несколько наборов RR, респондент ДОЛЖЕН выбрать небольшое подмножество из доступных для уменьшения потенциала амплификации ответа.

Если зона подписана, соответствующие записи RRSIG ДОЛЖНЫ быть включены в ответ.

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

4.2. Ответ с синтезированным HINFO RRset

Если в имени владельца, совпадающем с QNAME, отсутствует CNAME, запись ресурса, возвращаемая в ответе, МОЖЕТ быть синтезирована. В этом случае ДОЛЖНА быть возвращена одна запись ресурса HINFO. Поле CPU из HINFO RDATA ДОЛЖНО быть установлено на «RFC8482». В поле OS для HINFO RDATA СЛЕДУЕТ установить нулевую строку, чтобы минимизировать размер ответа.

Оператор респондента ДОЛЖЕН выбрать TTL, закодированный для синтезированной записи ресурса HINFO, чтобы он был достаточно большим, чтобы подавлять частые последующие ANY запросы от того же инициатора с тем же QNAME, понимая, что слишком длинный TTL может вносить изменения в политику относящиеся к ANY запросам, которые трудно изменить в будущем. Конкретное используемое значение ДОЛЖНО быть настраиваемым оператором сервера имен в соответствии с локальной политикой, основываясь на знакомых соображениях, связанных с выбором значения TTL для любой записи ресурса в любой зоне.

Если запрос DNS включает DO = 1, а QNAME соответствует зоне, известной подписчику, который должен быть подписан, ДОЛЖЕН быть возвращен действительный RRSIG для наборов RR в разделе ответа (или полномочия, если ответ пуст). В случае DO = 0 RRSIG ДОЛЖЕН быть опущен.

Система, которая получает ответ HINFO, НЕ ДОЛЖНА выводить, что ответ был сгенерирован в соответствии с этой спецификацией, и применять какую-либо специальную обработку ответа, потому что, как правило, невозможно с уверенностью сказать, был ли синтезирован полученный RRset HINFO. В частности, системы НЕ ДОЛЖНЫ полагаться на HINFO RDATA, описанные в этом разделе, чтобы различать синтезированные и несинтезированные RRsets HINFO.

4.3. Ответь с наилучшим предположением о намерении

В некоторых случаях можно догадаться, чего хочет инициатор в ответе (но не всегда). Некоторые реализации реализовали дух этого документа, возвращая все RRsets RRTYPE CNAME, MX, A и AAAA, которые присутствуют в имени владельца, подавляя другие. Эта эвристика, кажется, хорошо работает на практике; он удовлетворяет потребности некоторых приложений, в то же время подавляя другие наборы RR, такие как TXT и DNSKEY, которые часто могут способствовать получению больших откликов. В то время как некоторые приложения могут быть удовлетворены этим поведением, результирующие ответы в общем случае больше, чем в подходах, описанных в разделах 4.1 и 4.2.

Как и прежде, если зона подписана и бит DO установлен в соответствующем запросе, RRSIG RRset ДОЛЖЕН быть включен в ответ.

4.4. Транспортные соображения

DNS-ответчик МОЖЕТ вести себя по-разному при обработке ANY запросов, полученных по разным транспортам, например, путем предоставления обычного ANY ответа по TCP при использовании одного из других механизмов, указанных в этом документе, в случае, когда запрос был получен с использованием UDP.

Реализаторы МОГУТ предоставлять параметры конфигурации, чтобы позволить операторам определять различное поведение для разных транспортов.

5. Поведение DNS-инициаторов

Инициатор DNS, который отправляет запрос с QTYPE=ANY и получает ответ, содержащий запись ресурса HINFO или один RRset, как описано в Разделе 4, МОЖЕТ кэшировать ответ обычным способом. Такие кэшированные записи ресурсов ДОЛЖНЫ храниться в кэше в соответствии с обычной семантикой кэширования, как и в случае любого другого ответа, полученного от респондента DNS.

Инициатор DNS МОЖЕТ подавлять запросы с QTYPE = ANY в случае, если локальный кеш содержит соответствующую запись ресурса HINFO с полем ЦП RINATA HINFO, как описано в Разделе 4. Инициатор DNS МОЖЕТ вместо этого отвечать на такие запросы содержимым локального кэша обычным способом.

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

Возможно, что синтезированный RRset HINFO в ANY ответе, однажды кэшированный инициатором, мог бы подавить последующие запросы от того же инициатора с QTYPE = HINFO. Таким образом, использование HINFO в этом предложении будет эффективно маскировать RRset HINFO, присутствующий в зоне.

Операторам авторитетных серверов, которые обслуживают зоны, основанные на обычном использовании RRTYPE HINFO, СЛЕДУЕТ разумно выбирать метод «одного RRset», описанный в этом документе, или выбирать другой тип.

Считается, что HINFO RRTYPE редко используется в DNS на момент написания, основываясь на наблюдениях, сделанных в пассивном DNS и на рекурсивных и авторитетных DNS-серверах.

7. Обновления к RFC 1034 и 1035

Этот документ расширяет спецификацию для обработки ANY запросов, описанную в Разделе 4.3.2 [RFC1034].

Важно отметить, что возврат подмножества доступных наборов RR при обработке ANY запроса является законным и соответствует [RFC1035]; можно утверждать, что ANY не всегда означает ВСЕ, как используется в Разделе 3.2.3 [RFC1035]. Основным отличием здесь является то, что бит TC НЕ ДОЛЖЕН быть установлен в ответе, что указывает на то, что это не полный ответ.

Этот документ описывает необязательное поведение как для инициаторов DNS, так и для респондентов; Выполнение указаний, представленных в этом документе, НЕОБЯЗАТЕЛЬНО.

Запросы RRSIG (т. е. запросы с QTYPE = RRSIG) аналогичны ANY запросам в том смысле, что они могут генерировать большие ответы, а также дополнительную работу для респондентов, которые их обрабатывают, например, в случае, когда подписи генерируются на муха. RRSIG RRsets обычно не получают с использованием таких явных запросов, а скорее включают в ответы для других RRsets, которые охватывают RRSIG. Этот документ не определяет соответствующее поведение для запросов RRSIG; тем не менее, в будущем такой совет может выиграть от согласованности и опыта подходов к ANY запросам, описанным здесь.

8. Опыт внедрения

В октябре 2015 года в реализации авторитетного сервера имен Cloudflare был реализован ответ HINFO. Сообщалось о нескольких незначительных проблемах, и с тех пор они были решены.

Реализация ответа подмножества на ANY запросы была реализована в NSD 4.1 в 2016 году.

Тони Финч осуществил реализацию одного ответа RRset на ANY запрос для BIND9, и эта функциональность впоследствии была доступна в производственных выпусках, начиная с BIND 9.11.

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

Запросы с QTYPE = ANY часто наблюдаются как часть атак отражения, поскольку для получения большого ответа можно использовать относительно небольшой запрос. Это является желательной характеристикой, если целью является максимизация потенциала усиления DNS-сервера в рамках объемной атаки. Способность оператора DNS подавлять такие ответы на конкретном сервере делает этот сервер менее полезным усилителем.

Необязательное поведение, описанное в этом документе для уменьшения размера ответов на запросы с QTYPE = ANY, совместимо с использованием DNSSEC как инициатором, так и респондентом.

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

IANA обновила следующую запись в реестре «ТИПЫ записей ресурсов (RR)» [RR_TYPES]:

TYPE — *

Значение — 255

Смысл — Запрос на некоторые или все записи, доступные серверу

Ссылки — [RFC1035],[RFC6895],[RFC8482]

11. Ссылки

11.1. Нормативные ссылки

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

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

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

11.2. Информационные ссылки

[RFC5358] Damas, J. and F. Neves, «Preventing Use of Recursive Nameservers in Reflector Attacks», BCP 140, RFC 5358, DOI 10.17487/RFC5358, October 2008, <https://www.rfc-editor.org/info/rfc5358>.

[RFC6895] Eastlake 3rd, D., «Domain Name System (DNS) IANA Considerations», BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, <https://www.rfc-editor.org/info/rfc6895>.

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

[RR_TYPES] IANA, «Domain Name System (DNS) Parameters», <https://www.iana.org/assignments/dns-parameters>.

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

Дэвид Лоуренс представил ценные замечания и конкретные предложения. Джереми Лэйдман помог сделать документ лучше. Тони Финч осознал, что этот документ был ценным, и реализовал его, находясь под атакой. Ричард Гибсон определил области, в которых было полезно больше подробностей и точности. Большое количество других людей также предоставили комментарии и предложения; Мы благодарим их всех за отзывы.

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

Joe Abley
Afilias
300-184 York Street
London, ON N6A 1B5
Canada
Phone: +1 519 670 9327
Email: jabley@afilias.info

Olafur Gudmundsson
Cloudflare Inc.
Email: olafur+ietf@cloudflare.com

Marek Majkowski
Cloudflare Inc.
Email: marek@cloudflare.com

Evan Hunt
ISC
950 Charter St
Redwood City, CA 94063
United States of America
Email: each@isc.org