RFC 5507 | Выбор дизайна при расширении DNS

Аннотация

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

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

 

Оглавление

1. Введение
2. Фон
3. Механизмы расширения
3.1. Поместить селекторы в RDATA существующих типов записей ресурсов
3.2. Добавить префикс к имени владельца
3.3. Добавить суффикс к имени владельца
3.4. Добавить новый класс
3.5. Добавить новый тип записи ресурса
4. Границы зоны невидимы для приложений
5. Почему добавление нового типа записи ресурса является предпочтительным решением
6. Заключение и рекомендация
7. Создание нового типа записи ресурса
8. Вопросы безопасности
9. Благодарности
10. Члены IAB на момент написания этой статьи
11. Ссылки
11.1. Нормативные ссылки
11.2. Информационные ссылки
Адрес автора

 

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

Эта памятка содержит информацию для интернет-сообщества. Он не определяет интернет-стандарт любого вида. Распространение этой заметки не ограничено.

 

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

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

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

 

1. Введение

DNS хранит несколько категорий данных. Двумя наиболее часто используемыми категориями являются данные инфраструктуры для самой системы DNS (записи ресурсов NS и SOA) и данные, связанные с сопоставлениями между именами доменов и IP-адресами (записи ресурсов A, AAAA и PTR). Существуют и другие категории, некоторые из которых связаны с конкретными приложениями, такими как электронная почта (MX Resource Records), в то время как другие являются общими типами Resource Record Type, используемыми для передачи информации для нескольких протоколов (SRV и NAPTR Resource Records).

При хранении данных в DNS для нового приложения, цель должна состоять в том, чтобы хранить данные таким образом, чтобы приложение могло запрашивать данные, которые оно хочет, минимизируя как воздействие на существующие приложения, так и объем дополнительных данных, передаваемых в клиент. Это подразумевает, что необходимо сделать несколько вариантов дизайна, где наиболее важным является обеспечение того, чтобы точный выбор того, какие данные должны быть возвращены, уже был сделан в запросе. Запрос состоит из тройки: {Владелец (или имя), Класс записи ресурса, Тип записи ресурса}.

Исторически расширение DNS для хранения данных приложения, привязанных к имени домена, выполнялось по-разному в разное время. Записи ресурса MX были созданы как новый тип записи ресурса, специально предназначенный для поддержки электронной почты. Записи SRV — это общий тип, который использует схему префикса в сочетании с именем базового домена. Записи NAPTR добавляют данные выбора внутри RDATA. Ясно, что методы, используемые для добавления новых типов данных в DNS, были противоречивыми, и цель этого документа — попытаться прояснить последствия каждого из этих методов, как для приложений, которые их используют, так и для остальных DNS.

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

Еще одна общая проблема, которую необходимо учитывать, — это то, что должны описывать новые данные в DNS. В некоторых случаях это могут быть совершенно новые данные. В других случаях они могут быть метаданными, привязанными к данным, которые уже существуют в DNS. Примерами новых данных являются ключевая информация для протокола Secure SHell (SSH) и данные, используемые для аутентификации отправителя сообщений электронной почты (метаданные, связанные с записями ресурсов MX). Если новые данные привязаны к данным, которые уже существуют в DNS, следует проанализировать, является ли проблемой наличие (например) адресных записей и информации о ключах SSH в разных зонах DNS или если это бонус, и если проблема в том, должна ли спецификация требовать, чтобы все связанные данные находились в одной и той же зоне. Одно конкретное различие между наличием записей в одной и той же зоне или нет, связано с ведением записей. Если они находятся в одной зоне, один и тот же сопровождающий (с точки зрения DNS) управляет двумя записями. В частности, они должны быть подписаны одинаковыми ключами DNSSEC, если DNSSEC используется.

Этот документ не говорит о том, что следует хранить в DNS. В нем также не обсуждается, следует ли использовать DNS для обнаружения службы или DNS следует использовать для хранения данных, относящихся к услуге. В общем, DNS — это протокол, который, помимо хранения метаданных, который делает сам DNS функционирующим (NS, SOA, типы записей ресурсов DNSSEC и т. Д.), Содержит только ссылки на местоположения служб (SRV, NAPTR, A, запись ресурсов AAAA). Типы) — хотя есть исключения, такие как MX Resource Records.

 

2. Фон

См. RFC 5395 [RFC5395] для краткого описания структуры DNS-запросов. Читатели, интересующиеся полной историей, должны начать с базовой спецификации DNS в RFC 1035 [RFC1035] и продолжить с различными документами, которые обновляют, уточняют и расширяют базовую спецификацию.

При составлении DNS-запроса параметры, используемые протоколом, являются тройкой {владелец, класс, тип}. Говорят, что каждая запись ресурса, соответствующая такой тройке, принадлежит одному и тому же набору записей ресурса (RRSet), и весь RRSet всегда возвращается клиенту, который запрашивает его. Разделение RRSet является нарушением протокола (отправка частичного RRSet, а не усечение ответа DNS), поскольку это может привести к проблемам когерентности с механизмом кэширования DNS. См. Раздел 5 [RFC2181] для получения дополнительной информации.

Некоторые обсуждения вокруг расширений DNS включают аргументы относительно размера MTU. Обратите внимание, что большинство дискуссий о размере DNS и MTU касаются размера всего пакета DNS, а не размера одного RRSet.

Почти весь трафик DNS-запросов передается по UDP, где сообщение DNS должно помещаться в один пакет UDP. Ответные сообщения DNS почти всегда больше, чем сообщения DNS-запросов, поэтому проблемы с размером сообщений почти всегда касаются ответов, а не запросов. Базовая спецификация DNS ограничивает количество сообщений DNS по UDP до 512 октетов; EDNS0 [RFC2671] определяет механизм, с помощью которого клиент может сигнализировать о своей готовности получать более крупные ответы, но развертывание EDNS0 не является универсальным, отчасти из-за брандмауэров, которые блокируют фрагментированные пакеты UDP или EDNS0. Если ответное сообщение не помещается в один пакет, сервер имен возвращает усеченный ответ, после чего клиент может повторить попытку, используя TCP. DNS-запросы через TCP не подпадают под это ограничение длины, но TCP накладывает значительно большие накладные расходы на запросы на серверах имен, чем UDP. Также случается, что политики в развернутых брандмауэрах слишком часто таковы, что они блокируют DNS через TCP, поэтому использование TCP в действительности не может быть вариантом. Существуют также риски (хотя, возможно, небольшие), что изменение маршрутизации при открытом потоке TCP создает проблемы, когда DNS-серверы развертываются в среде anycast.

 

3. Механизмы расширения

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

3.1. Поместить селекторы в RDATA существующих типов записей ресурсов

Для данного имени запроса можно выбрать один RRSet (все записи ресурсов, совместно использующие одну и ту же {владелец, класс, тип}), совместно используемые несколькими приложениями, и чтобы разные приложения использовали селекторы в данных записи ресурса (RDATA) определить, какие записи предназначены для каких приложений. Этот тип механизма выбора обычно называют «подтипом», потому что он фактически создает подсистему дополнительного типа в пределах одного типа записи ресурса DNS.

Примеры подтипов включают в себя записи ресурсов NAPTR [RFC3761] и исходный тип записи ресурса DNSSEC KEY [RFC2535] (который позднее был обновлен RFC 3445 [RFC3445] и устарел в RFC 4033 [RFC4033], RFC 4034 [RFC4034] и RFC 4035 [RFC4035]).

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

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

 

3.2. Добавить префикс к имени владельца

Добавляя специфический для приложения префикс к имени домена, мы получаем другую тройку {owner, class, type} и, следовательно, другой RRSet. Одна проблема с добавлением префиксов связана с подстановочными знаками, особенно если есть записи типа:

*.example.com. IN MX 1 mail.example.com.

и кто-то хочет, чтобы записи были связаны с этими именами. Предположим, что один создает префикс «_mail». Тогда нужно было бы сказать что-то вроде:

_mail.*.example.com. IN X-FOO A B C D

но подстановочные знаки DNS работают только с «*» в качестве крайнего левого токена в имени домена (см. также RFC 4592 [RFC4592]).

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

Даже когда выбран определенный префикс, данные все равно должны храниться в каком-либо типе записи ресурса. Этот тип записи ресурса может быть либо новым типом записи ресурса, либо существующим типом записи ресурса, который имеет соответствующий формат для хранения данных. Также может понадобиться какой-то другой механизм выбора, например, возможность различать записи в RRSet, если они имеют одинаковый тип записи ресурса. По этой причине необходимо одновременно зарегистрировать уникальный префикс и определить, какой тип записи ресурса следует использовать для этой конкретной службы.

Если запись имеет какую-то связь с другой записью в зоне, тот факт, что две записи могут находиться в разных зонах, может повлиять на доверие, которое приложение имеет к записям. Например:

example.com. IN MX 10 mail.example.com.
_foo.example.com. IN X-BAR «metadata for the mail service»

В этом примере две записи могут находиться в двух разных зонах, и в результате могут администрироваться двумя разными организациями и подписываться двумя разными объектами при использовании DNSSEC. По этим двум причинам использование префикса в последнее время стало очень интересным решением для многих разработчиков протоколов. В некоторых случаях, например, идентифицированные почтовые подписи DomainKeys [RFC4871], использовались записи TXT. В других, таких как SRV, были добавлены совершенно новые типы записей ресурсов.

 

3.3. Добавить суффикс к имени владельца

Добавление суффикса к имени домена изменяет тройку {owner, class, type} и, следовательно, RRSet. В этом случае, поскольку имя запроса может быть точно настроено на требуемые данные, размер RRSet минимизируется. Проблема с добавлением суффикса заключается в том, что он создает параллельное дерево внутри класса IN. Кроме того, не существует технического механизма, обеспечивающего делегирование для «example.com» и «example.com._bar» одной и той же организации. Кроме того, данные, связанные с одним объектом, теперь будут храниться в двух разных зонах, таких как «example.com» и «example.com._bar», которые в зависимости от того, кто контролирует «_bar», могут создавать новую синхронизацию и авторизацию обновления проблемы.

Одним из способов решения административных проблем является использование типа записи ресурса DNAME, указанного в RFC 2672 [RFC2672].

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

В RFC 2163 [RFC2163] инфиксный токен вставляется непосредственно под доменом верхнего уровня (TLD), но результат эквивалентен добавлению суффикса к имени владельца (вместо создания TLD создается домен второго уровня) ,

 

3.4. Добавить новый класс

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

Тем не менее, теоретически можно использовать механизм классов DNS, чтобы различать разные виды данных. Однако, поскольку дерево делегирования DNS (представленное записями ресурсов NS) само по себе связано с конкретным классом, попытка разрешить запрос путем пересечения границы класса может привести к неожиданным результатам, поскольку нет гарантии, что серверы имен для зоны в новый класс будет таким же, как серверы имен в классе IN. Система MIT Hesiod [Dyer87] использовала такую ​​схему для хранения данных в классе HS, но только в очень небольшом масштабе (в пределах одного учреждения), и с административным указанием, требующим, чтобы деревья делегирования для деревьев IN и HS быть идентичными Использование класса HS для такого хранения нечувствительных данных со временем было заменено использованием облегченного протокола доступа к каталогам (LDAP) [RFC4511].

Даже при использовании другого класса данные все равно должны храниться в некотором типе записи ресурса, который имеет соответствующий формат.

 

3.5. Добавить новый тип записи ресурса

При добавлении нового типа записи ресурса в систему объекты в четырех разных ролях должны иметь возможность обрабатывать новый тип:

1. Должен быть способ вставить новые записи ресурсов в зону на главном главном сервере имен. Для некоторых реализаций сервера пользовательский интерфейс принимает только те типы записей ресурсов, которые он понимает (возможно, чтобы реализация могла попытаться проверить данные). Другие реализации позволяют администратору зоны вводить целое число для кода типа записи ресурса и RDATA в Base64 или шестнадцатеричном кодировании (или даже в виде необработанных данных). RFC 3597 [RFC3597] определяет стандартное универсальное кодирование для этой цели.

2. Подчиненный полномочный сервер имен должен иметь возможность выполнять передачу зоны, получать данные от какого-либо другого полномочного сервера имен и обслуживать данные из зоны, даже если в зону входят записи неизвестных типов записей ресурсов. Исторически в некоторых реализациях возникали проблемы с анализом сохраненных копий файла зоны после перезапуска, но эти проблемы не наблюдались в течение нескольких лет. Некоторые реализации используют альтернативный механизм (например, LDAP) для передачи записей ресурсов в зоне и в основном используются в корпоративных средах; в этом случае серверы имен должны иметь возможность передавать новые типы записей ресурсов с использованием любого используемого механизма. Однако сегодня этот альтернативный механизм может не поддерживать неизвестные типы записей ресурсов. Следовательно, в интернет-средах поддерживаются неизвестные типы записей ресурсов, но в корпоративных средах они проблематичны.

3. Средство кэширования (чаще всего рекурсивный сервер имен) будет кэшировать записи, являющиеся ответами на запросы. Как упомянуто в RFC 3597 [RFC3597], существуют различные ловушки, из-за которых у рекурсивного сервера имен могут возникнуть проблемы.

4. Приложение должно иметь возможность получить RRSet с новым типом записи ресурса. Само приложение может понимать RDATA, а библиотека распознавателя — нет. Поддержка универсального интерфейса для получения произвольных типов записей ресурсов DNS требовалась с 1989 года (см. Раздел 6.1.4.2 [RFC1123]). Некоторые реализации библиотеки преобразователей-заглушек пренебрегают предоставлением этой функциональности и не могут обрабатывать неизвестные типы записей ресурсов, но реализация новой библиотеки-преобразователей заготовок не представляет особой сложности, и библиотеки с открытым исходным кодом, которые уже предоставляют эту функцию, доступны.

Исторически, добавление нового типа записи ресурса было очень проблематичным. Процесс проверки был громоздким, DNS-серверы не смогли обработать новые типы записей ресурсов, а брандмауэры отбросили запросы или ответы с типами записей ресурсов, которые не известны брандмауэру. Это, например, одна из причин, по которой стандарт ENUM повторно использует запись ресурса NAPTR, решение, которое сегодня могло бы пойти на создание нового типа записи ресурса.

Сегодня существует требование, чтобы программное обеспечение DNS обрабатывало неизвестные типы записей ресурсов, и исследования показали, что развертываемое программное обеспечение в целом поддерживает его, за исключением некоторых альтернативных механизмов передачи записей ресурсов, таких как LDAP, как отмечено выше. Кроме того, был обновлен процесс утверждения новых типов записей ресурсов [RFC5395], поэтому усилия, необходимые для различных типов записей ресурсов, более предсказуемы.

 

4. Границы зоны невидимы для приложений

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

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

Ложное предположение привело к подходу, называемому «лазание по дереву», когда запрос, который не получает положительного ответа (либо запрошенный RRSet отсутствует, либо имя не существует), повторяется путем многократного удаления самой левой метки (подъем к корень), пока не будет достигнут корневой домен. Иногда в этих предложениях делается попытка избежать запроса для корневого уровня или уровня TLD, но все же этот подход имеет серьезные недостатки:

• Технически DNS был построен как инструмент запроса-ответа без каких-либо возможностей поиска [RFC3467]. Добавление механизма поиска налагает дополнительную нагрузку на техническую инфраструктуру, в худшем случае на TLD и корневые серверы имен.
• По причинам, аналогичным изложенным в RFC 1535 [RFC1535], запрос информации в домене, находящемся вне контроля предполагаемого объекта, может привести к неверным результатам, а также может поставить под угрозу безопасность. Найти точную границу политики невозможно без явного маркера, которого в настоящее время не существует. В лучшем случае программное обеспечение может обнаруживать границы зон (например, путем поиска записей ресурсов SOA), но некоторые реестры TLD регистрируют имена, начиная со второго уровня (например, CO.UK), и в секунду существуют различные другие типы «реестра», домены третьего или другого уровня, которые нельзя идентифицировать как таковые без знания политики, внешней по отношению к DNS.

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

 

5. Почему добавление нового типа записи ресурса является предпочтительным решением

К настоящему времени проницательный читатель может задаться вопросом, какие выводы можно сделать из представленных вопросов. Теперь мы попытаемся прояснить путаницу читателя, следуя мыслительным процессам типичного дизайнера приложений, который хочет хранить данные в DNS. Мы покажем, как такой разработчик почти неизбежно сталкивается с идеей простого использования TXT Resource Record, почему это плохо и почему вместо этого должен быть назначен новый тип записи ресурса. Мы также объясним, как повторное использование существующей записи ресурса, включая TXT, можно сделать менее вредным.

Общая проблема большинства решений связана с двумя основными проблемами:

• Нет семантики, чтобы предотвратить столкновение с другим использованием
• Космические соображения в сообщении DNS

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

Как объяснено в разделе 3.4, использование системы классов DNS в качестве механизма расширения на самом деле не вариант, и фактически большинство пользователей системы даже не осознают, что механизм существует. На практике, поэтому любое расширение, вероятно, будет в пределах класса IN.

Добавление нового типа записи ресурса является технически правильным ответом с точки зрения протокола DNS (подробнее об этом ниже), но это требует определенных знаний DNS из-за проблем, перечисленных в разделе 3.5. Следовательно, этот вариант часто отклоняется. Обратите внимание, что в соответствии с RFC 5395 [RFC5395], некоторые типы требуют согласия IETF, а другие требуют только спецификации.

Есть недостаток в определении новых типов RR, о котором стоит упомянуть. Тип записи ресурса (RRTYPE) является 16-битным значением и, следовательно, является ограниченным ресурсом. Во избежание накопления реестра существует политика распределения на основе обзора [RFC5395]; однако этого может быть недостаточно, если расширение DNS путем добавления новых типов RR занимает много времени, а реестр начинает приближаться к завершению. В этом случае компромисс в отношении выбора механизма расширения может потребоваться изменить.

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

Например, тип записи ресурса 40 был зарегистрирован для типа записи ресурса SINK. Этот тип записи ресурса обсуждался в рабочей группе DNSIND IETF, и на 46-й IETF было принято решение не продвигать ID вперед, чтобы он стал RFC из-за риска поощрения разработчиков приложений использовать тип записи ресурса SINK вместо регистрация нового типа записи ресурса, что привело бы к неимоверно большим наборам SINK RR.

Устранение всего вышеперечисленного оставляет тип записи ресурса TXT в классе IN. Формат TXT RDATA представляет собой текст в свободной форме, и в нем нет существующей семантики. Некоторые попытки были сделаны, например, в [DNSEXT-DNS-SD], чтобы указать структурированный формат для типов записей ресурсов TXT, но ни одна такая попытка не достигла статуса RFC. Кроме того, TXT Resource Record, очевидно, может просто использоваться в качестве блока для переноса данных, которые будут использоваться неким высокоуровневым синтаксическим анализатором, возможно, в некотором читаемом человеком языке программирования или разметке. Таким образом, для многих приложений записи ресурсов TXT являются «очевидным» выбором. К сожалению, этот вывод, хотя и понятен, также проблематичен по нескольким причинам.

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

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

Это даже хуже, чем общая проблема с подтипами, описанная в Разделе 3.1, потому что у TXT Resource Records нет даже стандартного поля селектора для хранения подтипа. RFC 1464 [RFC1464] попытался, но не увенчался успехом. В лучшем случае определение подтипа сводится к надежде на то, что какая бы схема ни была разработана, случайно не вступит в конфликт с чужой схемой подтипов, и что будет невозможно неправильно проанализировать использование приложением записей ресурсов TXT в качестве данных. предназначен для другого применения. Любая попытка навязать стандартизированный формат в формате TXT Resource Record будет запоздалой, по крайней мере, на пятнадцать лет, даже если он вступит в силу немедленно; в лучшем случае можно ограничить синтаксис, который конкретное приложение использует в записи ресурса TXT, и принять на себя риск того, что несвязанная запись ресурса TXT столкнется с ним.

Использование одной из модификаций именования, обсужденных в Разделе 3.2 и Разделе 3.3, решило бы проблему подтипирования (и использовалось в комбинации с повторным использованием записи TXT, например, для механизма поиска dns / txt в Почте с ключами домена (DKIM)) но каждый из этих подходов порождает новые проблемы. Префиксный подход (который, например, используют записи ресурсов SRV) не очень хорошо работает с подстановочными знаками, что является особой проблемой для приложений, связанных с почтой, поскольку записи ресурсов MX, вероятно, являются наиболее распространенным использованием подстановочных знаков DNS. Подход суффикса не имеет проблем с подстановочными знаками, но, как отмечалось ранее, у него есть проблемы с синхронизацией и обновлением авторизации, поскольку он работает путем создания второго поддерева в другой части глобального пространства имен DNS.

Следующая причина, по которой записи ресурсов TXT плохо подходят для использования протокола, связана с ограниченным пространством данных, доступным в сообщении DNS. Как кратко упоминалось в разделе 3.1, типичные шаблоны трафика DNS-запросов включают в себя очень большое количество DNS-клиентов, отправляющих запросы на относительно небольшое количество DNS-серверов. Схемы обнаружения MTU в обычном тракте здесь мало полезны, потому что, с точки зрения сервера, не хватает повторного трафика от какого-либо одного клиента, чтобы он стоил сохранения состояния. DNS на основе UDP является идемпотентным запросом, тогда как DNS на основе TCP требует, чтобы сервер сохранял состояние (в форме состояния соединения TCP, обычно в ядре сервера), и примерно в три раза увеличивает нагрузку на трафик. Таким образом, существует сильный стимул, чтобы сообщения DNS были достаточно короткими, чтобы помещаться в дейтаграмму UDP, предпочтительно дейтаграмму UDP, достаточно короткую, чтобы не требовала фрагментации IP.

Схемы подтипов, следовательно, опять-таки проблематичны, потому что они производят RRSets ресурсов большего размера, чем это необходимо, но подробные текстовые кодировки данных также расточительны, поскольку данные, которые они хранят, обычно могут быть более компактно представлены в Resource Record, разработанной специально для поддержки конкретных потребностей данных в приложении. Если данные, которые необходимо перенести, настолько велики, что невозможно удобно разместить их в DNS независимо от кодировки, вероятно, лучше переместить данные в другое место и просто использовать DNS в качестве указателя на данные. , как с NAPTR.

 

6. Заключение и рекомендация

Учитывая проблемы, подробно описанные в разделе 5, стоит пересмотреть часто приходящий к выводу, что указывать новый тип записи ресурса сложно. Исторически это действительно имело место, но недавние опросы показывают, что поддержка неизвестных типов записей ресурсов [RFC3597] сейчас широко распространена в общедоступном Интернете, и поэтому инфраструктура DNS может обрабатывать новые типы записей ресурсов. Отсутствие поддержки для неизвестных типов остается проблемой для относительно старого программного обеспечения обеспечения и в корпоративных средах.

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

Учитывая различные проблемы, описанные в этой заметке, мы считаем, что:

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

 

7. Создание нового типа записи ресурса

Процесс создания нового типа записи ресурса указан в RFC 5395 [RFC5395].

 

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

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

Добавление новых типов записей ресурсов (как описано в разделе 3.5) может создать два разных типа проблем: в программном обеспечении DNS и в приложениях. В программном обеспечении DNS оно может вызывать ошибки и другое плохое поведение в программном обеспечении, не совместимом с RFC 3597 [RFC3597], но большинство такого программного обеспечения DNS достаточно старое и небезопасное, чтобы его можно было обновить по другим причинам в любом случае. В приложениях и программном обеспечении могут быть обновлены изменения для новых функций, которым нужны новые данные в DNS, чтобы понять структуру нового формата данных (независимо от того, используется ли новый тип записи ресурса или выбран какой-либо другой механизм) , Базовая поддержка API для получения произвольных типов записей ресурсов требовалась с 1989 года [RFC1123].

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

 

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

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

Помогли следующие люди: Дин Андерсон, Марк Эндрюс, Джон Анжельмо, Рой Бадами, Дэн Бернштейн, Алекс Блай, Натаниэль Боренштейн, Стефан Борцмейер, Брайан Карпентер, Лесли Дейгл, Элвин Дэвис, Марк Делани, Ричард Дрейвс, Мартин Дуерст, Дональд Истлэйк Роберт Элз, Джим Фентон, Тони Финч, Джим Гилрой, Олафур Гудмундссон, Эрик Холл, Филипп Хэллам-Бейкер, Тед Харди, Боб Хинден, Пол Хоффман, Джефф Хьюстон, Кристиан Уитема, Йохан Ирен, Джон Кленсин, Бен Лори, Уильям Лейбзон Джон Левин, Эдвард Льюис, Дэвид МакКуигг, Эллисон Манкин, Билл Маннинг, Дэвид Мейер, Пекка Никандер, Манс Нильссон, Масатака Охта, Дуглас Отис, Майкл Паттон, Джонатан Розенберг, Андерс Рундгрен, Мириам Сапиро, Карстен Штротманн, Пекка Савола, Чек Шарп, Джеймс Снелл, Майкл Томас, Пол Викси, Сэм Вейлер, Флориан Ваймер, Берт Вийнен и Дэн Винг.

10. Члены IAB на момент написания этой статьи

Loa Andersson
Gonzalo Camarillo
Stuart Cheshire
Russ Housley
Olaf Kolkman
Gregory Lebovitz
Barry Leiba
Kurtis Lindqvist
Andrew Malis
Danny McPherson
David Oran
Dave Thaler
Lixia Zhang

11. Ссылки

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

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

[RFC2535] Eastlake, D., «Domain Name System Security Extensions», RFC 2535, March 1999.

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

[RFC3597] Gustafsson, A., «Handling of Unknown DNS Resource Record (RR) Types», RFC 3597, September 2003.

[RFC5395] Eastlake, D., «Domain Name System (DNS) IANA Considerations», BCP 42, RFC 5395, November 2008.

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

[DNSEXT-DNS-SD] Cheshire, S. and M. Krochmal, «DNS-Based Service Discovery», Work in Progress, September 2008.

[Dyer87] Dyer, S. and F. Hsu, «Hesiod, Project Athena Technical Plan — Name Service», Version 1.9, April 1987.

[RFC1123] Braden, R., «Requirements for Internet Hosts — Application and Support», STD 3, RFC 1123, October 1989.

[RFC1535] Gavron, E., «A Security Problem and Proposed Correction With Widely Deployed DNS Software», RFC 1535, October 1993.

[RFC2163] Allocchio, C., «Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM)», RFC 2163, January 1998.

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

[RFC2672] Crawford, M., «Non-Terminal DNS Name Redirection», RFC 2672, August 1999.

[RFC3445] Massey, D. and S. Rose, «Limiting the Scope of the KEY Resource Record (RR)», RFC 3445, December 2002.

[RFC3467] Klensin, J., «Role of the Domain Name System (DNS)», RFC 3467, February 2003.

[RFC3761] Faltstrom, P. and M. Mealling, «The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)», RFC 3761, April 2004.

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

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Resource Records for the DNS Security Extensions», RFC 4034, March 2005.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Protocol Modifications for the DNS Security Extensions», RFC 4035, March 2005.

[RFC4511] Sermersheim, J., «Lightweight Directory Access Protocol (LDAP): The Protocol», RFC 4511, June 2006.

[RFC4592] Lewis, E., «The Role of Wildcards in the Domain Name System», RFC 4592, July 2006.

[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, «DomainKeys Identified Mail (DKIM) Signatures», RFC 4871, May 2007.

Адрес автора

Internet Architecture Board
EMail: iab@iab.org

Patrik Faltstrom (editor)
EMail: paf@cisco.com

Rob Austein (editor)
EMail: sra@isc.org

Peter Koch (editor)
EMail: pk@denic.de