Internet Engineering Task Force (IETF) D. Crocker
Request for Comments: 8553 Brandenburg InternetWorking
BCP: 222 March 2019
Updates: 2782, 3263, 3529, 3620, 3832,
3887, 3958, 4120, 4227, 4386,
4387, 4976, 5026, 5328, 5389,
5415, 5518, 5555, 5617, 5679,
5766, 5780, 5804, 5864, 5928,
6120, 6186, 6376, 6733, 6763,
7208, 7489, 8145
Category: Best Current Practice
ISSN: 2070-1721
DNS AttrLeaf Changes: Fixing Specifications That Use Underscored Node Names
Изменения DNS AttrLeaf в спецификациях с именами узлов с подчёркиванием
Аннотация
Использование символа подчёркивания для префикса создаёт пространство ограниченной интерпретации записей о ресурсах. Исходно применение символа подчёркивания в качестве префикса доменного имени было определено без реестра IANA. Это привело к несогласованным действиям по созданию имён, выведенных из одного пространства имён. Реестр для имён с подчёркиванием определён в RFC 8552 и имеющиеся спецификации с использованием имён с символом подчёркивания требуется изменить в соответствии с новым реестром. Этот документ задаёт такие изменения. Эти изменения позволяют сохранить имеющиеся программы и эксплуатационную практику, адаптируя спецификации к новой модели с реестром имён с символом подчёркивания.
Статус документа
Документ относится к категории Internet Best Current Practice.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о документах BCP можно найти в разделе 2 в RFC 7841.
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc8553.
Авторские права
Авторские права (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. Введение
Исходно применение символа подчёркивания в качестве префикса доменного имени [RFC1035], создающего пространство ограниченной интерпретации записей о ресурсах было определено без реестра IANA [IANA-reg]. Это привело к несогласованным действиям по созданию имён, выведенных из одного пространства имён. Реестр таких имён сейчас определён (раздел 4 в [RFC8552]) и рассмотрены основы применения имён с символом подчёркивания [RFC8552].
Базовая модель регистрации имён с символом подчёркивания, как указано в [RFC8552], состоит в том, что каждая запись уникальна как комбинация типа записи и «глобального» (верхнего уровня) имени узла с символом подчёркивания, т. е. ближайшего в корню DNS имени с символом подчеркивания.
Спецификации, описывающие существующее использование имён с подчёркиванием, не отражают наличие этого интегрированного реестра. Для нового читателя или нового редактора такого документа в настоящее время ничто не указывает на обработку имён с символом подчёркивания, определённых в этом документе, через реестр IANA. Данный документ исправляет ситуацию, внося в соответствующие опубликованные документы обновлений, указывающих характер изменений.
Кроме того, документы, определяющие записи о ресурсах DNS SRV [RFC2782] и URI [RFC7553] DNS, содержат меташаблоны для назначения имён с подчёркиванием, частично основанные на отдельных реестрах [RFC6335]. Для той части, которая определяет глобальное (верхнего уровня) имя узла с подчёркиванием, это закрепляет несогласованное именование с символом подчёркивания отдельными спецификациями из того же пространства имён. Данный документ устраняет это, предоставляя детальный пересмотр спецификация SRV и URI для приведения их в соответствие с единым интегрированным реестром Underscored and Globally Scoped DNS Node Names.
В результате этих изменений сохраняются имеющиеся программы и эксплуатационная практика, а технические спецификации приспосабливаются к новой модели реестра имён с символом подчеркивания.
Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.
2. Использование RRset с подчёркиванием в спецификациях
Использование имён с символом подчёркивания специфично для каждого RR TYPE с определённой областью действия. Каждое имя задаёт место, но не определяет правил для присутствия под этой точкой в виде дополнительного именования с подчёркиванием или узла-листа с записями о ресурсах. Детали таких правил задают спецификации отдельных RR TYPE. В последующих параграфах описано, как имена с символом подчёркивания используются с типами RR, которые они именуют.
2.1. TXT RRset
Примечание. Документы этой категории включают [RFC5518], [RFC5617], [RFC6120], [RFC6376], [RFC6763], [RFC7208], [RFC7489].
В этом параграфе представлен базовый подход к внесению изменений в имеющиеся спецификации, определяющие прямое использование имён с символом подчёркивания при определении области действия TXT RRset. Представлены сведения, требуемые для приспособления таких спецификаций в использованию реестра IANA Underscored and Globally Scoped DNS Node Names [RFC8552]. Таким образом, этот подход означает как обновление имеющихся спецификаций, так и рекомендации по внесению изменений при пересмотре документов.
Для любого документа, задающего использование TXT RRset под одним или несколькими именами с подчёркиванием, глобальное имя узла предполагается зарегистрированным в реестре IANA Underscored and Globally Scoped DNS Node Names [RFC8552]. Предпринята попытка найти имеющиеся документы, в которых это сделано, зарегистрировать глобальные имена с символом подчёркивания и указать их в исходном списке имён, включённых в реестр.
Для публичных спецификаций, определяющих применение TXT RRset и использующих имя с символом подчёркивания, ниже приведён шаблон текста, который может быть включён в раздел «Взаимодействие с IANA (IANA Considerations).
В соответствии с [RFC8552], пожалуйста добавьте приведённую ниже запись в реестр Underscored and Globally Scoped DNS Node Names.
Таблица . Запись реестра Underscored and Globally Scoped DNS Node Names для TXT RR.
|
Тип RR |
_Имя узла |
Документ |
|---|---|---|
|
TXT |
_{имя узла DNS} |
{ссылка на документ с дополнением} |
2.2. SRV RRset
Примечание. Документы этой категории включают [RFC3263], [RFC3529], [RFC3620], [RFC3832], [RFC3887], [RFC3958], [RFC4120], [RFC4227], [RFC4386], [RFC4387], [RFC4976], [RFC5026], [RFC5328], [RFC5389], [RFC5415], [RFC5555], [RFC5679], [RFC5766], [RFC5780], [RFC5804], [RFC5864], [RFC5928], [RFC6186].
В спецификации записи SRV [RFC2782] задан шаблон для использования имён с символом подчёркивания. Глобальное имя характеризуется как ссылка на protocol, связанный с использованием SRV RRset.
В этом параграфе представлен базовый подход к внесению изменений в имеющиеся спецификации, определяющие использование SRV RRset. Представлены сведения, требуемые для приспособления таких спецификаций в использованию реестра IANA Underscored and Globally Scoped DNS Node Names [RFC8552]. Таким образом, этот подход означает как обновление имеющихся спецификаций, так и рекомендации по внесению изменений при пересмотре документов.
Для любого документа, задающего использование SRV RRset, глобальное (protocol) имя узла с символом подчёркивания предполагается зарегистрированным в реестре IANA Underscored and Globally Scoped DNS Node Names [RFC8552]. Предпринята попытка найти имеющиеся документы, в которых это сделано, зарегистрировать глобальные имена с символом подчёркивания и указать их в исходном списке имён, включённых в реестр.
Для публичных спецификаций, определяющих применение SRV RRset и использующих имя с символом подчёркивания, ниже приведён шаблон текста для регистрации глобальных имён (ближайших к корню) с подчёркиванием, который может быть включён в раздел «Взаимодействие с IANA (IANA Considerations).
В соответствии с [RFC8552], пожалуйста добавьте приведённую ниже запись в реестр Underscored and Globally Scoped DNS Node Names.
Таблица . Запись реестра Underscored and Globally Scoped DNS Node Names для SRV RR.
|
Тип RR |
_Имя узла |
Документ |
|---|---|---|
|
SRV |
_{имя узла DNS protocol} |
{ссылка на документ с дополнением} |
2.3. URI RRset
В спецификации записи URI [RFC7553] задан шаблон для использования имён с символом подчёркивания. Глобальное имя характеризуется как именование протокола (protocol), связанного с применением URI RR, или обращение последовательности Enumservice [RFC6117].
В этом параграфе представлен базовый подход к внесению изменений в имеющиеся спецификации, определяющие использование URI RRset. Представлены сведения, требуемые для приспособления таких спецификаций в использованию реестра IANA Underscored and Globally Scoped DNS Node Names [RFC8552]. Таким образом, этот подход означает как обновление имеющихся спецификаций, так и рекомендации по внесению изменений при пересмотре документов.
Для любого документа, задающего использование URI RRset, глобальное (protocol или Enumservice верхнего уровня) имя узла с символом подчёркивания предполагается зарегистрированным в реестре IANA Underscored and Globally Scoped DNS Node Names [RFC8552]. Предпринята попытка найти имеющиеся документы, в которых это сделано, зарегистрировать глобальные имена с символом подчёркивания и указать их в исходном списке имён, включённых в реестр.
Для публичных спецификаций, определяющих применение URI RRset и использующих имя с символом подчёркивания, ниже приведён шаблон текста для регистрации глобальных имён (ближайших к корню) с подчёркиванием, который может быть включён в раздел «Взаимодействие с IANA (IANA Considerations).
В соответствии с [RFC8552], пожалуйста добавьте приведённую ниже запись в реестр Underscored and Globally Scoped DNS Node Names.
Таблица . Запись реестра Underscored and Globally Scoped DNS Node Names для URI RR.
|
Тип RR |
_Имя узла |
Документ |
|---|---|---|
|
URI |
_{имя узла DNS protocol или Enumservice} |
{ссылка на документ с дополнением} |
3. Спецификации шаблонов с символом подчёркивания
3.1. Изменение спецификации SRV
Спецификация доменного имени, под которым появляется запись SRV [RFC2782], включает шаблон использования имён с символом подчёркивания. Глобальное имя с подчёркиванием характеризуется как указывающее протокол, связанный с использованием SRV RR.
В текст [RFC2782] внесены показанные ниже обновления. Следует также отметить, что добавлена нормативная ссылка на RFC 8552 в раздел «Литература» RFC 2782.
Прежнее
Формат SRV RR.
Ниже представлен формат SRV RR, имеющей код типа DNS 33.
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
…
Proto
Символьное имя желаемого протокола с символом подчёркивания (_) в начале для предотвращения конфликтов с встречающимися на практике метками DNS. Наиболее полезными значениями поля являются в настоящее время _TCP и _UDP, хотя можно использовать любое имя, указанное в Assigned Numbers или применяемое локально (для служб). Регистр символов в Proto не учитывается.Новое
Формат SRV RR.
Ниже представлен формат SRV RR, имеющей код типа DNS 33.
“_Service._Proto.Name TTL Class SRV Priority Weight Port Target”
_…_
Proto
Символьное имя желаемого протокола с символом подчёркивания в начале (например, _name) в начале для предотвращения конфликтов с встречающимися на практике метками DNS. Наиболее полезными значениями поля являются в настоящее время _TCP и _UDP. Регистр символов в Proto не учитывается. Имя SRV RRset protocol (глобальное) с символом подчёркивания следует регистрировать в реестре IANA Underscored and Globally Scoped DNS Node Names [RFC8552].3.2. Изменение спецификации URI
Спецификация доменного имени ( под которым появляется запись URI [RFC7553]) похожа на спецификацию SRV [RFC2782], хотя в тексте упоминается лишь имя service, а не отличие service от protocol. Кроме того, спецификация URI RR допускает варианты схемы именования с символом подчёркивания:
одна схема соответствует применяемой для SRV с глобальным именем узла с подчёркиванием protocol;
другая схема основана на обращении последовательности Enumservice [RFC6117].
Текст [RFC7553] изменён, как показано ниже. Кроме того, добавлена нормативная ссылка на RFC 8552 в раздел «Литература» RFC 7553.
Прежнее
4.1. Имя, класс и тип владельца
Имя владельца URI подчиняется специальным соглашениям. Подобно SRV RR [RFC2782], в URI RR имеются сведения о службе, указанные в имени владельца. Для кодирования службы в конкретном имени владельца применяются параметры службы. Допускаются параметры, зарегистрированные в реестре IANA Service Name and Transport Protocol Port Number Registry [RFC6335] или в качестве Enumservice [RFC6117]. Порядок параметров Enumservice Registration меняется на обратный (субтипы перед типом) с добавлением в начало символа подчёркивания (_) и размещением перед именем владельца в отдельных метках. Символ подчёркивания добавляется перед параметрами службы для предотвращения конфликтов с встречающимися на практике метками DNS и порядок меняется на обратный, чтобы при необходимости можно было передавать полномочия различным зонам (и, следовательно, провайдерам DNS).
Предположим, например, что выполняется поиск URI службы с ENUM Service Parameter “A:B:C” для хоста example.com. Запрос будет иметь вид (QNAME,QTYPE)=(“_C._B._A.example.com”,”URI”). В качестве другого примера рассмотрим поиск URI службы с Service Name “A” и Transport Protocol “B” для хоста example.com. Запрос будет иметь вид (QNAME,QTYPE)=(“_A._B.example.com”,”URI”).
Новое
4.1. Имя, класс и тип владельца
Имя владельца URI подчиняется специальным соглашениям. Подобно SRV RRset [RFC2782], глобальное (верхнего уровня) имя URI RRset с символом подчёркивания следует регистрировать в реестре IANA Underscored and Globally Scoped DNS Node Names [RFC8552].
Подобно SRV RRset, в URI RRset имеются сведения о службе, указанные в имени владельца. Допустимые параметры служб указаны ниже.
-
Параметры, зарегистрированные в реестре IANA Service Name and Transport Protocol Port Number Registry [RFC6335]. Символ подчёркивания добавляется перед параметрами службы для предотвращения конфликтов с встречающимися на практике метками DNS и порядок меняется на обратный, чтобы при необходимости можно было передавать полномочия различным зонам (и, следовательно, провайдерам DNS).
-
Параметры, зарегистрированные в Enumservice Registrations [RFC6117]. Порядок параметров Enumservice Registration меняется на обратный (субтипы перед типом) с добавлением в начало символа подчёркивания (_) и размещением перед именем владельца в отдельных метках. Имя Enumservice верхнего уровня (глобальное) становится глобальным именем для регистрации в соответствии с RFC 8552.
Предположим, например, что выполняется поиск URI службы с ENUM Service Parameter “A:B:C” для хоста example.com. Запрос будет иметь вид (QNAME,QTYPE)=(“_C._B._A.example.com”,”URI”). В качестве другого примера рассмотрим поиск URI службы с Service Name “A” и Transport Protocol “B” для хоста example.com. Запрос будет иметь вид (QNAME,QTYPE)=(“_A._B.example.com”,”URI”).
3.3. Изменение спецификации DNSSEC Signaling
В Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) [RFC8145] определено использование имён узлов DNS, фактически разрешающее все имена, начинающиеся с _ta-, при использовании в запросе NULL RR.
Текст параграфа 5.1 (Формат запроса) в RFC 8145 изменяется, как указано ниже. Кроме того, добавлена нормативная ссылка на RFC 8552 в раздел «Литература» RFC 8145.
Прежнее
Например, проверяющий распознаватель DNS …
QNAME=_ta-4444.
Новое
Например, проверяющий распознаватель DNS … “QNAME=_ta-4444”.
Для NULL RR в реестре IANA Underscored and Globally Scoped DNS Node Names [RFC8552] зарегистрирована запись для всех узлов, имена которых начинаются с _ta-.
4. Взаимодействие с IANA
Хотя этот документ упоминает реестры IANA, он не задаёт новых реестров и процедур.
5. Вопросы безопасности
Этот документ не создаёт проблем безопасности.
6. Литература
6.1. Нормативные документы
[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>.
[RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, “IANA Registration of Enumservices: Guide, Template, and IANA Considerations”, RFC 6117, DOI 10.17487/RFC6117, March 2011, <https://www.rfc-editor.org/info/rfc6117>.
[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>.
[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>.
[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>.
[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>.
[RFC8552] Crocker, D., “Scoped Interpretation of DNS Resource Records through “Underscored” Naming of Attribute Leaves”, RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/info/rfc8552>.
6.2. Дополнительная литература
[IANA-reg] IANA, “Protocol Registries”, <https://www.iana.org/protocols>.
[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>.
[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>.
[RFC3263] Rosenberg, J. and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers”, RFC 3263, DOI 10.17487/RFC3263, June 2002, <https://www.rfc-editor.org/info/rfc3263>.
[RFC3529] Harold, W., “Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP)”, RFC 3529, DOI 10.17487/RFC3529, April 2003, <https://www.rfc-editor.org/info/rfc3529>.
[RFC3620] New, D., “The TUNNEL Profile”, RFC 3620, DOI 10.17487/RFC3620, October 2003, <https://www.rfc-editor.org/info/rfc3620>.
[RFC3832] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C., and W. Jerome, “Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV”, RFC 3832, DOI 10.17487/RFC3832, July 2004, <https://www.rfc-editor.org/info/rfc3832>.
[RFC3887] Hansen, T., “Message Tracking Query Protocol”, RFC 3887, DOI 10.17487/RFC3887, September 2004, <https://www.rfc-editor.org/info/rfc3887>.
[RFC3958] Daigle, L. and A. Newton, “Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)”, RFC 3958, DOI 10.17487/RFC3958, January 2005, <https://www.rfc-editor.org/info/rfc3958>.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, “The Kerberos Network Authentication Service (V5)”, RFC 4120, DOI 10.17487/RFC4120, July 2005, <https://www.rfc-editor.org/info/rfc4120>.
[RFC4227] O’Tuathail, E. and M. Rose, “Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)”, RFC 4227, DOI 10.17487/RFC4227, January 2006, <https://www.rfc-editor.org/info/rfc4227>.
[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>.
[RFC4387] Gutmann, P., Ed., “Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP”, RFC 4387, DOI 10.17487/RFC4387, February 2006, <https://www.rfc-editor.org/info/rfc4387>.
[RFC4976] Jennings, C., Mahy, R., and A. Roach, “Relay Extensions for the Message Sessions Relay Protocol (MSRP)”, RFC 4976, DOI 10.17487/RFC4976, September 2007, <https://www.rfc-editor.org/info/rfc4976>.
[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>.
[RFC5328] Adolf, A. and P. MacAvock, “A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB)”, RFC 5328, DOI 10.17487/RFC5328, September 2008, <https://www.rfc-editor.org/info/rfc5328>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for NAT (STUN)”, RFC 5389, DOI 10.17487/RFC5389, October 2008, <https://www.rfc-editor.org/info/rfc5389>.
[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., “Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification”, RFC 5415, DOI 10.17487/RFC5415, March 2009, <https://www.rfc-editor.org/info/rfc5415>.
[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>.
[RFC5555] Soliman, H., Ed., “Mobile IPv6 Support for Dual Stack Hosts and Routers”, RFC 5555, DOI 10.17487/RFC5555, June 2009, <https://www.rfc-editor.org/info/rfc5555>.
[RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)”, RFC 5617, DOI 10.17487/RFC5617, August 2009, <https://www.rfc-editor.org/info/rfc5617>.
[RFC5679] Bajko, G., “Locating IEEE 802.21 Mobility Services ping DNS”, RFC 5679, DOI 10.17487/RFC5679, December 2009, <https://www.rfc-editor.org/info/rfc5679>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, “Traversal ping Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)”, RFC 5766, DOI 10.17487/RFC5766, April 2010, <https://www.rfc-editor.org/info/rfc5766>.
[RFC5780] MacDonald, D. and B. Lowekamp, “NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)”, RFC 5780, DOI 10.17487/RFC5780, May 2010, <https://www.rfc-editor.org/info/rfc5780>.
[RFC5804] Melnikov, A., Ed. and T. Martin, “A Protocol for Remotely Managing Sieve Scripts”, RFC 5804, DOI 10.17487/RFC5804, July 2010, <https://www.rfc-editor.org/info/rfc5804>.
[RFC5864] Allbery, R., “DNS SRV Resource Records for AFS”, RFC 5864, DOI 10.17487/RFC5864, April 2010, <https://www.rfc-editor.org/info/rfc5864>.
[RFC5928] Petit-Huguenin, M., “Traversal Using Relays around NAT (TURN) Resolution Mechanism”, RFC 5928, DOI 10.17487/RFC5928, August 2010, <https://www.rfc-editor.org/info/rfc5928>.
[RFC6120] Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core”, RFC 6120, DOI 10.17487/RFC6120, March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC6186] Daboo, C., “Use of SRV Records for Locating Email Submission/Access Services”, RFC 6186, DOI 10.17487/RFC6186, March 2011, <https://www.rfc-editor.org/info/rfc6186>.
[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>.
[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>.
Благодарности
Спасибо Bill Fenner, Dick Franks, Tony Hansen, Peter Koch, Olaf Kolkman, Andrew Sullivan за тщательное рецензирование (первоначальных) черновых версий. За последующие улучшения спасибо Tim Wicinski, John Levine, Bob Harold, Joel Jaeggli, Ondrej Sury, 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.