RFC 4027 Domain Name System Media Types

Network Working Group                                       S. Josefsson
Request for Comments: 4027                                    April 2005
Category: Informational

Domain Name System Media Types

Типы носителей DNS

PDF

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

В этом документе представлена информация для сообщества Internet. Документ не содержит каких-либо стандартов Internet. Допускается свободное распространение документа.

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

Аннотация

Документ регистрирует типы application/dns и text/dns в соответствии с RFC 2048. Тип application/dns используется для идентификации обособленного формата DNS (detached Domain Name System), описанного в RFC 2540. Тип text/dns служит для идентификации master-файлов, описанных в RFC 1035.

1. Введение

Информация системы доменных имён (DNS) [1] традиционно хранится в текстовых файлах, которые обычно называют master-файлами или файлами зон. Формат таких файлов описан в главе 5 RFC 1035 [2].

Данные DNS хранят также в обособленном (detached) формате, предназначенном для архивирования и описанном в RFC 2540 [4].

В этом документе регистрируются типы сред MIME для двух форматов данных в соответствии с процедурой регистрации, описанной в RFC 2048 [3].

2. Регистрация типа MIME application/dns

Кому: ietf-types@iana.org

Тема: регистрация типа MIME application/dns

Название типа MIME: application

Имя подтипа MIME: dns

Требуемые параметры: нет

Дополнительные параметры: нет

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

Вопросы безопасности: Этот тип идентифицирует содержимое, являющееся обособленной информацией DNS, описанной в RFC 2540 [4]. Эти данные могут иметь отношение к безопасности (RFC 2538 [7]) или быть защищёнными (RFC 2535 [6]). Защита содержимого может обеспечиваться с помощью стандартных методов, таких, как OpenPGP [5] или CMS [9], но этот вопрос выходит за пределы данного документа. Другие оценки безопасности здесь неприменимы.

Вопросы функциональной совместимости: Представление обособленной информации DNS является, в отличии от текстовых master-файлов, хорошо определенным. Других проблем функциональной совместимости неизвестно.

Опубликованная спецификация: Формат данных, которые могут помечаться этим типом, описан в RFC 2540 [4].

Приложения, использующие этот тип: Связанные с DNS программы, включая программы хранения и использования сертификатов, сохранённых в DNS.

Дополнительная информация:

Магический номер: нет

Расширение файлов: неизвестно

Код типа файлов Macintosh: неизвестен

Контактная информация:

Simon Josefsson simon@josefsson.org

Предполагаемое применение: Ограниченное использование

Автор/редактор изменений: simon@josefsson.org

3. Регистрация типа MIME text/dns

Кому: ietf-types@iana.org

Тема: регистрация типа MIME text/dns

Название типа MIME: text

Имя подтипа MIME: dns

Требуемые параметры: нет

Дополнительные параметры: нет

Представление:: Данные являются текстовыми и их следует передавать в ориентированном на работу со строками режиме. Текстовые литералы могут содержать последовательности CRLF внутри текста. Бинарный режим передачи возможен между системами, поддерживающими однотипный режим завершения строк. Master-файлы в основном используют кодировку ASCII, но могут включать и отличные от ASCII октеты, которые трактуются программами DNS как прозрачные значения (сравните с главой 5 RFC 1035). Формат master-файла разрешает представление произвольных октетов с использованием кодирования “\DDD”. Использование этого кодирования может оказаться более надёжным, нежели передача отличных от ASCII символов с использованием MIME, если данные передаются через шлюзы, которые декодируют и заново кодируют символьные данные.

Вопросы безопасности: Этот тип идентифицирует содержимое, которое представляет собой информацию DNS в формате master-файла, описанном в 1035 [2]. Данные могут иметь отношение к безопасности (RFC 2538 [7]) или быть защищёнными (RFC 2535 [6]). Защита содержимого может обеспечиваться с помощью стандартных методов, таких, как OpenPGP [5] или CMS [9], но этот вопрос выходит за пределы данного документа. Другие оценки безопасности здесь неприменимы.

Вопросы функциональной совместимости: Для master-файлов существуют проблемы функциональной совместимости, связанные с широким спектром расширений, используемых разными производителями. Комментарии в отличной от ASCII кодировке в master-файлах могут использовать локально выбранные наборы символов, передача которых с сохранением функциональной совместимости может оказаться затруднительной. Отличные от ASCII данные в общем случае могут повреждаться на шлюзах, выполняющих декодирование и повторное кодирование. Для обеспечения функциональной совместимости можно использовать формат master-файлов, описанных в спецификации, и кодирование “\DDD” для отличных от ASCII октетов. Другая проблема функциональной совместимости связана с существованием неизвестных типов RR, которые могут обрабатываться в соответствии с рекомендациями главы 5 RFC 3597 [8].

Опубликованная спецификация: Формат данных, которые могут помечаться этим типом, описан в RFC 1035 [2].

Дополнительная информация:

Магический номер: нет

Расширение файлов: известны расширения ‘soa’ и ‘zone’.

Код типа файлов Macintosh: неизвестен

Контактная информация:

Simon Josefsson simon@josefsson.org

Предполагаемое применение: Ограниченное использование

Автор/редактор изменений: simon@josefsson.org

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

Вопросы безопасности рассматриваются в соответствующих разделах регистрации MIME в параграфах 2 и 3.

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

Агентство IANA зарегистрировало типы MIME application/dns и text/dns с использованием регистрационных шаблонов, приведённых в параграфах 2 и 3, в соответствии с процедурой, описанной в RFC 2048 [3].

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

Спасибо D. Eastlake за предложения по типу text/dns. Спасибо Keith Moore и Alfred Hoenes за просмотр документа. Автор выражает свою признательность лаборатории RSA за поддержку работы, которая привела к созданию этого документа.

A. Отказ от претензий и разрешение на использование

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

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

[1] Mockapetris, P., “Domain names – concepts and facilities”, STD 13, RFC 1034, November 1987.

[2] Mockapetris, P., “Domain names – implementation and specification”, STD 13, RFC 1035, November 1987.

[3] Freed, N., Klensin, J., and J. Postel, “Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures”, BCP 13, RFC 2048, November 1996.

[4] Eastlake 3rd, D., “Detached Domain Name System (DNS) Information”, RFC 2540, March 1999.

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

[5] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, “OpenPGP Message Format”, RFC 2440, November 1998.

[6] Eastlake 3rd, D., “Domain Name System Security Extensions”, RFC 2535, March 1999.

[7] Eastlake 3rd, D. and O. Gudmundsson, “Storing Certificates in the Domain Name System (DNS)”, RFC 2538, March 1999.

[8] Gustafsson, A., “Handling of Unknown DNS Resource Record (RR) Types”, RFC 3597, September 2003.

[9] Housley, R., “Cryptographic Message Syntax (CMS)”, RFC 3852, July 2004.

Адрес автора

Simon Josefsson

EMail: simon@josefsson.org

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

Николай Малых

nmalykh@protokols.ru

Полное заявление авторских прав

К этому документу применимы права, лицензии и ограничения, описанные в BCP 78, и авторы сохраняют все свои права, за исключением явно указанных далее.

Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

Интеллектуальная собственность

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

Подтвеждение

Финансирование функций RFC Editor в настоящее время обеспечивается Internet Society.