summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8553.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8553.txt')
-rw-r--r--doc/rfc/rfc8553.txt843
1 files changed, 843 insertions, 0 deletions
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,
+ <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>.
+
+
+
+Crocker Best Current Practice [Page 11]
+
+RFC 8553 DNS AttrLeaf Fix March 2019
+
+
+6.2. Informative References
+
+ [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>.
+
+
+
+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, <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>.
+
+
+
+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, <https://www.rfc-editor.org/info/rfc5617>.
+
+ [RFC5679] Bajko, G., "Locating IEEE 802.21 Mobility Services Using
+ 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 Using
+ 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>.
+
+
+
+
+
+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,
+ <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>.
+
+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]
+