RFC 6950 | Архитектурные аспекты функций приложений в DNS

Аннотация

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

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

1. Мотивация
2. Обзор использования приложений DNS
2.1. Поиск услуг в домене
2.2. NAPTR и DDDS
2.3. Произвольные данные в DNS
3. Проблемы для DNS
3.1. Сложные Запросы
3.1.1. Ответы с учетом автора
3.2. Использование DNS в качестве общей базы данных
3.2.1. Большие данные в DNS
3.3. Административные структуры смещены с DNS
3.3.1. Метаданные о древовидной структуре
3.4. Перенаправление домена
4. Частный DNS и Split Horizon
5. Принципы и руководство
6. Вопросы безопасности
7. Члены IAB на момент утверждения
8. Благодарности
9. Информационные ссылки
Адрес автора

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

Этот документ не является спецификацией Internet Standards Track; опубликовано в ознакомительных целях.

Этот документ является продуктом Совета по архитектуре Интернета (IAB) и представляет информацию, которую IAB посчитал ценным для постоянной записи. Он представляет собой консенсус Совета по архитектуре Интернета (IAB). Документы, одобренные для публикации IAB, не являются кандидатами на какой-либо уровень Интернет-стандарта; см. раздел 2 RFC 5741.

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

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

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

1. Мотивация

Система доменных имен (DNS) уже давно предоставляет общие средства преобразования доменных имен в адреса интернет-протокола, что упрощает использование Интернета, обеспечивая ценный уровень косвенности между именами и элементами протокола более низкого уровня. [RFC0974] задокументировал дальнейшее использование DNS: для поиска службы приложения, работающей в домене, через ресурсную запись Mail Exchange (MX); эти записи помогают электронной почте, адресованной домену, находить почтовую службу для домена, санкционированную администратором зоны.

Первичная запись MX служила прототипом для других записей ресурсов DNS, которые поддерживали приложения, связанные с доменным именем. Запись ресурса SRV [RFC2052] предоставила более общий механизм для определения местоположения услуг в домене, дополненный системой взвешивания и выбором среди транспортных средств. Запись ресурса указателя полномочий по именованию (NAPTR) (первоначально описанная в [RFC2168]), особенно в связи с развитием более общей структуры системы динамического обнаружения делегирования (DDDS) [RFC3401], добавила общий механизм хранения данных приложения в DNS. В первую очередь это включало алгоритм на стороне клиента для преобразования строки в доменное имя, которое затем могло бы быть разрешено DNS для поиска записей NAPTR. Это позволило разрешать идентификаторы, которые не имеют традиционных компонентов хоста, через DNS; Наиболее известными примерами этого являются телефонные номера, которые разрешены приложением DDDS ENUM. Недавняя работа, такая как DomainKeys Identified Mail (DKIM) [RFC6376], позволила рекламировать функции безопасности приложений через DNS через запись ресурса TXT.

Таким образом, область применения DNS в приложениях со временем увеличилась. Приложениям во многих средах требуются такие функции, как конфиденциальность, и поскольку контексты, в которых приложения полагаются на DNS, расширились, некоторые протоколы приложений стали расширять DNS, чтобы включать в себя такие возможности. Тем не менее, некоторые предлагаемые варианты использования и расширения DNS стали несовместимыми как с архитектурой DNS, так и с протоколом DNS. Если мы возьмем пример конфиденциальности, мы увидим, что в глобальном общедоступном DNS преобразование доменных имен в IP-адреса представляет собой обмен публичной информацией без ожидания конфиденциальности. Таким образом, базовый протокол запросов / ответов не имеет механизма шифрования; как правило, любая защита, требуемая приложением или службой, вызывается после DNS-запроса, когда обращаются к разрешенной службе. Только в частных средах DNS (включая DNS с разделенным горизонтом), в которых идентификация запрашивающего лица обеспечивается с помощью некоторой внешней политики, DNS может вести конфиденциальные записи, предоставляя четкие ответы частным и общедоступным пользователям DNS. В поддержку балансировки нагрузки или других оптимизаций DNS-сервер может возвращать разные адреса в ответ на запросы из разных источников или даже вообще не отвечать; см. раздел 3.1.1 для деталей.

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

Указания в этом документе дополняют указания по расширению DNS, приведенные в [RFC5507]. Принимая во внимание, что [RFC5507] рассматривает предпочтительные способы добавления новой информации к базовому синтаксису DNS (например, определение новых записей ресурсов или добавление префиксов или суффиксов к меткам), в текущем документе рассматриваются более широкие последствия приложений, которые полагаются на DNS для реализация определенных функций, будь то через расширение DNS или простое повторное использование существующих возможностей протокола — последствия, которые могут касаться вызова распознавателя приложениями; поведение серверов имен, распознавателей или кэшей; расширения базового протокола DNS; оперативные обязанности администраторов зоны; безопасность; или общая архитектура имен. Когда существующие поля протокола DNS используются так, что их разработчики не намеревались обрабатывать новые приложения, эти приложения могут потребовать дальнейших изменений и расширений, которые в корне расходятся с сильными сторонами DNS.

2. Обзор использования приложений DNS

[RFC 882] идентифицирует исходную и фундаментальную связь между DNS и приложениями. Он начинается с описания того, как междоменная область приложений создает «огромные проблемы, когда мы хотим создать согласованные методы для ссылки на конкретные ресурсы, которые похожи, но разбросаны по среде». Это побудило преобразовать «отображение между именами хостов … и интернет-адресами ARPA» из глобальной таблицы (исходный файл «hosts») в «распределенную базу данных, которая выполняет ту же функцию». [RFC 882] также предусматривал несколько способов поиска ресурсов, связанных с почтовыми ящиками в домене: без этих расширений у пользователя, пытающегося отправить почту в чужой домен, не было механизма обнаружения, чтобы найти нужный хост в удаленном домене, к которому нужно подключиться.

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

2.1. Поиск услуг в домене

MX Resource Record предоставляет простейший пример приложения, рекламирующего свои ресурсы уровня домена в системе доменных имен. Запись ресурса MX содержит доменное имя сервера, который получает почту от имени соответствующего административного домена; это доменное имя само должно быть преобразовано в один или несколько IP-адресов через DNS для доступа к почтовому серверу. Хотя соглашения о присвоении имен для приложений могут служить аналогичной цели (например, хост может называться «mail.example.com»), доступ к расположению службы посредством создания новой записи ресурса дает важные преимущества. Например, можно назначить несколько записей MX под одним и тем же именем, чтобы назначить ресурсы резервного копирования или распределить нагрузку между несколькими такими серверами (см. [RFC1794]); эти свойства не могли быть легко получены соглашениями о присвоении имен (см. [RFC4367], хотя в последнее время обнаружение служб на основе DNS (DNS-SD) [RFC6763] кодифицирует соглашения об именах экземпляров служб для использования в приложениях для определения местоположения служб в домене).

Хотя запись MX представляет собой существенное улучшение по сравнению с соглашениями об именах в качестве средства определения местоположения службы, она остается специфичной для отдельного приложения. Таким образом, общий подход записи MX был адаптирован для соответствия более широкому классу приложений посредством записи ресурса службы (SRV) (первоначально описанной в [RFC2052]). Запись SRV позволяет DNS-резолверам запрашивать конкретные службы и соответствующие транспорты (например, HTTP, работающий по протоколу TLS) [RFC2818] и узнавать имя хоста и порт, где эта служба находится в данном домене. Он также предоставляет механизм взвешивания, позволяющий распределять нагрузку между несколькими экземплярами службы.

Зависимость приложений от наличия записей MX и SRV имеет важное значение для того, как приложения управляют идентификаторами и как приложения передают доменные имена распознавателям. Идентификаторы электронной почты в форме «user @ domain» полагаются на записи MX, чтобы обеспечить удобство простого указания компонента «домен», а не требовать от приложения угадывать, какой именно хост обрабатывает почту от имени домена. В то время как соглашения о наименовании продолжают изобиловать («www.example.com») для приложений, таких как просмотр веб-страниц, записи SRV позволяют приложениям запрашивать протокол для конкретного приложения и транспорт в домене. Для Облегченного протокола доступа к каталогам (LDAP) имя службы SRV соответствует схеме URL идентификатора, вызываемого приложением (например, когда «ldap: //example.com» является идентификатором, запрос SRV передается распознавателю). для «_ldap._tcp.example.com»); для других приложений имя службы SRV, которое приложение передает распознавателю, может быть неявным в идентификаторе, а не явным. В любом случае приложение доставляет имя службы в DNS, чтобы найти местоположение узла этой службы для домена, порт, в котором находится служба на этом узле, дополнительные расположения или порты для балансировки нагрузки и отказоустойчивости, и связанные функции приложения.

Поиск определенных служб для домена был первой основной функцией, для которой приложения начали использовать DNS за пределами простого разрешения имен. SRV расширил и обобщил прецедент MX, чтобы сделать расположение службы доступным для любого приложения, а не только для почты. Поскольку приложениям, которые получают записи MX (или SRV), может потребоваться выполнить дополнительные запросы или преобразования, чтобы получить конечное доменное имя, которое будет преобразовано в IP-адреса для службы, [RFC1034] разрешил, чтобы в разделе Дополнительная (данные) Ответы DNS могут содержать соответствующие записи адресов для имен служб, обозначенных записью MX; эта оптимизация, требующая поддержки на полномочном сервере и в распознавателе, является начальным примером того, как поддержка функций приложения требует изменений в работе DNS. В то же время это пример расширения DNS, на которое нельзя полагаться повсеместно: многие реализации распознавателя DNS будут игнорировать адреса в дополнительном разделе ответов DNS из-за проблем надежности, описанных в [RFC2181].

2.2. NAPTR и DDDS

Запись ресурса NAPTR была разработана для удовлетворения потребности перехода от универсального указателя ресурса (URL) к более зрелой структуре универсального идентификатора ресурса (URI) [RFC3986], в которую были включены унифицированные имена ресурсов (URN). В отличие от URL-адресов, URN, как правило, не передают достаточную семантику внутренне для их разрешения через DNS, и, следовательно, для преобразования этих типов URI в доменные имена требуется отдельный механизм преобразования URI. Это позволяет идентификаторам без распознаваемого доменного компонента обрабатываться как доменные имена с целью разрешения имен. Как только эти преобразования приводят к появлению доменного имени, приложения могут получать записи NAPTR под этим именем в DNS. Записи NAPTR содержат гораздо более сложную и сложную структуру, чем записи ресурсов MX или SRV. Запись NAPTR содержит два разных весовых механизма («порядок» и «предпочтение»), поле «сервис» для обозначения приложения, которое описывает запись NAPTR, а затем два поля, которые могут содержать переводы: поле «замена» или « regexp «(регулярное выражение), только одно из которых появляется в данной записи NAPTR (см. [RFC2168]). «Замена», подобно предку NAPTR записи PTR, просто обозначает другое доменное имя, где можно искать записи, связанные с этой услугой в домене. «Regexp», с другой стороны, позволяет преобразовывать регулярные выражения в исходном URI, предназначенном для превращения его в идентификатор, который может разрешить DNS.

Как говорится в аннотации к [RFC2915], «это позволяет использовать DNS для поиска сервисов по широкому спектру имен ресурсов (включая URI), которые не имеют синтаксиса доменных имен». Любой вид иерархического идентификатора потенциально может быть закодирован как доменное имя, и, таким образом, исторически DNS часто использовался для разрешения идентификаторов, которые никогда не разрабатывались в качестве имени для хоста Интернета. Яркий ранний пример можно найти в домене in-addr [RFC0883], в котором адреса IPv4 кодируются как доменные имена с применением алгоритма подготовки строки, который требует обращения октетов и обработки каждого отдельного октета как метки в имени домена — таким образом, например, адрес 192.0.2.1 стал 1.2.0.192.in-addr.arpa. Это позволило распознавателям запрашивать DNS, чтобы узнать имена, связанные с адресом IPv4. Тот же механизм был применен к адресам IPv6 [RFC3596] и другим видам идентификаторов, в которых отсутствует компонент домена. В конце концов, эта идея была связана с деятельностью по созданию системы разрешения телефонных номеров в Интернете, которая стала называться ENUM (первоначально описанной в [RFC2916]). ENUM заимствовал из более раннего предложения, домена «tpc.int» [RFC1530], который предоставлял средства для кодирования телефонных номеров в качестве доменных имен, применяя алгоритм подготовки строк, который требовал обращения цифр и обработки каждой отдельной цифры как метки в имя домена — таким образом, например, номер +15714345400 стал 0.0.4.5.4.3.4.1.7.5.1.tpc.int. В системе ENUM вместо «tpc.int» зарезервирован для использования специальный домен «e164.arpa».

В более зрелой форме стандарта NAPTR, в структуре Динамической системы делегирования (DDDS) [RFC3401], первоначальное преобразование идентификатора (такого как номер телефона) в доменное имя называлось «Первое хорошо известное правило». , Механизм реверсирования адресов, посредством которого имя запроса формируется путем обращения адреса IPv4 и добавления его к домену in-addr.arpa, обобщается для использования NAPTR: каждое приложение определяет «Первое хорошо известное правило», которое переводит конкретный ресурс. в имя запроса. Его гибкость вдохновила ряд предложений, помимо ENUM, на кодирование и разрешение неортодоксальных идентификаторов в DNS. При условии, что идентификаторы, преобразованные по «Первому общеизвестному правилу», имеют некоторую значимую структуру и не слишком длинны, практически все может служить входом для структуры DDDS: например, гражданские адреса. Хотя в [RFC3402] оговорено в отношении идентификатора, что «лексическая структура этой строки должна подразумевать уникальный путь делегирования», не требуется, чтобы идентификатор был иерархическим или чтобы точки делегирования в доменном имени создавались с помощью «First Well Known». Правило «соответствует любым точкам административного делегирования, присущим структуре идентификатора.

Хотя эта возможность поиска имен, «которые не входят в синтаксис доменного имени», не меняет базовый протокол DNS — имена, сгенерированные алгоритмом DDDS, по-прежнему являются просто доменными именами, но они изменяют контекст, в котором приложения передают имя распознавателям и потенциально может потребовать совсем другой практики работы администраторов зоны (см. раздел 3.3). С точки зрения результатов DNS-запроса, наличие поля «regexp» записей NAPTR дало беспрецедентную гибкость в типах идентификаторов, которые приложения могут обрабатывать с помощью DNS. Поскольку выходные данные регулярного выражения часто принимают форму URI (например, в разрешении ENUM телефонный номер может быть преобразован в SIP URI [RFC3261]), все, что может быть закодировано как URI, может быть результатом разрешение записи NAPTR, которая, как показано в следующем разделе, по существу означает произвольные данные.

2.3. Произвольные данные в DNS

Кодировка URI имеет способы инкапсуляции в основном произвольных данных: наиболее крайним примером является URL-адрес данных [RFC2397]. Таким образом, возвращаемая запись NAPTR может быть интерпретирована для получения выходных данных, отличных от имени домена, которые впоследствии будут преобразованы в IP-адреса и с которыми связываются для конкретного приложения — это может дать буквальный результат, который будет использоваться приложением. Первоначально, как обсуждалось в [RFC2168], предполагаемая применимость поля регулярного выражения в NAPTR была более узкой: поле «regexp» содержало «выражение подстановки, которое применяется к исходному URI для создания следующего имени домена для поиска» для того, чтобы «изменить хост, с которым связываются для разрешения URI» или как способ «изменить путь или хост после назначения URL». Инструменты регулярного выражения, доступные авторам записей NAPTR, однако, предоставляют гораздо более широкие возможности для изменения входной строки, и, таким образом, приложения стали полагаться на NAPTR для выполнения более радикальных преобразований, которые не удовлетворяли ни одной из вышеупомянутых потребностей. Согласно [RFC3402], вывод DDDS полностью зависит от приложения: «Приложение должно определить, каким должен быть ожидаемый вывод правила терминала», а пример, приведенный в документе, — это идентификация автомобильных деталей путем ввода номера детали и получение в конце процесса информации о производителе.

Исторически говоря, NAPTR не был пионером хранения произвольных данных в DNS. В начале [RFC0882] заметил, что «маловероятно, что все пользователи доменных имен смогут договориться о наборе ресурсов или информации о ресурсах, которые имена будут использоваться для извлечения», и, следовательно, накладывает небольшое ограничение на информацию, которая Записи DNS могут нести: это могут быть «адреса хоста, данные почтового ящика и другая пока еще неопределенная информация». [RFC1035] определил запись TXT, средство для хранения произвольных строк в DNS; [RFC1035] также конкретно оговаривает, что TXT содержит «описательный текст» и что «семантика текста зависит от области, в которой он находится». Существование записей TXT уже давно предоставляет новым приложениям быстрый способ хранения данных, связанных с доменным именем, в DNS, поскольку добавление данных таким способом не требует процесса регистрации. [RFC1464] экспериментировал со средством включения пар имя / значение в структуру записи TXT, что позволяло приложениям различать разные порции данных, хранящихся в записи TXT, — конечно, не просто «описательный текст», как первоначально указывалось TXT. Таким образом, приложение, которое хочет хранить дополнительные данные в DNS, может сделать это без регистрации нового типа записи ресурса, хотя [RFC5507] указывает, что «трудно надежно отличить запись одного приложения от других и для его анализатора» чтобы избежать проблем, когда он встречает другие записи TXT «.

Несмотря на то, что открытые политики, связанные с использованием записи TXT, привели к тому, что стандартизация использования TXT в приложениях прошла мимо, TXT использовался в качестве технического решения для многих приложений. Недавно DKIM [RFC6376] обошел проблему неоднозначности TXT, сохранив ключи под специализированной структурой именования DNS, которая включает в себя компонент «_domainkeys», который служит для ограничения области действия этого TXT исключительно для использования DKIM. Хранение ключей в DNS стало предпочтительным решением для DKIM по нескольким причинам: в частности, потому что почтовые приложения уже запрашивали DNS в своих обычных операциях, потому что открытые ключи, связанные с электронной почтой, требовали широкого публичного распространения, а также потому, что идентификаторы электронной почты содержат компонент домена, который приложения могут легко использовать для обращения к DNS. Если бы приложению пришлось договариваться о поддержке механизма DKIM с почтовыми серверами, это приводило бы к атакам с понижением частоты (когда злоумышленники искажали представление о том, что DKIM не поддерживается на исходной стороне), что невозможно, если DNS доставляет ключи (при условии, что DNSSEC [RFC4033] гарантирует подлинность данных). Тем не менее, существуют потенциальные проблемы с хранением больших данных в DNS, как обсуждалось в разделе 3.2.1, а также с соглашениями о пространстве имен DKIM, которые усложняют использование подстановочных знаков DNS (как обсуждено в разделе 6.1.2 [RFC6376] и в более общих чертах в [RFC5507]). Если префиксы используются для идентификации записей TXT, используемых приложением, потенциально использование подстановочных знаков может, кроме того, вызвать утечки, которые другие приложения должны будут обнаружить.

3. Проблемы для DNS

Методы, которые обсуждались в предыдущем разделе для преобразования произвольных идентификаторов в доменные имена и возврата произвольных данных в ответ на запросы DNS, представляют существенные отклонения от базовой функции преобразования имен хостов в IP-адреса, но ни один из них принципиально не изменяет основную семантику DNS. Однако, если учесть, что URI, возвращаемые DDDS, могут быть двоичными данными в кодировке base-64 в URL-адресе данных, DNS может эффективно реализовать весь набор функций приложения любого простого протокола запроса-ответа. По сути, структура DDDS считает DNS общей базой данных — действительно, структура DDDS была разработана для работы с любой базой данных; как говорится в [RFC3403], DNS — это только одна потенциальная база данных для использования DDDS. Однако может ли DNS как базовая база данных поддерживать функции, необходимые для некоторых приложений DDDS, — вопрос более сложный.

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

Поскольку многие из этих новых требований появились в пространстве ENUM, в следующих разделах ENUM используется в качестве иллюстративного примера; однако любое приложение, использующее DNS в качестве многофункциональной базы данных, может легко столкнуться с аналогичными требованиями.

3.1. Сложные Запросы

Традиционно DNS RRsets уникально идентифицируются по имени домена, типу записи ресурса и классу. DNS-запросы основаны на этом 3-х кортеже, и ответы представляют собой наборы записей ресурсов, которые должны рассматриваться как элементарные элементы данных (см. [RFC2181]); для приложений поведение DNS традиционно соответствовало поисковому механизму с точным соответствием. Однако за пределами пространства DNS существует множество приложений запросов-ответов, которые требуют сложного или реляционного поиска, одно из которых учитывает более одного фактора при формулировании ответа, или одно, которое не использует ни одного отдельного фактора в качестве ключа для базы данных. Например, в области телефонии маршрутизация телефонных вызовов часто учитывает множество факторов, помимо набираемого номера, в том числе исходящие группы соединительных линий, выбор оператора обмена между абонентами, данные о переносимости номера, время суток и т. Д. Все учитываются одновременно при создании маршрута. Хотя в своей первоначальной концепции ENUM надеялась обойти традиционную коммутируемую телефонную сеть общего пользования (PSTN) и проложить маршрут непосредственно к устройствам с доступом в Интернет, инфраструктура ENUM, направленная на поддержку миграции функций маршрутизации традиционных операторов связи в Интернет, стремится достичь паритета функций с традиционными маршрутизация номеров. Однако в [RFC3402] прямо говорится, что «в DDDS предполагается, что лексический элемент, используемый для принятия решения о делегировании, достаточно прост, чтобы содержаться в самой уникальной строке приложения. DDDS не решает случай, когда решение о делегировании» производится с использованием знаний, содержащихся вне AUS и Правила (время суток, финансовые операции, управление правами и т. д.) ». Следовательно, некоторое внимание было уделено способам добавления дополнительных данных к запросам ENUM, чтобы дать DNS-серверу достаточную информацию для возврата подходящего URI (см. Раздел 3.1.1).

Однако с чисто синтаксической точки зрения доменные имена не допускают такой богатой структуры. Несколько обходных путей пытались создать такие функции в DNS-запросах. Например, само доменное имя может быть дополнено дополнительными параметрами: можно взять имя, например 0.0.4.5.4.3.4.1.7.5.1.e164.arpa, и добавить к нему идентификатор группы СЛ, например, из Форма tg011.0.0.4.5.4.3.4.1.7.5.1.e164.arpa. Хотя в этом конкретном случае DNS-сервер может придерживаться своего традиционного поведения при поиске записей ресурсов, синтаксическая жизнеспособность кодирования дополнительных параметров таким образом сомнительна, особенно если требуется более одного дополнительного параметра и наличие параметров является необязательным, так что приложению нужно несколько запросов для оценки полноты информации, необходимой для выполнения его функции.

В качестве альтернативы было предложено добавить дополнительные параметры запроса в качестве механизмов расширения для расширений DNS (EDNS (0)) (см. [RFC6891]). Это может быть проблематично по трем причинам. Во-первых, поддержка расширений EDNS (0) требует значительных изменений в поведении сервера имен; эти изменения должны поддерживаться авторитетными и рекурсивными серверами имен, на которые опирается приложение, и их может быть очень трудно реализовать в глобальном масштабе. Кроме того, первоначальная заявленная применимость механизма EDSN (0), как говорится в [RFC2671], заключалась в «конкретном сообщении транспортного уровня, а не в каких-либо фактических данных DNS», и, следовательно, указанные в нем записи ресурсов OPT никогда не должны быть пересылаются. Однако использование EDNS (0) для составных запросов явно предназначено для различения реальных данных DNS, а не для облегчения обработки на транспортном уровне. Наконец, [RFC6891] также указывает, что «OPT RR НЕ ДОЛЖНЫ кэшироваться, пересылаться или храниться» (см. Следующий абзац). По этим причинам в этом документе не рекомендуется составлять сложные DNS-запросы с использованием EDNS (0).

Последствия такого рода составных запросов для рекурсии и кеширования потенциально серьезны. Логика, используемая авторитетным сервером для ответа на составной запрос, может быть не понята никакими рекурсивными серверами или кешами; посредники, которые наивно полагают, что ответ был выбран на основе только имени домена, типа и класса, могут обслуживать ответы на запросы не так, как намеревается уполномоченный сервер. Следовательно, если бы EDNS (0) использовался таким образом, его атрибуты не были бы транзитивными, и если бы это не учитывалось при использовании посредников, как это обычно происходит в глобальном DNS, может произойти нарушение работы.

3.1.1. Ответы с учетом автора

Ответы DNS, адаптированные к идентификатору их отправителя, где некоторая административная идентификация отправителя должна быть передана в DNS, составляют наиболее важный подкласс этих составных запросов. Сначала мы должны отличить это от случаев, когда исходный IP-адрес или аналогичное указание используется для обслуживания имени, специфичного для местоположения. Для приложений такого типа, которые обычно не влияют на безопасность, использование таких факторов, как исходный IP-адрес, приносит мало вреда; например, при предоставлении веб-портала, настроенного для региона клиента, это не будет нарушением безопасности, если клиент увидит локализованный портал не той страны. Поскольку рекурсивные средства распознавания могут скрывать исходную сеть DNS-клиента, в недавнем предложении было предложено ввести новый параметр запроса DNS, который должен заполняться рекурсивными преобразователями DNS, чтобы сохранить исходящий IP-адрес (см. [EDNS-CLIENT-IP]). Однако, помимо чисто косметического использования, эти подходы имеют известные ограничения из-за преобладания частных IP-адресов, VPN и т. Д., Которые затемняют исходный IP-адрес и вместо этого предоставляют IP-адрес посредника, который может быть очень далек от исходная конечная точка. Внедрение технологии, такой как описанная в [EDNS-CLIENT-IP], потребует значительных изменений в работе рекурсивных распознавателей и авторитетных серверов, которые будут полагаться на исходный IP-адрес источника для выбора записей ресурсов, и, кроме того, фундаментальное изменение в кэшировании поведение также. В результате такая технология не может быть развернута пошаговым, односторонним способом, а может быть успешной только при двусторонней реализации (с помощью авторитетного сервера и рекурсивного преобразователя); это значительный барьер для развертывания.

В других используемых сегодня развертываниях, в том числе на основе функции «просмотров» BIND, IP-адрес источника используется для предоставления доступа к выбранному и потенциально конфиденциальному набору записей ресурсов. Последствия для безопасности, связанные с доверием исходному IP-адресу DNS-запроса, не позволяют стандартизировать большинство решений по этим направлениям (см. [RFC6269]), хотя эта практика остается широко распространенной в частном развертывании DNS с разделением горизонта (см. Раздел 4), который обычно полагаются на базовый уровень безопасности, такой как физическая сеть, четкое разграничение периметра в точке периметра сети (с мерами противодействия спуфингу сетевого уровня) или VPN IPsec для предотвращения подмены исходного IP-адреса. Эти развертывания действительно требуют соблюдения конфиденциальности, чтобы предотвратить утечку информации, предназначенной для ограниченной аудитории (например, внутри предприятия), в общедоступный Интернет — в то время как эти ресурсы внутренней сети могут использовать частные IP-адреса, которые не должны быть полезны для общего пользования. В любом случае, в Интернете в некоторых случаях эта утечка может привести к раскрытию топологии или другой информации, которую администратор сервера имен надеется сохранить в секрете. Совсем недавно TSIG [RFC2845] использовался как способ выбора среди «представлений» в BIND; это обеспечивает более высокий уровень безопасности, чем простое использование IP-адреса источника, но обычно многие пользователи совместно используют один и тот же секрет для доступа к данному представлению, и, кроме того, TSIG не обеспечивает свойства конфиденциальности для сообщений DNS — без разделения сетевого уровня между пользователями из разных представлений, перехватчики могут захватывать DNS-запросы и ответы.

Использование исходных IP-адресов в качестве дискриминатора для выбора записей ресурсов DNS, независимо от того, не принимается ли оно сообществом стандартов, широко распространено в данной области. Однако некоторые приложения идут еще дальше и предлагают расширить DNS, чтобы добавить идентификатор отправителя на уровне приложения; например, [EDNS-OPT-CODE] предоставляет SIP URI в параметре EDNS (0). По сути, эта передача информации прикладного уровня об административной идентичности отправителя через DNS является слабым механизмом аутентификации, на основе которого DNS-сервер принимает решение об авторизации перед совместным использованием записей ресурсов. Это может аппроксимировать механизм конфиденциальности для каждой записи ресурса, где только определенному набору инициаторов разрешено просматривать записи ресурса, или в случае, когда запрос на одно и то же имя разными объектами приводит к совершенно разным наборам записей ресурса. Однако без какой-либо криптографической защиты этот механизм должен полагаться на внешние уровни безопасности (такие как VPN), а не на какую-либо прямую гарантию. Опять же, кэширование, пересылка и рекурсия создают значительные проблемы для приложений, которые пытаются переложить эту ответственность на DNS. Достижение паритета функциональных возможностей даже с помощью самых простых механизмов аутентификации, доступных на уровне приложений, вероятно, потребует значительной реархитектуры DNS.

3.2. Использование DNS в качестве общей базы данных

Как отмечалось ранее, приложения могут использовать метод, подобный «Первому общеизвестному правилу» DDDS, для преобразования произвольной строки в доменное имя, а затем получения от DNS произвольных данных, хранящихся в RX TXT, в «регулярном выражении» NAPTR или даже в пользовательских записях. Однако некоторые приложения запросов-ответов требуют запросов и ответов, которые просто выходят за рамки синтаксических возможностей DNS. Например, сами доменные имена должны состоять из меток, которые не превышают 63 октета, в то время как общая длина закодированного имени не может превышать 255 октетов, и приложения, которые используют символы меток вне традиционного набора ASCII, могут столкнуться с проблемами (однако см. обсуждение в [RFC6055], раздел 3 для окончательного руководства по использованию non-ASCII в DNS). Поэтому DNS не может быть полностью общей базой данных. Аналогичные проблемы относятся к размеру ответов DNS.

3.2.1. Большие данные в DNS

Хотя спецификация URL «data» [RFC2397] отмечает, что она «полезна только для коротких значений», к сожалению, она не дает конкретных указаний относительно того, что может означать «short». Некоторые приложения сегодня используют довольно большие URL-адреса данных (содержащие мегабайт или более данных) в качестве обходного пути в средах, где синтаксически могут появляться только URI (например, в Apple iOS, для передачи объектов между приложениями). Значение «короткий» в контексте приложения, вероятно, очень отличается от того, как мы должны понимать его в сообщении DNS. Обращаясь к типичному общедоступному развертыванию DNS, [RFC5507] отмечает, что «существует сильный стимул сохранять сообщения DNS достаточно короткими, чтобы помещаться в дейтаграмму UDP, предпочтительно дейтаграмму UDP, достаточно короткую, чтобы не требовать фрагментации IP». И хотя EDNS (0) позволяет механизмам согласовывать размеры сообщений DNS, превышающие традиционные 512 октетов, существует высокий риск того, что большая полезная нагрузка вызовет фрагментацию UDP, в частности, когда сообщение DNS уже несет информацию DNSSEC. Если EDNS (0) недоступен или согласованный размер пакета EDNS (0) слишком мал для размещения данных, или фрагменты UDP отброшены, DNS может (в конечном итоге) прибегнуть к использованию TCP. В то время как TCP позволяет DNS-ответам быть достаточно длинными, это требует работы серверов с отслеживанием состояния, что может быть дорогостоящим в развертываниях, где серверы имеют только временные соединения со многими клиентами. В конечном счете, существуют формы данных, которые приложение может хранить в DNS, которые превышают разумные пределы: например, в контексте ENUM, что-то вроде хранения mp3-файлов в кодировке base-64 с собственными мелодиями звонка.

Проекты, основанные на хранении больших объемов данных в DNS RR, также должны минимизировать потенциальный ущерб, достижимый при атаке с отражением (см. [RFC4732], раздел 3), когда злоумышленник отправляет DNS-запросы только по UDP с поддельным адресом источника, и жертва получает ответ. Атакующий использует усиление, когда небольшой запрос генерирует большой ответ, направленный на жертву. Если ответчик поддерживает EDNS (0), злоумышленник может установить максимальный размер полезной нагрузки запрашивающей стороны на большее значение при запросе большой записи ресурса, такой как сертификат [RFC4398]. Таким образом, комбинация больших данных, хранимых в DNS RR и отвечающих, поддерживающих большие размеры полезной нагрузки, может увеличить потенциальный ущерб, достижимый при атаке отражением.

Поскольку атака с отражением может быть запущена из любой сети, в которой не реализована проверка адреса источника, эти атаки трудно устранить в отсутствие повсеместного развертывания проверки адреса источника или «более тяжелых» транспортных протоколов, таких как TCP. Пропускная способность, которую можно использовать в атаке с отражающим усилением, направленной ботнетом, отражающимся от рекурсивного сервера имен в сети с высокой пропускной способностью, отрезвляет. Например, если отвечающий распознаватель может быть направлен на генерацию ответа 10 КБ в ответ на 50-октетный запрос, тогда увеличение 200:1 будет достижимо. Это позволило бы ботнету, управляющему 10000 хостами с пропускной способностью 1 Мбит/с, сосредоточить 200 Гбит/с трафика на жертве, что более чем достаточно для загрузки любого сайта в современном Интернете.

Атаки DNS-отражения обычно используют UDP-запросы; Запрещается трудно выполнить трехстороннее рукопожатие TCP, начатое с поддельного адреса источника для атак отражения DNS. Если злоумышленник не использует EDNS (0) [RFC6891] для увеличения максимального размера полезной нагрузки запрашивающей стороны, ответ может достигать только 576 октетов, прежде чем в ответе будет установлен усеченный бит. Это ограничивает максимальное увеличение, достижимое от запроса DNS, который не использует EDNS (0). Поскольку большое несоответствие между размером запроса и размером ответа создает это усиление, методы для смягчения этого несоответствия должны быть дополнительно изучены, хотя это выходит за рамки этого меморандума (для анализа эффектов ограничения EDNS (0 ) ответы, все еще приспосабливая DNSSEC, см. [Линдсей]). Например, некоторые реализации могут ограничивать ответы EDNS (0) конкретным отношением по сравнению с размером запроса, где точное соотношение может быть настроено для каждого развертывания (с учетом размеров ответов DNSSEC). Без каких-либо средств смягчения потенциала для амплификации EDNS (0) может нанести значительный вред.

Таким образом, есть две операционные силы, которые стремятся снизить практически доступные размеры EDNS (0): возможная фрагментация UDP и минимизация усиления в случае атак отражением. Данные DNSSEC будут использовать значительную часть доступного пространства в пакете DNS. Поэтому, принимая во внимание тот факт, что, учитывая текущий опыт развертывания DNSSEC и EDNS (0), точные числа дать невозможно — общая полезная нагрузка, доступная для других данных DNS, учитывая предпосылку минимизации аварийного восстановления TCP, вероятно, будет ближе. до нескольких сотен октетов, чем несколько тысяч октетов.

3.3. Административные структуры смещены с DNS

В то время как структура DDDS позволяет любому типу буквенно-цифровых данных служить в качестве имени домена посредством применения «Первого общеизвестного правила», делегативная структура результирующего имени домена может не отражать какого-либо административного разделения обязанностей, присущих исходным данным. В то время как [RFC3402] требует только, чтобы «Строка уникальности приложения имела какую-то регулярную лексическую структуру, к которой могут применяться правила», DDDS — это, прежде всего, система делегирования: ее абстракция предусматривает, что «правильно сформированные правила преобразования будут отражать Делегирование управления информацией, связанной со строкой ». Например, телефонные номера в Соединенных Штатах присваиваются и делегируются относительно сложным образом. Исторически первые шесть цифр национального номера (называемого «NPA / NXX») отражали точку административного делегирования от агентства по присвоению номеров перевозчику; из этих блоков, состоящих из десяти тысяч номеров, перевозчик, в свою очередь, делегировал бы индивидуальные назначения последних четырех цифр (часть «XXXX») конкретным клиентам. Однако после повышения переносимости телефонных номеров в Северной Америке в 1990-х годах первый пункт делегирования пропал: фактически делегирование осуществляется от полномочий по нумерации к оператору связи для каждого полного десятизначного номера (NPA / NXX-XXXX). Хотя детали технической реализации в разных странах различны, в настоящее время во всем мире существуют системы переносимости номеров с аналогичными административными полномочиями.

При преобразовании этих идентификаторов в качестве доменных имен в соответствии с правилом DDDS для ENUM получается большой плоский административный домен без точек административного делегирования от администратора кода страны, например, 1.e164.arpa, вплоть до конечного правопреемника номера. , В предположении, что один административный домен поддерживается в пределах одной DNS-зоны, содержащей потенциально более пяти миллиардов имен, трудности масштабируемости проявляются в ряде областей: масштабируемость, возникающая в результате кэширования, зависит от этих точек делегирования, поэтому кэшированные результаты для промежуточных серверов принимают нагрузка на серверы более высокого уровня. Если таких делегаций нет, то, как в примере с номером телефона, сервер зоны Apex должен нести всю нагрузку для запросов. Что еще хуже, переносимость номеров также привносит гораздо больший динамизм в назначение номеров, поскольку в некоторых регионах обновленные уполномоченные для перенесенных номеров должны распространяться в течение пятнадцати минут после смены администрации. Вместе эти две проблемы делают кеширование зоны чрезвычайно проблематичным. Кроме того, традиционные инструменты репликации DNS, такие как протоколы передачи зон AXFR [RFC1034] и IXFR [RFC1995], могут не масштабироваться для размещения зон с этими размерами и свойствами.

На практике максимальные размеры административных доменов телефонных номеров ближе к 300M (текущее количество выделенных телефонных номеров в Соединенных Штатах сегодня — все еще более чем в три раза превышает количество доменных имен .com), и можно уменьшить некоторые из упомянутые выше проблемы масштабируемости путем искусственного разделения административного домена на иерархию зон DNS. Тем не менее тот факт, что традиционные инструменты управления DNS больше не применяются к структурам, которые приложение пытается предоставить в DNS, указывает на то, что DNS может не подходить для приложения для хранения своих данных.

Хотя DDDS является наиболее очевидным примером этих проблем, суть более общая: например, если переносимость адресов должна быть реализована для IP-адресов и, следовательно, их администрирование станет неиерархическим, то же самое относится и к in-addr.arpa. имена. Трудность сопоставления DNS с административными структурами может даже возникнуть с традиционными доменными именами, где приложения ожидают, что клиенты будут определять или обнаруживать сокращения зоны. Например, в веб-контексте приложениям может быть сложно определить, представляют ли два домена один и тот же «сайт» при сравнении учетных данных безопасности с URL-адресами (подробнее см. В разделе 3.4 ниже). Это также вызвало известные проблемы при определении области действия веб-файлов cookie в тех случаях, когда приложения должны определить, где заканчиваются административные домены, для предоставления файлов cookie, которые имеют как можно более узкую область действия.

Таким образом, «первое общеизвестное правило» DDDS обеспечивает возможность преобразования произвольных строк в доменные имена, но эти имена хорошо работают с DNS только тогда, когда входные строки имеют административную структуру, которая сопоставляется с делегированиями DNS. Во-первых, делегирование подразумевает некую иерархическую структуру. Любой механизм преобразования иерархического идентификатора в доменное имя должен быть сконструирован таким образом, чтобы результирующее доменное имя соответствовало естественной иерархии исходного идентификатора. Хотя телефонные номера, даже в Северной Америке, имеют некоторые иерархические качества (например, географические области, соответствующие их первым трем цифрам), после реализации переносимости номеров эти точки больше не отображаются на административное делегирование. Если входная строка в DDDS не имеет иерархической структуры, представляющей административные делегации, которые могут отображаться в системе распределения DNS, то эта строка, вероятно, не является подходящим кандидатом для перевода в доменное имя.

3.3.1. Метаданные о древовидной структуре

Существуют также другие способы, с помощью которых делегирующая структура идентификатора может плохо отображаться на DNS. Традиционно распознаватели DNS предполагают, что, когда они получают доменное имя из приложения, имя является полным — что это не фрагмент доменного имени, который пользователь все еще находится в процессе ввода. Однако для некоторых систем связи это предположение не применяется. Варианты использования ENUM выявили пару требований оптимизации, чтобы уменьшить ненужные вызовы и запросы; Предлагаемые решения включают метаданные в DNS, которые описывают содержание и структуру деревьев ENUM DNS, чтобы помочь приложениям обрабатывать неполные запросы или запросы для доменов, которые не используются.

В частности, предложение «send-n» [ENUM-Send-N] рассчитывало сократить количество DNS-запросов, отправляемых в регионах с планами нумерации с переменной длиной. Когда набранный номер потенциально имеет переменную длину, телефонный коммутатор обычно не может предвидеть, когда набранный номер будет завершен, поскольку только администратор плана нумерации (который может быть национальным регулятором или даже в планах открытых номеров обмена частной веткой) знает, как длинный номер телефона должен быть. Следовательно, коммутатор, пытающийся разрешить такой номер через систему, такую как ENUM, может отправить запрос на номер телефона, который набран только частично, чтобы проверить его полноту. Предложение send-n устанавливает в DNS подсказку, информирующую телефонный коммутатор о минимальном количестве цифр, которое необходимо собрать, помещая в зоны, соответствующие неполным телефонным номерам, некоторые записи ресурсов, в которых указано, сколько еще цифр требуется — эффективно, сколько шаг вниз по дереву DNS, который необходимо выполнить перед повторным запросом DNS. Неудивительно, что эти границы отражают точки административного делегирования, когда родитель в числовом плане передает полномочия ребенку. Имея эту информацию, приложение не обязано запрашивать DNS каждый раз, когда набирается новая цифра, но может подождать, чтобы собрать достаточно цифр для получения ответа. Таким образом, в качестве оптимизации эта практика экономит ресурсы DNS-сервера, хотя вызов не может быть завершен до тех пор, пока не будут собраны все цифры, поэтому этот механизм просто сокращает время, которое система будет ожидать перед отправкой запроса ENUM после сбора последней набранной цифры. Тангенциально связанное предложение [ENUM-UNUSED] аналогичным образом размещает записи ресурсов в DNS, которые сообщают приложению, что ему не нужно пытаться набрать номер в телефонной сети, поскольку номер не назначен — сопоставимый общий механизм DNS определит для доменного имени, в котором нет записей, доступных в DNS, независимо от того, был ли домен выделен регистрантом владельцу регистрации (что является условием, отличным от того, что имя просто неразрешимо, в соответствии с семантикой NXDOMAIN).

Оба предложения оптимизируют поведение приложения, размещая метаданные в DNS, которые предсказывают успешность будущих запросов или вызова приложения, определяя точки административного делегирования или назначения в дереве. В некоторых отношениях маркировка точки в дереве, где зона начинается или заканчивается, имеет некоторые общие черты с традиционным использованием родительской зоны типа записи NS, за исключением того, что вместо указания на дочернюю зону эти предложения метаданных указывают на отдаленных внуков. Хотя это не меняет поведение распознавателя как таковое (вместо этого оно меняет способ, которым приложения вызывают распознаватель), оно имеет последствия для практики для администраторов зон. Метаданные в одном административном домене должны были бы оставаться синхронизированными с состоянием ресурсов, которые они предсказывают в другом административном домене в пространстве имен DNS, в случае, например, набора номера с перекрытием, когда оператор-носитель делегирует зону, контролируемую предприятием. При работе с внешними ресурсами, связанными с другими пространствами имен, такими как присвоение номеров в КТСОП или в базах данных оператора реестра, возникают другие требования к синхронизации; поддержание этой синхронизации требует, чтобы DNS имел обновления «полу-реального времени», которые могут конфликтовать с механизмами масштабирования и кэширования DNS.

Размещение метаданных в DNS также может вызвать вопросы о полномочиях и модели делегирования. Кто получает записи для неназначенных имен? Хотя в оригинальном, но малоиспользуемом корне ENUM e164.arpa это почти наверняка будет администратор плана нумерации, гораздо менее ясно, кто будет в более распространенных и успешных «инфраструктурных» моделях ENUM (см. Раздел 4). В конечном счете, эти предложения метаданных имеют некоторые общие черты со службами перенаправления DNS, предлагаемыми интернет-провайдерами (например, [DNS-REDIRECT]), которые «помогают» веб-пользователям, которые пытаются перейти на несуществующие сайты. Аналогично, предложения метаданных, такие как [ENUM-UNUSED], создают записи DNS для нераспределенных зон, которые перенаправляют на веб-страницу поставщика услуг. Однако в случаях [DNS-REDIRECT] наличие или отсутствие доменного имени по крайней мере является фактом о пространстве имен Интернета, а не о внешнем пространстве имен, таком как пространство имен телефонии E.164 (которое должно быть синхронизировано с дерево DNS в предложениях метаданных). В send-n разные конечные зоны, которые управляют телефонными номерами разной длины, могут предоставлять свои подсказки только для своего апекса, что обеспечивает несовершенную оптимизацию: они не могут установить его сами в родительском, как из-за отсутствия полномочий, так и из-за разных зон. хотел бы предоставить противоречивые данные. Чем позже подсказка появится в дереве, тем не менее будет достигнута оптимизация. Разработчик протокола приложения, управляющий идентификаторами, административная модель которых плохо отображается в пространстве имен DNS и структуре делегирования, будет лучше обслуживать такие функции вне DNS.

3.4. Перенаправление домена

Большинство интернет-приложений предоставляют функцию перенаправления — когда кто-то пытается связаться со службой, служба может отослать человека к другому экземпляру службы, возможно, в другом домене, который по какой-либо причине лучше подходит для обслуживания запроса. Например, в HTTP и SIP эта функция реализована 300 ответами класса, содержащими один или несколько URI, которые могут указывать на то, что ресурс временно или постоянно перемещен в другую службу. Несколько инструментов в DNS, включая запись SRV, могут предоставлять аналогичную функцию на уровне DNS, и, следовательно, некоторые приложения в качестве оптимизации снимают с себя ответственность за перенаправление на DNS; NAPTR также может предоставлять эту возможность для каждого приложения, а многочисленные записи ресурсов DNS могут обеспечивать перенаправление для каждого домена. Это может предотвратить ненужные затраты ресурсов приложения на функцию, которая может быть выполнена как компонент поиска DNS, который уже является предварительным условием для обращения к службе. Следовательно, в некоторых архитектурах развертывания это перенаправление уровня DNS используется для служб виртуального хостинга.

Однако реализация перенаправления домена в DNS имеет важные последствия для безопасности приложений. В отсутствие универсального DNSSEC приложения должны слепо полагать, что их запрос не был перехвачен на уровне DNS и перенаправлен в потенциально вредоносный домен, если какой-либо последующий механизм приложения не может обеспечить необходимую гарантию. В отличие от этого, протоколы уровня приложений, поддерживающие перенаправление, такие как HTTP и SIP, имеют доступные механизмы безопасности, включая TLS, которые могут использовать сертификаты для подтверждения того, что ответ 300 поступил от домена, с которым первоначально надеялся связаться отправитель.

Ряд приложений пытались обеспечить механизм защиты после факта, который проверяет полномочия делегирования DNS в отсутствие DNSSEC. Спецификация для разыменования URI SIP ([RFC3263], подтвержденная в [RFC5922]) требует, чтобы во время установления TLS сайт, в конечном итоге достигнутый запросом SIP, представил сертификат, соответствующий исходному URI, ожидаемому пользователем; для этого требуется, чтобы виртуальный хостинг обладал сертификатом, соответствующим размещенному домену. (Другими словами, если example.com перенаправляет на example.net в DNS, этот механизм ожидает, что example.net предоставит сертификат для example.com в TLS, согласно прецеденту HTTP в [RFC2818]). Однако это ограничение исключает многие стили развертывания хостинга, распространенные в современном мире. [HARD-ПРОБЛЕМА] исследует эту проблемную область. [RFC6125] предлагает решение для всех приложений, использующих TLS, которое опирается на новые специфичные для приложения идентификаторы в сертификатах, как и [RFC4985]); обратите внимание, однако, что поддержка таких сертификатов потребует изменения существующих практик центра сертификации, а также поведения приложения. Благодаря DNSSEC аутентификация именованных объектов на основе DNS (DANE) [RFC6394] предлагает еще один способ привязки сертификатов к конкретным приложениям и услугам.

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

4. Частный DNS и Split Horizon

Классический взгляд на уникальность доменных имен в DNS приведен в [RFC2826]:

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

[RFC2826] «не запрещает частным сетям работать со своими собственными частными пространствами имен», но отмечает, что если частные сети «хотят использовать имена, уникально определенные для глобального Интернета, они должны извлекать эту информацию из глобальной иерархии имен DNS» , Существуют различные развертывания DNS за пределами глобальной общедоступной DNS, в том числе развертывания «с разделением горизонта» и использование DNS в частных (или виртуальных частных) сетях. В разделенном горизонте авторитетный сервер дает разные ответы на запросы из общедоступного Интернета, чем внутренние преобразователи; в то время как в некоторых развертываниях внутренние запросы отличаются от общедоступных запросов по IP-адресу источника, проблемы в разделе 3.1.1, относящиеся к доверительным IP-адресам источника, относятся к таким развертываниям. Когда диапазон внутреннего адресного пространства является частным [RFC1918], это облегчает как для сервера разграничение публичного от частного, так и для публичных объектов труднее выдавать себя за узлы в частной сети. Сети, которые сделаны частными физически или логически с помощью криптографических туннелей, делают эти частные развертывания более безопасными. Наиболее сложные развертывания по этим направлениям используют несколько виртуальных частных сетей, чтобы обслуживать разные ответы для одного и того же имени во многих различных сетях.

Варианты использования, которые мотивируют DNS с разделением горизонта, обычно включают ограничение доступа к некоторым сетевым службам, например к ресурсам интрасети, таким как внутренние веб-сайты, серверы разработки или каталоги, при сохранении простоты использования, предлагаемой доменными именами для внутренних пользователей. , В то время как для многих из этих ресурсов разделение горизонта не будет возвращать ответы общедоступным распознавателям для этих внутренних ресурсов (эти записи хранятся в секрете от общественности), в некоторых случаях может разрешаться одно и то же имя (например, «mail.example.com») одному хосту внутренне, а другому внешне. Однако требования к частным развертываниям с несколькими VPN различны: в этом случае уполномоченный сервер дает разные и конфиденциальные ответы на набор распознавателей, запрашивающих одно и то же имя. Хотя такого рода случаи использования редко возникают для традиционных доменных имен, где, как говорится в [RFC2826], пользователи и приложения ожидают уникального разрешения для имени, они могут легко возникнуть, когда другие виды идентификаторов были переведены с помощью такого механизма, как «Первое известное правило» DDDS в «синтаксис имени домена». Например, телефонные звонки традиционно направляются через сети с высокой степенью посредничества, в которых попытка найти маршрут для вызова часто требует поиска подходящего посредника на основе исходной сети и местоположения, а не нахождения конечной точки (см. Различие между внешним видом). -Вверх Функция и функция маршрутизации местоположения в [RFC5486]). Более того, потребность в ответах, специально разработанных для инициатора, и конфиденциальности, легко мотивируется, когда данные, возвращаемые DNS, больше не «описывают адреса протоколов, сетевые ресурсы и услуги» [RFC2826], а вместо этого являются произвольными данными. Хотя, например, ENUM изначально предназначался для развертывания в глобальном общедоступном корне DNS (под e164.arpa), требования по поддержанию телефонных идентификаторов в DNS быстро привели операторов к частному развертыванию.

В частных средах также проще развернуть любые необходимые расширения, чем в общедоступной DNS: во-первых, собственные нестандартные расширения и параметры легче интегрировать в запросы или ответы DNS, как реализации распознавателей и серверы, вероятно, можно контролировать; во-вторых, конфиденциальность и пользовательские ответы могут быть обеспечены путем развертывания, соответственно, базовых физических или виртуальных частных сетей для защиты частного дерева от общедоступных запросов и, фактически, различных виртуальных деревьев DNS для каждого административного объекта, который может запустить запрос; в-третьих, в этих ограниченных средах кэширование и рекурсивные распознаватели можно управлять или исключать, чтобы предотвратить любое непредвиденное поведение посредника. Хотя эти частные развертывания играют важную роль на рынке, существуют риски при использовании методов, предназначенных только для развертывания в частных и ограниченных средах, в качестве основы стандартного решения. Когда проприетарные параметры или расширения развертываются в частных средах, опыт учит нас, что эти реализации начнут взаимодействовать с общедоступной DNS и что частные практики будут утекать.

Хотя такая утечка не является проблемой при использовании механизмов, описанных в разделах 3.1, 3.2 и 3.5 (с частными типами RR) [RFC5507], другие механизмы расширения могут привести к путанице или вреду в случае утечки. Использование выделенного суффикса (Раздел 3.3 [RFC5507]) в частной среде может привести к путанице, например, в случае утечки в общедоступный Интернет.

То, что такого рода утечка элементов протокола из частного развертывания в общедоступное развертывание действительно происходит, было продемонстрировано, например, с помощью SIP: SIP реализовал категорию предположительно частных расширений («P-» заголовки), которые получили широкое распространение и использование за пределами стесненные условия, для которых они были специально разработаны. Нет оснований полагать, что реализации с аналогичными «частными» расширениями протоколов DNS не будут аналогичным образом использоваться в общедоступных средах.

5. Принципы и руководство

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

Вполне вероятно, что DNS обеспечивает хорошее соответствие, когда потребности приложений соответствуют следующим свойствам:

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

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

Заполнение метаданных о границах домена в дереве — точки административного делегирования в DNS — это то, о чем приложения вообще не знают
Доменные имена, полученные из идентификаторов, которые не разделяют семантическую или административную модель, совместимую с DNS
Выборочное раскрытие данных, хранящихся и предоставленных DNS
Ответы DNS не вписываются в пакеты UDP, если только EDNS (0) не доступен, и только тогда с оговорками, обсуждаемыми в разделе 3.2.1.

В тех случаях, когда приложениям требуются функции такого рода, они, вероятно, лучше реализуются независимыми протоколами уровня приложений, чем DNS. Например, объекты, которые HTTP может переносить как в запросах, так и в ответах, могут легко содержать необходимую структуру для управления сложными запросами. Многие приложения уже используют HTTP из-за его широкой поддержки в промежуточных коробках. Аналогичным образом, HTTP имеет множество способов обеспечить необходимые свойства аутентификации, авторизации и конфиденциальности, которые требуются для некоторых функций, а также свойства перенаправления, описанные в разделе 3.4. Эти различия подчеркивают тот факт, что DNS и HTTP предлагают очень разные услуги и имеют различную применимость; в то время как оба являются протоколами запроса-ответа, HTTP не должен выполнять работу DNS, а DNS не должен выполнять работу HTTP. Точно так же DNS не должен выполнять работу Diameter, LDAP или других протоколов прикладного уровня. Конечно, накладные расходы на использование любого протокола прикладного уровня могут не подходить для всех сред, но даже в тех средах, где подходит более легкий протокол, DNS обычно не является единственной альтернативой.

В тех случаях, когда административные делегирования DNS образуют необходимый компонент при реализации функции приложения, существуют различные способы, с помощью которых DNS может загружать доступ к независимому протоколу прикладного уровня, более подходящему для выполнения рассматриваемых запросов. Например, поскольку записи ресурсов NAPTR или URI [URI-RR] могут содержать URI, эти URI, в свою очередь, могут указывать на внешнюю службу запросов, такую как служба HTTP, где можно обмениваться более синтаксически и семантически богатыми запросами и ответами. Любой разработчик протокола, рассматривающий, где реализовать функции, должен выполнить свой собственный анализ пробелов и определить, стоит ли реализация некоторых функций потенциальной стоимости при повышенном состоянии сети, задержке и т. Д., Но реализация некоторых функций просто требует более тяжелых структур, чем другие.

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

Многие проблемы, связанные с тем, как приложения используют DNS, обсуждаемые в этом документе, связаны с безопасностью. Осознанная необходимость аутентификации источника DNS-запросов (см. Раздел 3.1.1) и авторизации доступа к конкретным записям ресурсов также иллюстрирует фундаментальные принципы безопасности, возникающие при разгрузке определенных функций приложения в DNS. Как отмечается в разделе 3.2.1, большие данные в DNS могут служить средством для генерации атак отражения, и без средств, обсуждаемых в этом разделе (относительно использования EDNS (0) и TCP), наличие больших наборов записей (например, ЛЮБЫЕ запросы) не рекомендуется. В разделе 3.4 обсуждается проблема безопасности, связанная с перенаправлением, которая возникла в ряде протоколов (см. [HARD-ПРОБЛЕМА]).

В то время как DNSSEC, будучи развернутым повсеместно, может сыграть важную роль в обеспечении перенаправления приложений в DNS, DNSSEC не предоставляет средств для средства распознавания для аутентификации себя на сервере, а также не предоставляет платформу для серверов, чтобы возвращать выборочные ответы на основе аутентифицированных личность распознавателей, ни конфиденциальный механизм. Некоторые реализации могут поддерживать аутентификацию пользователей через TSIG, при условии, что сопоставление безопасности с совместимым сервером уже установлено, хотя аутентификация обычно не требуется для запросов в глобальной общедоступной DNS. Однако существующего набора функций DNSSEC достаточно для обеспечения безопасности для большинства способов, которыми приложения традиционно использовали DNS. Развертывание DNSSEC ([RFC4033] и связанных с ним спецификаций) от всей души приветствуется. Ничто в этом документе не предназначено для того, чтобы препятствовать внедрению, развертыванию или использованию динамических обновлений безопасного DNS [RFC3007], хотя в этом документе рекомендуется обрабатывать большие данные в DNS в соответствии с указаниями в разделе 3.2.1.

7. Члены IAB на момент утверждения

Членами Совета по архитектуре Интернета на момент утверждения этого документа были:

Bernard Aboba
Jari Arkko
Marc Blanchet
Ross Callon
Alissa Cooper
Spencer Dawkins
Joel Halpern
Russ Housley
David Kessens
Danny McPherson
Jon Peterson
Dave Thaler
Hannes Tschofenig

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

IAB ценит комментарии и часто энергичные разногласия Эрика Остервейла, Джона Левина, Стефана Борцмейера, Эда Льюиса, Дейва Крокера, Рэя Беллиса, Лоуренса Конроя, Ран Аткинсона, Патрика Фальтстрома и Элиота Лира.

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

[DNS-REDIRECT] Creighton, T., Griffiths, C., Livingood, J., and R. Weber, «DNS Redirect Use by Service Providers», Work in Progress, October 2010.

[EDNS-CLIENT-IP] Contavalli, C., van der Gaast, W., Leach, S., and D. Rodden, «Client IP information in DNS requests», Work in Progress, May 2010.

[EDNS-OPT-CODE] Kaplan, H., Walter, R., Gorman, P., and M. Maharishi, «EDNS Option Code for SIP and PSTN Source Reference Info», Work in Progress, October 2011.

[ENUM-Send-N] Bellis, R., «IANA Registrations for the ’Send-N’ Enumservice», Work in Progress, June 2008.

[ENUM-UNUSED] Stastny, R., Conroy, L., and J. Reid, «IANA Registration for Enumservice UNUSED», Work in Progress, March 2008.

[HARD-PROBLEM] Barnes, R. and P. Saint-Andre, «High Assurance Re-Direction (HARD) Problem Statement», Work in Progress, July 2010.

[Lindsay] Lindsay, G., «DNSSEC and DNS Amplification Attacks», April 2012.

[RFC0882] Mockapetris, P., «Domain names: Concepts and facilities», RFC 882, November 1983.

[RFC0883] Mockapetris, P., «Domain names: Implementation specification», RFC 883, November 1983.

[RFC0974] Partridge, C., «Mail routing and the domain system», STD 10, RFC 974, January 1986.

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, November 1987.

[RFC1464] Rosenbaum, R., «Using the Domain Name System To Store Arbitrary String Attributes», RFC 1464, May 1993.

[RFC1530] Malamud, C. and M. Rose, «Principles of Operation for the TPC.INT Subdomain: General Principles and Policy», RFC 1530, October 1993.

[RFC1794] Brisco, T., «DNS Support for Load Balancing», RFC 1794, April 1995.

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, «Address Allocation for Private Internets», BCP 5, RFC 1918, February 1996.

[RFC1995] Ohta, M., «Incremental Zone Transfer in DNS», RFC 1995, August 1996.

[RFC2052] Gulbrandsen, A. and P. Vixie, «A DNS RR for specifying the location of services (DNS SRV)», RFC 2052, October 1996.

[RFC2168] Daniel, R. and M. Mealling, «Resolution of Uniform Resource Identifiers using the Domain Name System», RFC 2168, June 1997.

[RFC2181] Elz, R. and R. Bush, «Clarifications to the DNS Specification», RFC 2181, July 1997.

[RFC2397] Masinter, L., «The «data» URL scheme», RFC 2397, August 1998.

[RFC2671] Vixie, P., «Extension Mechanisms for DNS (EDNS0)», RFC 2671, August 1999.

[RFC2818] Rescorla, E., «HTTP Over TLS», RFC 2818, May 2000.

[RFC2826] Internet Architecture Board, «IAB Technical Comment on the Unique DNS Root», RFC 2826, May 2000.

[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, «Secret Key Transaction Authentication for DNS (TSIG)», RFC 2845, May 2000.

[RFC2915] Mealling, M. and R. Daniel, «The Naming Authority Pointer (NAPTR) DNS Resource Record», RFC 2915, September 2000.

[RFC2916] Faltstrom, P., «E.164 number and DNS», RFC 2916, September 2000.

[RFC3007] Wellington, B., «Secure Domain Name System (DNS) Dynamic Update», RFC 3007, November 2000.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, «SIP: Session Initiation Protocol», RFC 3261, June 2002.

[RFC3263] Rosenberg, J. and H. Schulzrinne, «Session Initiation Protocol (SIP): Locating SIP Servers», RFC 3263, June 2002.

[RFC3401] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS», RFC 3401, October 2002.

[RFC3402] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm», RFC 3402, October 2002.

[RFC3403] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database», RFC 3403, October 2002.

[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, «DNS Extensions to Support IP Version 6», RFC 3596, October 2003.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, January 2005.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «DNS Security Introduction and Requirements», RFC 4033, March 2005.

[RFC4367] Rosenberg, J., Ed., and IAB, «What’s in a Name: False Assumptions about DNS Names», RFC 4367, February 2006.

[RFC4398] Josefsson, S., «Storing Certificates in the Domain Name System (DNS)», RFC 4398, March 2006.

[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, «Internet Denial-of-Service Considerations», RFC 4732, December 2006.

[RFC4985] Santesson, S., «Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name», RFC 4985, August 2007.

[RFC5486] Malas, D., Ed., and D. Meyer, Ed., «Session Peering for Multimedia Interconnect (SPEERMINT) Terminology», RFC 5486, March 2009.

[RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch, Ed., «Design Choices When Expanding the DNS», RFC 5507, April 2009.

[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, «Domain Certificates in the Session Initiation Protocol (SIP)», RFC 5922, June 2010.

[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, «IAB Thoughts on Encodings for Internationalized Domain Names», RFC 6055, February 2011.

[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, March 2011.

[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, «Issues with IP Address Sharing», RFC 6269, June 2011.

[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., «DomainKeys Identified Mail (DKIM) Signatures», RFC 6376, September 2011.

[RFC 6394] Barnes, R., «Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)», RFC 6394, October 2011.

[RFC 6763] Cheshire, S. and M. Krochmal, «DNS-Based Service Discovery», RFC 6763, February 2013.

[RFC6891] Damas, J., Graff, M., and P. Vixie, «Extension Mechanisms for DNS (EDNS(0))», STD 75, RFC 6891, April 2013.

[URI-RR] Faltstrom, P. and O. Kolkman, «The Uniform Resource Identifier (URI) DNS Resource Record», Work in Progress, July 2013.

Адрес автора

Jon Peterson
NeuStar, Inc.
EMail: jon.peterson@neustar.biz

Olaf Kolkman
NLnet Labs
EMail: olaf@nlnetlabs.nl

Hannes Tschofenig
Nokia Siemens Networks
EMail: Hannes.Tschofenig@gmx.net

Bernard Aboba
Skype
EMail: Bernard_aboba@hotmail.com
Peterson,