doc: Add RFC documents

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]
+