Internet Engineering Task Force (IETF) D. Crocker Request for Comments: 8552 Brandenburg InternetWorking BCP: 222 March 2019 Category: Best Current Practice ISSN: 2070-1721
Scoped Interpretation of DNS Resource Records through “Underscored” Naming of Attribute Leaves
Интерпретация записей DNS по именам ветвей с символом подчёркивания
Аннотация
Формально любая запись о ресурсах DNS (Resource Record или RR) может присутствовать в любом доменном имени. Однако некоторые службы применяют рабочие соглашения, задающие конкретную интерпретацию RRset путём размещения записей в ветви DNS конкретного родительского домена, к котором RRset относится фактически. Вершина такой подчинённой ветви определяется соглашением об именовании, использующим зарезервированное имя узла, начинающееся с символа подчёркивания (например, _name). Именование с подчёркиванием определяет семантическую область для типов записей DNS, которые связаны с родительским доменом ветви с символом подчёркивания. В этой спецификации исследуется природа такого использования DNS и задан реестр IANA Underscored and Globally Scoped DNS Node Names, предназначенный для предотвращения конфликтов совпадающих имён для разных служб.
Статус документа
Документ относится к категории Internet Best Current Practice.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о документах BCP можно найти в разделе 2 в RFC 7841.
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8552.
Авторские права
Авторские права (Copyright (c) 2019) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).
1. Введение
Основные технические спецификации системы доменных имён (Domain Name System или DNS) [RFC1035] и [RFC2181] не задают семантику доменных имён и их частей, а также не устанавливают ограничений для типов записей о ресурсах (RR), которые разрешается хранит для конкретных имён [RFC1035] [RFC2181]. С течением времени некоторые имена узлов, такие как www и ftp, стали означать поддержку конкретных услуг, но это скорее вопрос рабочих соглашений, чем семантики протокола. Такая свобода базовой технологии позволила параллельно использовать широкий спектр административных и семантических правил. Семантика данных DNS была ограничена спецификациями отдельных типов записей о ресурсах в расчёте на добавление новых типов записей при необходимости. К сожалению, добавление новых типов записей оказалось чрезвычайно сложной задачей и за время использования DNS возникли существенные препятствия внедрению и использованию новых типов записей.
1.1. Область действия по символу подчёркивания
В качестве альтернативы определению нового типа RR в некоторых усовершенствованиях службы DNS предусмотрено использование имеющегося типа записей о ресурсах с заданием ограничений на область его действия. Область действия является статическим свойством, не зависящим от природы запроса. Это артефакт имени DNS. Такая область является листовым узлом, содержащим конкретные наборы записей о ресурсах, которые формально определены и ограничены.
Лист размещается в ветви, имеющие отличительное соглашение об именовании, имеется родительское доменное имя, к которому относятся данные. Ветвь размещается под этим именем. Субветвь указывается одним или несколькими зарезервированными именами узлов DNS и по меньшей мере первое (старшее) из этих имён начинается с символа подчёркивания (например, _name).
Поскольку правила DNS для имён хостов (host) не позволяют использовать символ подчёркивания, имя с таким символом будет отличаться от всех разрешённых имён хостов [RFC0952]. Фактически такое соглашение об именовании создаёт пространство для перечисления «атрибутов» (в форме типов записей о ресурсах), связанных с родительским доменом выше субветви с подчёркиванием.
Указание области действия особенно полезно при использовании обобщённых типов записей о ресурсах, в частности, TXT, SRV и URI [RFC1035] [RFC2782] [RFC6335] [RFC7553]. Это обеспечивает эффективное разделение вариантов применения. При отсутствии такого разделения клиенту DNS возвращается большое число недифференцированных Rrset, которые должны анализироваться в поиске имеющих отношение к делу. Результаты в некоторых случаях могут быть неоднозначными, поскольку тип записи может не указывать адекватно своё конкретное назначение. При ограничении по символам подчёркивания будут возвращаться только имеющие отношение к делу RRset.
Простым примером является почта, указываемая ключами домена (DomainKeys Identified Mail или DKIM) [RFC6376], где используется _domainkey для указания места хранения записи TXT с подписанной информацией для родительского домена.
Эта спецификация формально определяет использование имён с символом подчёркивания в качестве «атрибутивного» расширения для имён родительских доменов. Например, доменное имя _domainkey.example. выступает как атрибут родительского домена «example.». Для предотвращения конфликтов, возникающих из-за применения одинаковых имён с символом подчёркивания для разных приложений, использующих один тип записей о ресурсах, данный документ организует реестр Underscored and Globally Scoped DNS Node Names в IANA. Использование имён узлов, начинающихся с символа подчёркивания, зарезервировано, если они являются ближайшими к корню DNS (в этом случае они считаются «глобальными»). Имена с символом подчёркивания, расположенные в иерархии дальше, обрабатываются в рамках глобального имени узла с символом подчёркивания.
Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.
1.2. Улучшение расширяемости
Некоторые типы записей о ресурсах применяются так, что могут возникать проблемы расширяемости (масштабирования), если весь набор RRset, связанный с доменным именем, агрегируется в листовом узле для этого имени. Все более популярным подходом с отличной расширяемостью является размещение RRset в специально поименованной ветви, которая находится в иерархии под именем узла, где в ином случае содержался бы RRset. Правила именования таких ветвей определяют контекст для интерпретации RRset. Иными словами, вместо
domain-name.example
/
RRset
применяется
_branch.domain-name.example
/
RRset
Прямой поиск в подчинённом листовом узле даёт лишь нужные типы записей, причём не дороже, чем обычный поиск DNS.
1.3. Глобальные имена узлов с символом подчёркивания
Как определено в [RFC1034], DNS использует имена, организованные в иерархическое дерево. Доменное имя может включать несколько имён узлов, начинающихся с символа подчёркивания (например, _name). Глобальное имя узла с символом подчёркивания является ближайшим к корню иерархии DNS и называется также верхним (highest level или topmost). В представлении, описанном в параграфе 3.1 [RFC1034], это будет самое правое имя метки.
В иных представлениях имя может размещаться иначе, поэтому для однозначности понимания здесь применяется термин «глобальное имя».
1.4. Взаимодействие с шаблонами DNS
Шаблоны (wildcard) DNS плохо взаимодействую с именами с символом подчёркивания по двум причинам.
Поскольку шаблоны интерпретируются лишь как имена листьев, невозможно создать эквивалент шаблонного имени для имён с префиксом. Такие имена, как label.*.example.com не являются шаблонами.
И наоборот, такой шаблон как *.example.com может соответствовать любому имени, включая имена с символом подчёркивания. В результате по шаблону будут возвращаться записи с типом, контролируемым именем с символом подчёркивания, но не предназначенным для контекста с подчёркиванием и не соответствующим его правилам.
1.5. История
Исходно варианты применения имён с символом подчёркивания в основно разрабатывались несогласованно. Для записей TXT нет согласованного внутреннего синтаксиса, позволяющего различать варианты применения. В случае SRV RR и URI RR различение типов было частью решения (см. [RFC2782] и [RFC7553]). Спецификации SRV и URI служат шаблонами, задающими RR, которые можно применять лишь в конкретных приложениях, имеющих дополнительные спецификации. Определение шаблона включает ссылку на два уровня таблиц имён, из которых следует брать имена с подчёркиванием. Нижний уровень (локальное действие) набора имён _service определён через другие таблицы IANA, а именно, таблицы с символьными именами. Верхний уровень (глобальное действие) поля именования SRV – это _proto, хотя его набор имён явно не задан.
Совокупным результатом независимых усилий стал длинный список имён с символом подчёркивания, которые были зарезервированы без координации, что может приводить к конфликтам при назначении имён. Исправить ситуацию можно с помощью данного документа и [RFC8553], где определён реестр таких имён и предпринята попытка зарегистрировать все уже используемые имена, а также направить изменения в имеющиеся спецификации, использующие глобальные имена узлов с символом подчёркивания.
2. Реестр Underscored and Globally Scoped DNS Node Names
Здесь определён реестр глобальных имён узлов DNS, начинающихся с символа подчёркивания. Цель реестра Underscored and Globally Scoped DNS Node Names состоит в предотвращении конфликтов в результате использования одного имени с символом подчёркивания для разных приложений.
Если публично доступная спецификация требует использования имени узла с символом подчёркивания, глобальное (ближайшее к корню DNS) имя с подчёркиванием должно включаться в этот реестр.
Имя с символом подчёркивания задаёт область применения конкретных типов записей о ресурсах, связанных с доменным именем, которое является родителем для ветви, определяемой именем с символом подчёркивания. Данное имя определяет конкретный, ограниченный контекст для одного или нескольких RR TYPE, где применение таких типов записей соответствует заданным ограничениям.
-
Внутри листа с областью действия, заданной подчёркиванием, можно применять другие RRset, не указанные как часть области действия.
Структурно реестр определяется как одна плоская таблица RR TYPE под именами узлов, начинающимися с символа подчёркивания. В некоторых случаях, таких как использование записи SRV, полное имя области действия может состоять из нескольких частей (последовательность имён с подчёркиванием). Семантически такая последовательность представляет иерархическую модель и теоретически разумно разрешить повторное использование подчинённого имени с символом подчёркивания в другом глобальном контексте с подчёркиванием, т. е. подчинённое имя будет значимым только в области действия глобального имени узла с подчёркиванием. Поэтому такие имена не включаются в реестр Underscored and Globally Scoped DNS Node Names, который предназначен для регистрации лишь имён верхнего уровня с символом подчёркивания (глобальных).
Таблица . Примеры имён с символом подчёркивания.
|
Имя |
|---|
|
_service1 |
|
_protoB._service2 |
|
_protoB._service3 |
|
_protoC._service3 |
|
_useX._protoD._service4 |
|
_protoE._region._authority |
В реестре Underscored and Globally Scoped DNS Node Names регистрируются только глобальные имена с символом подчёркивания. В приведённом выше примере это будут имена _service1, _service2, _service3, _service 4, и _authority.
-
Применение имён узлов с подчёркиванием специфично для каждого RR TYPE, область действия которого ограничивается. Каждое имя определяет место, но не задаёт правил для того, что размещается ниже этого места в виде дополнительного именования с символом подчёркивания или или листа с записями о ресурсах. Детали таких правил определяются спецификациями конкретных RR TYPE. В приведённых ниже разделах описаны способы использования имеющихся имён с подчёркиванием с именуемыми ими RR TYPE.
-
За определение и регистрацию подчинённых имён с подчёркиванием отвечает спецификация, создавшая глобальный узел с символом подчёркивания в имени в записи реестра.
Если схема, использующая глобальный узел с подчёркиванием в имени, имеет 1 или несколько подчинённых уровней именования узлов с символом подчёркивания, пространства имён, из которых выбираются имена для нижележащих уровней, контролируются родительским именем с символом подчёркивания. Каждое зарегистрированное глобальное имя с подчёркиванием владеет своим подчиненным пространством имён.
3. Рекомендации по регистрации использования RRset
В этом разделе содержится руководство для разработчиков спецификаций и базовый шаблон, который они могут применять для регистрации новых записей в реестре Underscored and Globally Scoped DNS Node Names. Приведённый ниже текст может добавляться в спецификации, использующие уже зарегистрированные комбинации RR TYPE и _NODE NAME.
В соответствии с RFC 8552 добавьте показанную ниже запись в реестр Underscored and Globally Scoped DNS Node Names.
Таблица . Шаблон для записей реестра Underscored and Globally Scoped DNS Node Names.
|
Тип RR |
Имя _узла |
Документ |
|---|---|---|
|
* |
_example |
параграф 4.1.4 |
4. Взаимодействие с IANA
Агентство IANA организовало реестр Underscored and Globally Scoped DNS Node Names. В этом разделе описан сам реестр, определения, исходные записи, использование of_ta и _example, а также применение [RFC8126] как руководства для рецензирования экспертами. Агентство IANA добавило в реестр Enumservices Registrations ссылку на этот документ.
4.1. Реестр Underscored and Globally Scoped DNS Node Names
Реестр Underscored and Globally Scoped DNS Node Names включает все имена узлов DNS, начинающиеся с символа подчёркивания (_, ASCII 0x5F) и являющиеся ближайшими к корню, т. е. определяющими верхний уровень ветви DNS ниже уровня «родительского» доменного имени.
-
Для этого реестра применяются правила IANA Expert Review, см. параграф 4.1.5.
-
Содержимое каждой записи реестра определено в параграфе 4.1.1.
-
Каждая запись реестра должна включать значения всех полей, указанных в параграфе 4.1.1.
-
Внутри реестра комбинация RR Type и _NODE NAME должна быть уникальной.
-
Поля таблицы сортируются первому столбцу (RR Type), а при совпадении значений в нем – по второму (_NODE NAME).
-
Ссылка (Reference) в каждой записи должна иметь стабильную привязку к организации, контролирующей запись реестра.
4.1.1. Содержимое записи Underscored and Globally Scoped DNS Node Names
Поля записи реестра указаны ниже.
RR Type – тип RR
Значение RR TYPE, определённое для использования в данной области действия._NODE NAME – имя _узла
Одно имя с символом подчёркивания, определяющее зарезервированное имя. Это имя является глобальным для области действия типа записи о ресурсах, связанных с этим именем. Символы имён должны указываться в нижнем регистре (строчные буквы) для упрощения процедуры сравнения.Reference – документ
Указывает спецификацию, определяющую тип записи и её использовании с данным _Node Name. Организация, выпустившая спецификацию, сохраняет контроль над записью реестра для _Node Name.Каждый тип RR, используемый с _Node Name, должен иметь отдельную запись в реестре.
4.1.2. Исходные имена узлов
Исходные записи реестра приведены в таблице .
Таблица . Исходное содержимое реестра Underscored and Globally Scoped DNS Node Names.
|
Тип RR |
Имя _узла |
Документ |
|---|---|---|
|
* |
_example |
параграф 4.1.4 |
|
NULL |
_ta-* {параграф 4.1.3} |
[RFC8145] |
|
OPENPGPKEY |
_openpgpkey |
[RFC7929] |
|
SMIMEA |
_smimecert |
[RFC8162] |
|
SRV |
_dccp |
[RFC2782] |
|
SRV |
_http |
[RFC4386] |
|
SRV |
_ipv6 |
[RFC5026] |
|
SRV |
_ldap |
[RFC4386] |
|
SRV |
_ocsp |
[RFC4386] |
|
SRV |
_sctp |
[RFC2782] |
|
SRV |
_sip |
[RFC5509] |
|
SRV |
_tcp |
[RFC2782] |
|
SRV |
_udp |
[RFC2782] |
|
SRV |
_xmpp |
[RFC3921] |
|
TLSA |
_dane |
[RFC7671] |
|
TLSA |
_sctp |
[RFC6698] |
|
TLSA |
_tcp |
[RFC6698] |
|
TLSA |
_udp |
[RFC6698] |
|
TXT |
_acme-challenge |
[RFC8555] |
|
TXT |
_dmarc |
[RFC7489] |
|
TXT |
_domainkey |
[RFC6376] |
|
TXT |
_mta-sts |
[RFC8461] |
|
TXT |
_spf |
[RFC7208] |
|
TXT |
_sztp |
[ZEROTOUCH] |
|
TXT |
_tcp |
[RFC6763] |
|
TXT |
_udp |
[RFC6763] |
|
TXT |
_vouch |
[RFC5518] |
|
URI |
_acct |
[RFC6118] |
|
URI |
_dccp |
[RFC7566] |
|
URI |
_email |
[RFC6118] |
|
URI |
_ems |
[RFC6118] |
|
URI |
_fax |
[RFC6118] |
|
URI |
_ft |
[RFC6118] |
|
URI |
_h323 |
[RFC6118] |
|
URI |
_iax |
[RFC6118] |
|
URI |
_ical-access |
[RFC6118] |
|
URI |
_ical-sched |
[RFC6118] |
|
URI |
_ifax |
[RFC6118] |
|
URI |
_im |
[RFC6118] |
|
URI |
_mms |
[RFC6118] |
|
URI |
_pres |
[RFC6118] |
|
URI |
_pstn |
[RFC6118] |
|
URI |
_sctp |
[RFC6118] |
|
URI |
_sip |
[RFC6118] |
|
URI |
_sms |
[RFC6118] |
|
URI |
_tcp |
[RFC6118] |
|
URI |
_udp |
[RFC6118] |
|
URI |
_unifmsg |
[RFC6118] |
|
URI |
_vcard |
[RFC6118] |
|
URI |
_videomsg |
[RFC6118] |
|
URI |
_voice |
[RFC6118] |
|
URI |
_voicemsg |
[RFC6118] |
|
URI |
_vpim |
[RFC6118] |
|
URI |
_web |
[RFC6118] |
|
URI |
_xmpp |
[RFC6118] |
4.1.3. _ta
Для NULL RR Type запись _ta-* указывает все имена узлов, начинающиеся с _ta-*. Это не является спецификацией шаблона DNS.
4.1.4. _example
Имя узла _example зарезервировано для всех RRset.
4.1.5. Рекомендации для рецензентов (Expert Review)
В этом параграфе даны рекомендации для экспертов, рецензирующих запросы на регистрацию в реестре Underscored and Globally Scoped DNS Node Names.
Рецензирование выполняется исключительно для определения адекватности запрошенной записи реестра и не включает другие аспекты задающего запись документа. Например, такой документ может также включать определения типа записи о ресурсах, на который ссылается запрошенная запись. Рецензирование таких определений выполняется отдельно от рецензирования, требуемого здесь.
Рецензирование выполняется для того, чтобы убедиться в том, что запись реестра:
-
достаточно ясна, точна и полна;
-
комбинация имени с символом подчёркивания, под которым используется указанный тип записей о ресурсах, и самого типа записи является уникальной в реестре.
При рецензировании другие аспекты технического качества спецификации, её адекватности и т. п. не учитываются.
4.2. Реестр Enumservices Registrations
В реестр Enumservice Registrations добавлено приведённое ниже замечание.
При добавлении записи в этот реестр следует внимательно рассмотреть также вопрос добавления записи в реестр Underscored and Globally Scoped DNS Node Names.
5. Вопросы безопасности
Этот документ не создаёт проблем безопасности.
6. Литература
6.1. Нормативные документы
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, “DoD Internet host table specification”, RFC 952, DOI 10.17487/RFC0952, October 1985, <https://www.rfc-editor.org/info/rfc952>.
[RFC1034] Mockapetris, P., “Domain names – concepts and facilities”, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., “Domain names – implementation and specification”, STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2181] Elz, R. and R. Bush, “Clarifications to the DNS Specification”, RFC 2181, DOI 10.17487/RFC2181, July 1997, <https://www.rfc-editor.org/info/rfc2181>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV)”, RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>.
[RFC3921] Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence”, RFC 3921, DOI 10.17487/RFC3921, October 2004, <https://www.rfc-editor.org/info/rfc3921>.
[RFC4386] Boeyen, S. and P. Hallam-Baker, “Internet X.509 Public Key Infrastructure Repository Locator Service”, RFC 4386, DOI 10.17487/RFC4386, February 2006, <https://www.rfc-editor.org/info/rfc4386>.
[RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed., “Mobile IPv6 Bootstrapping in Split Scenario”, RFC 5026, DOI 10.17487/RFC5026, October 2007, <https://www.rfc-editor.org/info/rfc5026>.
[RFC5509] Loreto, S., “Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV Rrs for the Session Initiation Protocol (SIP)”, RFC 5509, DOI 10.17487/RFC5509, April 2009, <https://www.rfc-editor.org/info/rfc5509>.
[RFC5518] Hoffman, P., Levine, J., and A. Hathcock, “Vouch By Reference”, RFC 5518, DOI 10.17487/RFC5518, April 2009, <https://www.rfc-editor.org/info/rfc5518>.
[RFC6118] Hoeneisen, B. and A. Mayrhofer, “Update of Legacy IANA Registrations of Enumservices”, RFC 6118, DOI 10.17487/RFC6118, March 2011, <https://www.rfc-editor.org/info/rfc6118>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, “Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry”, BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., “DomainKeys Identified Mail (DKIM) Signatures”, STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/info/rfc6376>.
[RFC6698] Hoffman, P. and J. Schlyter, “The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA”, RFC 6698, DOI 10.17487/RFC6698, August 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6763] Cheshire, S. and M. Krochmal, “DNS-Based Service Discovery”, RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.
[RFC7208] Kitterman, S., “Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1”, RFC 7208, DOI 10.17487/RFC7208, April 2014, <https://www.rfc-editor.org/info/rfc7208>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., “Domain-based Message Authentication, Reporting, and Conformance (DMARC)”, RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/info/rfc7489>.
[RFC7553] Faltstrom, P. and O. Kolkman, “The Uniform Resource Identifier (URI) DNS Resource Record”, RFC 7553, DOI 10.17487/RFC7553, June 2015, <https://www.rfc-editor.org/info/rfc7553>.
[RFC7566] Goix, L. and K. Li, “Enumservice Registration for ‘acct’ URI”, RFC 7566, DOI 10.17487/RFC7566, June 2015, <https://www.rfc-editor.org/info/rfc7566>.
[RFC7671] Dukhovni, V. and W. Hardaker, “The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance”, RFC 7671, DOI 10.17487/RFC7671, October 2015, <https://www.rfc-editor.org/info/rfc7671>.
[RFC7929] Wouters, P., “DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP”, RFC 7929, DOI 10.17487/RFC7929, August 2016, <https://www.rfc-editor.org/info/rfc7929>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8145] Wessels, D., Kumari, W., and P. Hoffman, “Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)”, RFC 8145, DOI 10.17487/RFC8145, April 2017, <https://www.rfc-editor.org/info/rfc8145>.
[RFC8162] Hoffman, P. and J. Schlyter, “Using Secure DNS to Associate Certificates with Domain Names for S/MIME”, RFC 8162, DOI 10.17487/RFC8162, May 2017, <https://www.rfc-editor.org/info/rfc8162>.
[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., and J. Jones, “SMTP MTA Strict Transport Security (MTA-STS)”, RFC 8461, DOI 10.17487/RFC8461, September 2018, <https://www.rfc-editor.org/info/rfc8461>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, “Automatic Certificate Management Environment (ACME)”, RFC 8555, DOI 10.17487/RFC8555, March 2019, <https://www.rfc-editor.org/info/rfc8555>.
6.2. Дополнительная литература
[RFC8553] Crocker, D., “DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names”, RFC 8553, DOI 10.17487/RFC8553, March 2019, <https://www.rfc-editor.org/info/rfc8553>.
[ZEROTOUCH] Watsen, K., Abrahamsson, M., and I. Farrer, “Secure Zero Touch Provisioning (SZTP)”, Work in Progress3, draft-ietf-netconf-zerotouch-29, January 2019.
Благодарности
Спасибо Bill Fenner, Dick Franks, Tony Hansen, Martin Hoffmann, Paul Hoffman, Peter Koch, Olaf Kolkman, Murray Kucherawy, John Levine, Benno Overeinder, Andrew Sullivan за добросовестный обзор ранних черновых версий. За последующие улучшения спасибо Stephane Bortzmeyer, Alissa Cooper, Bob Harold, Joel Jaeggli, Benjamin Kaduk, Mirja Kuehlewind, Warren Kumari, John Levine, Benno Overeinder, Eric Rescorla, Adam Roach, Petr Spacek, Ondrej Sury, Paul Vixie, Tim Wicinski, Paul Wouters.
Отдельная благодарность Ray Bellis за настойчивую поддержку продолжения работы, а также за предложение существенно упростить модель регистрации.
Адрес автора
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 United States of America Phone: +1.408.246.8253 Email: dcrocker@bbiw.net URI: http://bbiw.net/Перевод на русский язык
1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.
2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.