From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8553.txt | 843 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 843 insertions(+) create mode 100644 doc/rfc/rfc8553.txt (limited to 'doc/rfc/rfc8553.txt') diff --git a/doc/rfc/rfc8553.txt b/doc/rfc/rfc8553.txt new file mode 100644 index 0000000..ca7b110 --- /dev/null +++ b/doc/rfc/rfc8553.txt @@ -0,0 +1,843 @@ + + + + + + +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 + +Abstract + + Using an underscore for a prefix creates a space for constrained + interoperation of resource records. Original uses of an underscore + character as a domain node name prefix were specified without the + benefit of an IANA registry. This produced an entirely uncoordinated + set of name-creation activities, all drawing from the same namespace. + A registry for these names has now been defined by RFC 8552. + However, the existing specifications that use underscored naming need + to be modified in order to be in line with the new registry. This + document specifies those changes. The changes preserve existing + software and operational practice, while adapting the specifications + for those practices to the newer underscore registry model. + +Status of This Memo + + This memo documents an Internet Best Current Practice. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + BCPs is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8553. + + + + + + + +Crocker Best Current Practice [Page 1] + +RFC 8553 DNS AttrLeaf Fix March 2019 + + +Copyright Notice + + Copyright (c) 2019 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Underscored RRset Use in Specifications . . . . . . . . . . . 3 + 2.1. TXT RRset . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. SRV RRset . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.3. URI RRset . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3. Underscored Template Specifications . . . . . . . . . . . . . 7 + 3.1. SRV Specification Changes . . . . . . . . . . . . . . . . 7 + 3.2. URI Specification Changes . . . . . . . . . . . . . . . . 8 + 3.3. DNSSEC Signaling Specification Changes . . . . . . . . . 10 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 6.2. Informative References . . . . . . . . . . . . . . . . . 12 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 + +1. Introduction + + Original uses of an underscore character as a domain node name + [RFC1035] prefix, which creates a space for constrained + interpretation of resource records, were specified without the + benefit of an IANA registry [IANA-reg]. This produced an entirely + uncoordinated set of name-creation activities, all drawing from the + same namespace. A registry has now been defined (see Section 4 of + [RFC8552]); the RFC that defined it discusses the background for the + use of underscored domain names [RFC8552]. + + + + + + + +Crocker Best Current Practice [Page 2] + +RFC 8553 DNS AttrLeaf Fix March 2019 + + + The basic model for underscored name registration, as specified in + [RFC8552], is to have each registry entry be unique in terms of the + combination of a resource record type and a "global" (highest-level) + underscored node name; that is, the node name beginning with an + underscore that is the closest to the DNS root. + + The specifications describing the existing uses of underscored naming + do not reflect the existence of this integrated registry. For the + new reader or the new editor of one of those documents, there is + currently nothing signaling that the underscored name(s) defined in + the document are now processed through an IANA registry. This + document remedies that, by marking such a published document with an + update that indicates the nature of the change. + + Further, the documents that define the SRV [RFC2782] and URI + [RFC7553] DNS resource records provide a meta-template for + underscored name assignments, partially based on separate registries + [RFC6335]. For the portion that selects the global (highest-level) + underscored node name, this perpetuates uncoordinated assignment + activities by separate technical specifications, out of the same + namespace. This document remedies that by providing detail for + revisions to the SRV and URI specifications to bring their use in + line with the single, integrated "Underscored and Globally Scoped DNS + Node Names" registry. + + The result of these changes preserves existing software and + operations practices while adapting the technical specifications to + the newer underscore registry model. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. Underscored RRset Use in Specifications + + The use of underscored node names is specific to each RR TYPE that is + being scoped. Each name defines a place but does not define the + rules for what appears underneath that place, either as additional + underscored naming or as a leaf node with resource records. Details + for those rules are provided by specifications for individual RR + TYPEs. The sections below describe the way that existing underscored + names are used with the RR TYPEs that they name. + + + + + + + +Crocker Best Current Practice [Page 3] + +RFC 8553 DNS AttrLeaf Fix March 2019 + + +2.1. TXT RRset + + + + NOTE - Documents falling into this category include: [RFC5518], + [RFC5617], [RFC6120], [RFC6376], [RFC6763], [RFC7208], and + [RFC7489]. + + This section provides a generic approach for changes to existing + specifications that define straightforward use of underscored node + names when scoping the use of a TXT RRset. The approach provides the + information needed for adapting such specifications to the use of the + IANA "Underscored and Globally Scoped DNS Node Names" registry + [RFC8552]. Hence, the approach is meant both as an update to these + existing specifications and as guidance for changes when those + documents are revised. + + For any document that specifies the use of a TXT RRset under one or + more underscored names, the global node name is expected to be + registered in the IANA "Underscored and Globally Scoped DNS Node + Names" registry [RFC8552]. An effort has been made to locate + existing documents that do this, to register the global underscored + node names, and to list them in the initial set of names added to the + registry. + + If a public specification defines use of a TXT RRset and calls for + the use of an underscored node name, here is a template of suggested + text for registering the global underscored node name -- the one + closest to the root -- that can be used through the IANA + Considerations section of the specification: + + "Per [RFC8552], please add the following entry to the "Underscored + and Globally Scoped DNS Node Names" registry:" + + +--------+----------------+-----------------------------------------+ + | RR | _NODE NAME | Reference | + | Type | | | + +--------+----------------+-----------------------------------------+ + | TXT | _{DNS node | {citation for the document making the | + | | name} | addition} | + +--------+----------------+-----------------------------------------+ + + Table 1: Entry for the "Underscored and Globally Scoped DNS + Node Names" Registry for TXT RR Use + + + + + + + +Crocker Best Current Practice [Page 4] + +RFC 8553 DNS AttrLeaf Fix March 2019 + + +2.2. SRV RRset + + NOTE - Documents falling into this category include: + + [RFC3263], [RFC3529], [RFC3620], [RFC3832], [RFC3887], + [RFC3958], [RFC4120], [RFC4227], [RFC4386], [RFC4387], + [RFC4976], [RFC5026], [RFC5328], [RFC5389], [RFC5415], + [RFC5555], [RFC5679], [RFC5766], [RFC5780], [RFC5804], + [RFC5864], [RFC5928], and [RFC6186]. + + Specification of the SRV resource record [RFC2782] provides a + template for use of underscored node names. The global node name is + characterized as referencing the 'protocol' that is associated with + SRV RRset usage. + + This section provides a generic approach for changes to existing + specifications that define the use of an SRV RRset. The approach + provides the information needed for adapting such specifications to + the use of the IANA "Underscored and Globally Scoped DNS Node Names" + registry [RFC8552]. Hence, the approach is meant both as an update + to these existing specifications and as guidance for changes when + those documents are revised. + + For any document that specifies the use of an SRV RRset, the global + ('protocol') underscored node name is expected to be registered in + the IANA "Underscored and Globally Scoped DNS Node Names" registry + [RFC8552]. An effort has been made to locate existing documents that + do this, to register the global underscored node names, and to list + them in the initial set of names added to the registry. + + If a public specification defines use of an SRV RRset and calls for + the use of an underscored node name, here is a template of suggested + text for registering the global underscored node name -- the one + closest to the root -- that can be used through the IANA + Considerations section of the specification: + + + + + + + + + + + + + + + + +Crocker Best Current Practice [Page 5] + +RFC 8553 DNS AttrLeaf Fix March 2019 + + + "Per [RFC8552], please add the following entry to the "Underscored + and Globally Scoped DNS Node Names" registry: + + +--------+----------------------+-----------------------------------+ + | RR | _NODE NAME | Reference | + | Type | | | + +--------+----------------------+-----------------------------------+ + | SRV | _{DNS 'protocol' | {citation for the document making | + | | node name} | the addition} | + +--------+----------------------+-----------------------------------+ + + Table 2: Entry for the "Underscored and Globally Scoped DNS Node + Names" Registry for SRV RR Use + +2.3. URI RRset + + Specification of the URI resource record [RFC7553] provides a + template for use of underscored node names. The global node name is + characterized as naming the 'protocol' that is associated with URI RR + usage or by reversing an Enumservice sequence [RFC6117]. + + This section provides a generic approach for changes to existing + specifications that define use of a URI RRset. The approach provides + the information needed for adapting such specifications to the use of + the IANA "Underscored and Globally Scoped DNS Node Names" registry + [RFC8552]. Hence, the approach is meant both as an update to these + existing specifications and as guidance for changes when those + documents are revised. + + For any document that specifies the use of a URI RRset, the global + ('protocol' or highest-level Enumservice) underscored node name is + expected to be registered in the IANA "Underscored and Globally + Scoped DNS Node Names" registry [RFC8552]. An effort has been made + to locate existing documents that do this, to register the global + underscored node names, and to list them in the initial set of names + added to the registry. + + If a public specification defines use of a URI RRset and calls for + the use of an underscored node name, here is a template of suggested + text for registering the global underscored node name -- the one + closest to the root -- that can be used through the IANA + Considerations section of the specification: + + + + + + + + + +Crocker Best Current Practice [Page 6] + +RFC 8553 DNS AttrLeaf Fix March 2019 + + + "Per [RFC8552], please add the following entry to the "Underscored + and Globally Scoped DNS Node Names" registry: + + +-------+----------------------------+------------------------------+ + | RR | _NODE NAME | Reference | + | Type | | | + +-------+----------------------------+------------------------------+ + | URI | _{DNS 'protocol' or | {citation for the document | + | | Enumservice node name} | making the addition} | + +-------+----------------------------+------------------------------+ + + Table 3: Entry for the "Underscored and Globally Scoped DNS Node + Names" Registry for URI RR Use + +3. Underscored Template Specifications + +3.1. SRV Specification Changes + + The specification for a domain name, under which an SRV resource + record [RFC2782] appears, provides a template for use of underscored + node names. The global underscored node name is characterized as + indicating the 'protocol' that is associated with SRV RR usage. + + The text of [RFC2782] is changed as described below. In addition, + note that a normative reference to RFC 8552 is added to the + References section of RFC 2782. + + OLD: + + The format of the SRV RR + + Here is the format of the SRV RR, whose DNS type code is 33: + _Service._Proto.Name TTL Class SRV Priority Weight Port Target + ... + Proto + The symbolic name of the desired protocol, with an underscore + (_) prepended to prevent collisions with DNS labels that occur + in nature. _TCP and _UDP are at present the most useful values + for this field, though any name defined by Assigned Numbers or + locally may be used (as for Service). The Proto is case + insensitive. + + + + + + + + + + +Crocker Best Current Practice [Page 7] + +RFC 8553 DNS AttrLeaf Fix March 2019 + + + NEW: + + The format of the SRV RR + + Here is the format of the SRV RR, whose DNS type code is 33: + + "_Service._Proto.Name TTL Class SRV Priority Weight Port + Target" + + _..._ + + Proto + + The symbolic name of the desired protocol with an underscore + (e.g., "_name") prepended to prevent collisions with DNS + labels that occur in nature. _TCP and _UDP are at present + the most useful values for this field. The Proto is case + insensitive. + + The SRV RRset 'protocol' (global) underscored node name + SHOULD be registered in the IANA "Underscored and Globally + Scoped DNS Node Names" registry [RFC8552]. + +3.2. URI Specification Changes + + Specification for the domain name (under which a URI resource record + [RFC7553] occurs) is similar to that for the SRV resource record + [RFC2782], although the text refers only to 'service' name, rather + than distinguishing 'service' from 'protocol'. Further, the URI RR + specification permits alternative underscored naming schemes: + + One matches what is used for SRV, with the global underscored node + name called 'protocol'. + + The other is based on a reversing of an Enumservice [RFC6117] + sequence. + + Text of [RFC7553] is changed as described below. In addition, a + normative reference to RFC 8552 is added to the References section of + RFC 7553. + + + + + + + + + + + +Crocker Best Current Practice [Page 8] + +RFC 8553 DNS AttrLeaf Fix March 2019 + + + OLD: + + 4.1. Owner Name, Class, and Type + + The URI owner name is subject to special conventions. + + Just like the SRV RR [RFC2782], the URI RR has service information + encoded in its owner name. In order to encode the service for a + specific owner name, one uses service parameters. Valid service + parameters are those registered by IANA in the "Service Name and + Transport Protocol Port Number Registry" [RFC6335] or as "Enumservice + --- + Registrations [RFC6117]. The Enumservice Registration parameters are + reversed (i.e., subtype(s) before type), prepended with an underscore + (_), and prepended to the owner name in separate labels. The + underscore is prepended to the service parameters to avoid collisions + with DNS labels that occur in nature, and the order is reversed to + make it possible to do delegations, if needed, to different zones + (and therefore providers of DNS). + + For example, suppose we are looking for the URI for a service with + ENUM Service Parameter "A:B:C" for host example.com. Then we would + query for (QNAME,QTYPE)=("_C._B._A.example.com","URI"). + + As another example, suppose we are looking for the URI for a service + with Service Name "A" and Transport Protocol "B" for host + example.com. Then we would query for + (QNAME,QTYPE)=("_A._B.example.com","URI"). + + NEW: + + 4.1. Owner Name, Class, and Type + + The URI owner name is subject to special conventions. + + As for the SRV RRset [RFC2782], the URI RRset global (highest- + level) underscored node name SHOULD be registered in the IANA + "Underscored and Globally Scoped DNS Node Names" registry + [RFC8552]. + + Just like the SRV RRset, the URI RRset has service information + encoded in its owner name. In order to encode the service for + a specific owner name, one uses service parameters. Valid + service parameters are: + + + Those registered by IANA in the "Service Name and Transport + Protocol Port Number Registry" [RFC6335]. The underscore is + prepended to the service parameters to avoid collisions with + + + +Crocker Best Current Practice [Page 9] + +RFC 8553 DNS AttrLeaf Fix March 2019 + + + DNS labels that occur in nature, and the order is reversed + to make it possible to do delegations, if needed, to + different zones (and therefore providers of DNS). + + + Those listed in "Enumservice Registrations" [RFC6117]. The + Enumservice Registration parameters are reversed (i.e., + subtype(s) before type), prepended with an underscore (e.g., + "_name"), and prepended to the owner name in separate + labels. The highest-level (global) underscored Enumservice + name becomes the global name per RFC 8552 to register. + + For example, suppose we are looking for the URI for a service + with ENUM Service Parameter "A:B:C" for host example.com. Then + we would query for + (QNAME,QTYPE)=("_C._B._A.example.com","URI"). + + As another example, suppose we are looking for the URI for a + service with Service Name "A" and Transport Protocol "B" for + host example.com. Then we would query for + (QNAME,QTYPE)=("_A._B.example.com","URI"). + +3.3. DNSSEC Signaling Specification Changes + + "Signaling Trust Anchor Knowledge in DNS Security Extensions + (DNSSEC)" [RFC8145] defines a use of DNS node names that effectively + consumes all names beginning with the string "_ta-" when using the + NULL RR in the query. + + Text of Section 5.1, "Query Format", of RFC 8145 is changed as + described below. In addition, a normative reference to RFC 8552 is + added to the References section of RFC 8145. + + OLD: + + For example, a validating DNS resolver ... + QNAME=_ta-4444. + + NEW: + + For example, a validating DNS resolver ... "QNAME=_ta-4444". + + Under the NULL RR, an entry is registered in the IANA + "Underscored and Globally Scoped DNS Node Names" registry + [RFC8552] for all node names beginning with "_ta-". + + + + + + + +Crocker Best Current Practice [Page 10] + +RFC 8553 DNS AttrLeaf Fix March 2019 + + +4. IANA Considerations + + Although this document makes reference to IANA registries, it + introduces no new IANA registries or procedures. + +5. Security Considerations + + This memo raises no security issues. + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [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, . + + [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, + . + + [RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource + Identifier (URI) DNS Resource Record", RFC 7553, + DOI 10.17487/RFC7553, June 2015, + . + + [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, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource + Records through "Underscored" Naming of Attribute Leaves", + RFC 8552, DOI 10.17487/RFC8552, March 2019, + . + + + +Crocker Best Current Practice [Page 11] + +RFC 8553 DNS AttrLeaf Fix March 2019 + + +6.2. Informative References + + [IANA-reg] + IANA, "Protocol Registries", + . + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, + November 1987, . + + [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, + . + + [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation + Protocol (SIP): Locating SIP Servers", RFC 3263, + DOI 10.17487/RFC3263, June 2002, + . + + [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, . + + [RFC3620] New, D., "The TUNNEL Profile", RFC 3620, + DOI 10.17487/RFC3620, October 2003, + . + + [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, + . + + [RFC3887] Hansen, T., "Message Tracking Query Protocol", RFC 3887, + DOI 10.17487/RFC3887, September 2004, + . + + [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, . + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC 4120, + DOI 10.17487/RFC4120, July 2005, + . + + + +Crocker Best Current Practice [Page 12] + +RFC 8553 DNS AttrLeaf Fix March 2019 + + + [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, . + + [RFC4386] Boeyen, S. and P. Hallam-Baker, "Internet X.509 Public Key + Infrastructure Repository Locator Service", RFC 4386, + DOI 10.17487/RFC4386, February 2006, + . + + [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, . + + [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, + . + + [RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed., + "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, + DOI 10.17487/RFC5026, October 2007, + . + + [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, + . + + [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, + "Session Traversal Utilities for NAT (STUN)", RFC 5389, + DOI 10.17487/RFC5389, October 2008, + . + + [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, + . + + [RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By + Reference", RFC 5518, DOI 10.17487/RFC5518, April 2009, + . + + [RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack + Hosts and Routers", RFC 5555, DOI 10.17487/RFC5555, June + 2009, . + + + +Crocker Best Current Practice [Page 13] + +RFC 8553 DNS AttrLeaf Fix March 2019 + + + [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, . + + [RFC5679] Bajko, G., "Locating IEEE 802.21 Mobility Services Using + DNS", RFC 5679, DOI 10.17487/RFC5679, December 2009, + . + + [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using + Relays around NAT (TURN): Relay Extensions to Session + Traversal Utilities for NAT (STUN)", RFC 5766, + DOI 10.17487/RFC5766, April 2010, + . + + [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery + Using Session Traversal Utilities for NAT (STUN)", + RFC 5780, DOI 10.17487/RFC5780, May 2010, + . + + [RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely + Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804, + July 2010, . + + [RFC5864] Allbery, R., "DNS SRV Resource Records for AFS", RFC 5864, + DOI 10.17487/RFC5864, April 2010, + . + + [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT + (TURN) Resolution Mechanism", RFC 5928, + DOI 10.17487/RFC5928, August 2010, + . + + [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence + Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, + March 2011, . + + [RFC6186] Daboo, C., "Use of SRV Records for Locating Email + Submission/Access Services", RFC 6186, + DOI 10.17487/RFC6186, March 2011, + . + + [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, + . + + + + + +Crocker Best Current Practice [Page 14] + +RFC 8553 DNS AttrLeaf Fix March 2019 + + + [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service + Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, + . + + [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for + Authorizing Use of Domains in Email, Version 1", RFC 7208, + DOI 10.17487/RFC7208, April 2014, + . + + [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based + Message Authentication, Reporting, and Conformance + (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, + . + +Acknowledgements + + Thanks go to Bill Fenner, Dick Franks, Tony Hansen, Peter Koch, Olaf + Kolkman, and Andrew Sullivan for diligent review of the (much) + earlier draft versions. For the later enhancements, thanks to Tim + Wicinski, John Levine, Bob Harold, Joel Jaeggli, Ondrej Sury, and + Paul Wouters. + + Special thanks to Ray Bellis for his persistent encouragement to + continue this effort, as well as the suggestion for an essential + simplification to the registration model. + +Author's Address + + 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/ + + + + + + + + + + + + + + +Crocker Best Current Practice [Page 15] + -- cgit v1.2.3