draft-ietf-dnsop-attrleaf-14.txt   draft-ietf-dnsop-attrleaf-15.txt 
dnsop D. Crocker dnsop D. Crocker
Internet-Draft Brandenburg InternetWorking Internet-Draft Brandenburg InternetWorking
Intended status: Standards Track October 10, 2018 Intended status: Standards Track November 3, 2018
Expires: April 13, 2019 Expires: May 7, 2019
DNS Scoped Data Through "Underscore" Naming of Attribute Leaves DNS Scoped Data Through "Underscore" Naming of Attribute Leaves
draft-ietf-dnsop-attrleaf-14 draft-ietf-dnsop-attrleaf-15
Abstract Abstract
Formally, any DNS resource record may occur under any domain name. Formally, any DNS resource record may occur under any domain name.
However some services use an operational convention for defining However some services use an operational convention for defining
specific interpretations of an RRset, by locating the records in a specific interpretations of an RRset, by locating the records in a
DNS branch, under the parent domain to which the RRset actually DNS branch, under the parent domain to which the RRset actually
applies. The top of this subordinate branch is defined by a naming applies. The top of this subordinate branch is defined by a naming
convention that uses a reserved node name, which begins with an convention that uses a reserved node name, which begins with an
_underscore. The underscored naming construct defines a semantic _underscore. The underscored naming construct defines a semantic
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 13, 2019. This Internet-Draft will expire on May 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Underscore Scoping . . . . . . . . . . . . . . . . . . . 3 1.1. Underscore Scoping . . . . . . . . . . . . . . . . . . . 3
1.2. Scaling Benefits . . . . . . . . . . . . . . . . . . . . 4 1.2. Scaling Benefits . . . . . . . . . . . . . . . . . . . . 4
1.3. "Global" Underscored Node Names . . . . . . . . . . . . . 4 1.3. "Global" Underscored Node Names . . . . . . . . . . . . . 4
1.4. Interaction with DNS wildcards . . . . . . . . . . . . . 5 1.4. Interaction with DNS wildcards . . . . . . . . . . . . . 5
1.5. History . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. DNS Underscore Scoped Entry Registries Function . . . . . . . 5 2. DNS Underscore Scoped Entry Registries Function . . . . . . . 5
3. RRset Use Registration Template . . . . . . . . . . . . . . . 6 3. RRset Use Registration Template . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4.1. DNS Underscore Global Scoped Entry Registry . . . . . . . 7 4.1. DNS Underscore Global Scoped Entry Registry . . . . . . . 8
4.2. DNS Underscore Global Scoped Entry Registry Definition . 8 4.2. DNS Underscore Global Scoped Entry Registry Definition . 8
4.3. Initial entries . . . . . . . . . . . . . . . . . . . . . 8 4.3. Initial entries . . . . . . . . . . . . . . . . . . . . . 9
5. Guidance for Expert Review . . . . . . . . . . . . . . . . . 9 4.4. Enumservices Registrations Registry . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Guidance for Expert Review . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 7.2. References -\- Informative . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The core Domain Name System (DNS) technical specifications assign no The core Domain Name System (DNS) technical specifications assign no
semantics to domain names or their parts, and no constraints upon semantics to domain names or their parts, and no constraints upon
which resource record (RR) types are permitted to be stored under which resource record (RR) types are permitted to be stored under
particular names [RFC1035], [RFC2181]. Over time, some leaf node particular names [RFC1035], [RFC2181]. Over time, some leaf node
names, such as "www" and "ftp" have come to imply support for names, such as "www" and "ftp" have come to imply support for
particular services, but this is a matter of operational convention, particular services, but this is a matter of operational convention,
rather than defined protocol semantics. This freedom in the basic rather than defined protocol semantics. This freedom in the basic
skipping to change at page 4, line 8 skipping to change at page 4, line 10
establishes the DNS Underscore Global Scoped Entry IANA Registry. establishes the DNS Underscore Global Scoped Entry IANA Registry.
Use of such node names, which begin with underscore, are reserved Use of such node names, which begin with underscore, are reserved
when they are the underscored name closest to the DNS root; they are when they are the underscored name closest to the DNS root; they are
considered "global". Underscore-based names that are farther down considered "global". Underscore-based names that are farther down
the hierarchy are handled within the scope of the global underscore the hierarchy are handled within the scope of the global underscore
name. name.
Discussion Venue: Discussion about this draft should be directed Discussion Venue: Discussion about this draft should be directed
to the dnsop@ietf.org [1] mailing list. to the dnsop@ietf.org [1] mailing list.
NOTE TO RFC EDITOR: Please remove "Discussion Venue" paragraph NOTE TO RFC EDITOR: Please remove "Discussion Venue" paragraph
prior to publication. prior to publication.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Scaling Benefits 1.2. Scaling Benefits
Some resource record types are used in a fashion that can create Some resource record types are used in a fashion that can create
scaling problems, if an entire RRset associated with a domain name is scaling problems, if an entire RRset associated with a domain name is
aggregated in the leaf node for that name. An increasingly-popular aggregated in the leaf node for that name. An increasingly-popular
approach, with excellent scaling properties, places the RRset under a approach, with excellent scaling properties, places the RRset under a
specially named branch, which is in turn under the node name that specially named branch, which is in turn under the node name that
would otherwise contain the RRset. The rules for naming that branch would otherwise contain the RRset. The rules for naming that branch
skipping to change at page 5, line 18 skipping to change at page 5, line 20
Since wildcards only are interpreted as leaf names, one cannot create Since wildcards only are interpreted as leaf names, one cannot create
the equivalent of a wildcard name for prefixed names. A name such as the equivalent of a wildcard name for prefixed names. A name such as
label.*.example.com is not a wildcard. label.*.example.com is not a wildcard.
Conversely, a wildcard such as *.example.com can match any name Conversely, a wildcard such as *.example.com can match any name
including an underscored name. So, a wildcard might match an including an underscored name. So, a wildcard might match an
underscored name, returning a record that is the type controlled by underscored name, returning a record that is the type controlled by
the underscored name but is not intended to be used in the the underscored name but is not intended to be used in the
underscored context and does not conform to its rules. underscored context and does not conform to its rules.
1.5. History
Originally different uses of underscore-based node names developed
largely without coordination. For "TXT" records, there is no
consistent, internal syntax that to permits distinguishing among the
different uses. In the case of the "SRV" "RR" and "URI" "RR",
distinguishing among different types of use was part of the design
[RFC2782], [RFC7553]. The "SRV" and "URI" specifications serve as
templates, defining "RR"s that might only be used for specific
applications when there is an additional specification. The template
definition included reference to two levels of tables of names from
which underscore-names should be drawn. The lower-level (local
scope) set of <"_service"> names is defined in terms of other IANA
tables, namely any table with symbolic names. The upper-level
(global scope) "SRV" naming field is <"_proto">, although its pool of
names is not explicitly defined.
The aggregate effect of these independent efforts was a long list of
underscore-based names that were reserved without coordination, which
invites an eventual name-assignment collision. The remedy is this
base document, which defines a registry for these names, and attempts
to register all those already in use, with a companion document
[attrleaf-fix] developed to direct changes to the pre-registry
specifications that used underscore-based (global) node names.
2. DNS Underscore Scoped Entry Registries Function 2. DNS Underscore Scoped Entry Registries Function
A registry for "global" DNS node names that begin with an underscore A registry for "global" DNS node names that begin with an underscore
is defined here. The purpose of the Underscore Global Registry is to is defined here. The purpose of the Underscore Global Registry is to
avoid collisions resulting from the use of the same underscore-based avoid collisions resulting from the use of the same underscore-based
name, for different applications. name, for different applications.
o If a public specification calls for use of an underscore-prefixed o If a public specification calls for use of an underscore-prefixed
domain node name, the "global" underscored name -- the underscored domain node name, the "global" underscored name -- the underscored
name that is closest to the DNS root -- MUST be entered into this name that is closest to the DNS root -- MUST be entered into this
skipping to change at page 6, line 19 skipping to change at page 6, line 45
| _protoB._service2 | | _protoB._service2 |
| _protoB._service3 | | _protoB._service3 |
| _protoC._service3 | | _protoC._service3 |
| _useX._protoD._service4 | | _useX._protoD._service4 |
| _protoE._region._authority | | _protoE._region._authority |
+----------------------------+ +----------------------------+
Table 1: Examples of Underscored Names Table 1: Examples of Underscored Names
Only global underscored names are registered in the IANA Underscore Only global underscored names are registered in the IANA Underscore
Global table. (From the example, that would mean registering Only the global underscored names "_service1", "_service2", Global
_service1, _service2, _service3, _service 4, and _authority.) table. (From the example, that would mean registering "_service3",
"_service4", and "_authority" are registered in the IANA _service1,
_service2, _service3, _service 4, and _authority.)
o The use of underscored node names is specific to each RRTYPE that o The use of underscored node names is specific to each RRTYPE that
is being scoped. Each name defines a place, but does not define is being scoped. Each name defines a place, but does not define
the rules for what appears underneath that place, either as the rules for what appears underneath that place, either as
additional underscored naming or as a leaf node with resource additional underscored naming or as a leaf node with resource
records. Details for those rules are provided by specifications records. Details for those rules are provided by specifications
for individual RRTYPEs. The sections below describe the way that for individual RRTYPEs. The sections below describe the way that
existing underscore labels are used with the RRTYPEs that they existing underscore labels are used with the RRTYPEs that they
name. name.
skipping to change at page 7, line 15 skipping to change at page 7, line 41
Note to RFC Editor: Please replace the above "{RFC Attrleaf}" text Note to RFC Editor: Please replace the above "{RFC Attrleaf}" text
with a reference to this document's RFC number. /d with a reference to this document's RFC number. /d
+----------+-------------------+------------------------------------+ +----------+-------------------+------------------------------------+
| RR Type | _NODE NAME | REFERENCE | | RR Type | _NODE NAME | REFERENCE |
+----------+-------------------+------------------------------------+ +----------+-------------------+------------------------------------+
| {RRTYPE} | _{DNS global node | {citation for the document making | | {RRTYPE} | _{DNS global node | {citation for the document making |
| | name} | the addition.} | | | name} | the addition.} |
+----------+-------------------+------------------------------------+ +----------+-------------------+------------------------------------+
Table 2: Underscore Global Registry Entry Table 2: Underscore Global Registry Entry Template
4. IANA Considerations 4. IANA Considerations
Per [RFC8126], IANA is requested to establish the: Per [RFC8126] IANA is requested to establish the:
DNS Underscore Global Scoped Entry Registry "DNS Underscore Global Scoped Entry Registry"
This section describes actions requested of IANA. The guidance in This section describes actions requested of IANA. The guidance in
[IANA] is used. [IANA] is used.
4.1. DNS Underscore Global Scoped Entry Registry 4.1. DNS Underscore Global Scoped Entry Registry
The DNS Global Underscore Scoped Entry Registry is any DNS node name The DNS Global Underscore Scoped Entry Registry is any DNS node name
that begin with the underscore character ("_", ASCII 0x5F) and is the that begin with the underscore character ("_", ASCII 0x5F) and is the
underscored node name closest to the root; that is it defines the underscored node name closest to the root; that is it defines the
highest-level of a DNS branch, under a "parent" domain name. highest-level of a DNS branch, under a "parent" domain name.
skipping to change at page 8, line 9 skipping to change at page 8, line 34
o The table is to be maintained with entries sorted by the first o The table is to be maintained with entries sorted by the first
column (RR Type) and, within that, the second column (_Node Name). column (RR Type) and, within that, the second column (_Node Name).
o The required Reference for an entry MUST have a stable resolution o The required Reference for an entry MUST have a stable resolution
to the organization controlling that registry entry. to the organization controlling that registry entry.
4.2. DNS Underscore Global Scoped Entry Registry Definition 4.2. DNS Underscore Global Scoped Entry Registry Definition
A registry entry contains: A registry entry contains:
RR Type: Lists an RR type that is defined for use within this RR Type: Lists an RR type that is defined for use within this
scope scope.
_Node Name: Specifies a single, underscored name that defines a _Node Name: Specifies a single, underscored name that defines a
reserved name; this name is the "global" entry name for the reserved name; this name is the "global" entry name for
scoped resource record types that are associated with that the scoped resource record types that are associated
name; for characters in the name that have an upper-case with that name; for characters in the name that have an
form and a lower-case form, the character MUST be recorded upper-case form and a lower-case form, the character
as lower-case, to simplify name comparisons. MUST be recorded as lower-case, to simplify name
comparisons.
References: Lists specification that defines a record type and its References: Lists the specification that defines a record type
use under this Name. The organization producing the and its use under this _Node Name. The organization
specification retains control over the registry entry for producing the specification retains control over the
the _Node Name registry entry for the _Node Name.
Each RR type that is to be used MUST have a separate registry entry. Each RR type that is to be used with a _Node Name MUST have a
separate registry entry.
4.3. Initial entries 4.3. Initial entries
Initial entries in the registry are: Initial entries in the registry are:
+------------+------------------+------------+ +------------+------------------+------------+
| RR Type | _NODE NAME | REFERENCE | | RR Type | _NODE NAME | REFERENCE |
+------------+------------------+------------+ +------------+------------------+------------+
| NULL | _ta-* {see note} | [RFC8145] | | NULL | _ta-* {see note} | [RFC8145] |
| OPENPGPKEY | _openpgpkey | [RFC7929] | | OPENPGPKEY | _openpgpkey | [RFC7929] |
| PTR | _tcp | [RFC6763] |
| PTR | _udp | [RFC6763] |
| SMIMEA | _smimecert | [RFC8162] | | SMIMEA | _smimecert | [RFC8162] |
| SRV | _dccp | [RFC2782] | | SRV | _dccp | [RFC2782] |
| SRV | _http | [RFC4386] |
| SRV | _ipv6 | [RFC5026] | | SRV | _ipv6 | [RFC5026] |
| SRV | _sip | [RFC5509] | | SRV | _ldap | [RFC4386] |
| SRV | _ocsp | [RFC4386] |
| SRV | _sctp | [RFC2782] | | SRV | _sctp | [RFC2782] |
| SRV | _sip | [RFC5509] |
| SRV | _tcp | [RFC2782] | | SRV | _tcp | [RFC2782] |
| SRV | _udp | [RFC2782] | | SRV | _udp | [RFC2782] |
| SRV | _xmpp | [RFC3921] | | SRV | _xmpp | [RFC3921] |
| TLSA | _dane | [RFC7671] | | TLSA | _dane | [RFC7671] |
| TLSA | _sctp | [RFC6698] | | TLSA | _sctp | [RFC6698] |
| TLSA | _tcp | [RFC6698] | | TLSA | _tcp | [RFC6698] |
| TLSA | _udp | [RFC6698] | | TLSA | _udp | [RFC6698] |
| TXT | _mta-sts | [MTA-STS] |
| TXT | _acme-challenge | [ACME] | | TXT | _acme-challenge | [ACME] |
| TXT | _dmarc | [RFC7489] | | TXT | _dmarc | [RFC7489] |
| TXT | _domainkey | [RFC6376] | | TXT | _domainkey | [RFC6376] |
| TXT | _mta-sts | [MTA-STS] |
| TXT | _spf | [RFC7208] | | TXT | _spf | [RFC7208] |
| TXT | _tcp | [RFC6763] |
| TXT | _udp | [RFC6763] |
| TXT | _vouch | [RFC5518] | | TXT | _vouch | [RFC5518] |
| URI | _iax | [RFC6315] | | URI | _acct | [RFC6118] |
| URI | _acct | [RFC7566] | | URI | _dccp | [RFC7566] |
| URI | _dccp | [RFC6118] |
| URI | _email | [RFC6118] | | URI | _email | [RFC6118] |
| URI | _ems | [RFC6118] | | URI | _ems | [RFC6118] |
| URI | _fax | [RFC6118] | | URI | _fax | [RFC6118] |
| URI | _ft | [RFC6118] | | URI | _ft | [RFC6118] |
| URI | _h323 | [RFC6118] | | URI | _h323 | [RFC6118] |
| URI | _ical-sched | [RFC6118] | | URI | _iax | [RFC6118] |
| URI | _ical-access | [RFC6118] | | URI | _ical-access | [RFC6118] |
| URI | _ical-sched | [RFC6118] |
| URI | _ifax | [RFC6118] | | URI | _ifax | [RFC6118] |
| URI | _im | [RFC6118] | | URI | _im | [RFC6118] |
| URI | _mms | [RFC6118] | | URI | _mms | [RFC6118] |
| URI | _pres | [RFC6118] | | URI | _pres | [RFC6118] |
| URI | _pstn | [RFC7553] | | URI | _pstn | [RFC6118] |
| URI | _sctp | [RFC7553] | | URI | _sctp | [RFC6118] |
| URI | _sip | [RFC7553] | | URI | _sip | [RFC6118] |
| URI | _sms | [RFC6118] | | URI | _sms | [RFC6118] |
| URI | _tcp | [RFC6118] | | URI | _tcp | [RFC6118] |
| URI | _udp | [RFC6118] | | URI | _udp | [RFC6118] |
| URI | _unifmsg | [RFC6118] | | URI | _unifmsg | [RFC6118] |
| URI | _vcard | [RFC6118] | | URI | _vcard | [RFC6118] |
| URI | _videomsg | [RFC6118] | | URI | _videomsg | [RFC6118] |
| URI | _voice | [RFC6118] | | URI | _voice | [RFC6118] |
| URI | _voicemsg | [RFC6118] | | URI | _voicemsg | [RFC6118] |
| URI | _vpim | [RFC6118] | | URI | _vpim | [RFC6118] |
| URI | _web | [RFC6118] | | URI | _web | [RFC6118] |
| URI | _xmpp | [RFC6118] | | URI | _xmpp | [RFC6118] |
+------------+------------------+------------+ +------------+------------------+------------+
Table 3: Underscore Global Registry (initial entries) Table 3: Underscore Global Registry (initial entries)
NOTE: Under the NULL RR, the entry "_ta-*" is meant to denote all NOTE: Under the NULL RR, the entry ""_ta-*"" denotes all node
node names beginning with the string "_ta-". It does NOT refer to names beginning with the string ""_ta-*"". It does NOT refer to a
a DNS wildcard specification. DNS wildcard specification.
4.4. Enumservices Registrations Registry
Please add a note to the Enumservice Registrations registry with the
following -- or similar -- language:
"When adding an entry to this registry, strong consideration
should be given to also adding an entry to the 'DNS Underscore
Global Scoped Entry Registry'."
5. Guidance for Expert Review 5. Guidance for Expert Review
This section provides guidance for expert review of registration This section provides guidance for expert review of registration
requests in the DNS Underscore Global Scoped Entry Registry. requests in the DNS Underscore Global Scoped Entry Registry.
This review is solely to determine adequacy of a requested entry This review is solely to determine adequacy of a requested entry
in this Registry, and does not include review of other aspects of in this Registry, and does not include review of other aspects of
the document specifying that entry. For example such a document the document specifying that entry. For example such a document
might also contain a definition of the resource record type that might also contain a definition of the resource record type that
skipping to change at page 11, line 14 skipping to change at page 12, line 5
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence", Protocol (XMPP): Instant Messaging and Presence",
RFC 3921, DOI 10.17487/RFC3921, October 2004, RFC 3921, DOI 10.17487/RFC3921, October 2004,
<https://www.rfc-editor.org/info/rfc3921>. <https://www.rfc-editor.org/info/rfc3921>.
[RFC4386] Boeyen, S. and P. Hallam-Baker, "Internet X.509 Public Key
Infrastructure Repository Locator Service", RFC 4386,
DOI 10.17487/RFC4386, February 2006,
<https://www.rfc-editor.org/info/rfc4386>.
[RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed., [RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed.,
"Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026,
DOI 10.17487/RFC5026, October 2007, DOI 10.17487/RFC5026, October 2007,
<https://www.rfc-editor.org/info/rfc5026>. <https://www.rfc-editor.org/info/rfc5026>.
[RFC5509] Loreto, S., "Internet Assigned Numbers Authority (IANA) [RFC5509] Loreto, S., "Internet Assigned Numbers Authority (IANA)
Registration of Instant Messaging and Presence DNS SRV RRs Registration of Instant Messaging and Presence DNS SRV RRs
for the Session Initiation Protocol (SIP)", RFC 5509, for the Session Initiation Protocol (SIP)", RFC 5509,
DOI 10.17487/RFC5509, April 2009, DOI 10.17487/RFC5509, April 2009,
<https://www.rfc-editor.org/info/rfc5509>. <https://www.rfc-editor.org/info/rfc5509>.
[RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By [RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By
Reference", RFC 5518, April 2009. Reference", RFC 5518, April 2009.
[RFC6118] Hoeneisen, B. and A. Mayrhofer, "Update of Legacy IANA [RFC6118] Hoeneisen, B. and A. Mayrhofer, "Update of Legacy IANA
Registrations of Enumservices", RFC 6118, Registrations of Enumservices", RFC 6118,
DOI 10.17487/RFC6118, March 2011, DOI 10.17487/RFC6118, March 2011,
<https://www.rfc-editor.org/info/rfc6118>. <https://www.rfc-editor.org/info/rfc6118>.
[RFC6315] Guy, E. and K. Darilion, "IANA Registration for
Enumservice 'iax'", RFC 6315, DOI 10.17487/RFC6315, July
2011, <https://www.rfc-editor.org/info/rfc6315>.
[RFC6335] Cotton, M., Eggert, L., Tpuch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Tpuch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "nternet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", RFC 6335, Aug Transport Protocol Port Number Registry", RFC 6335, Aug
2011. 2011.
[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
Identified Mail (DKIM) Signatures", RFC 6376, Sept 2011. Identified Mail (DKIM) Signatures", RFC 6376, Sept 2011.
[RFC6698] Hoffman, J. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, J. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August . Protocol: TLSA", RFC 6698, August .
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012,
<https://www.rfc-editor.org/info/rfc6733>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in E-Mail, Version 1", Authorizing Use of Domains in E-Mail, Version 1",
RFC 7208, April 2014. RFC 7208, April 2014.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance Message Authentication, Reporting, and Conformance
skipping to change at page 12, line 41 skipping to change at page 13, line 41
[RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust [RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust
Anchor Knowledge in DNS Security Extensions (DNSSEC)", Anchor Knowledge in DNS Security Extensions (DNSSEC)",
RFC 8145, April 2017. RFC 8145, April 2017.
[RFC8162] Hoffman, P. and J. Schlyter, "Using Secure DNS to [RFC8162] Hoffman, P. and J. Schlyter, "Using Secure DNS to
Associate Certificates with Domain Names for S/MIME", Associate Certificates with Domain Names for S/MIME",
RFC 8162, May 2017. RFC 8162, May 2017.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", RFC 8162, May 2017. 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC952] Harrenstien, K., Stahl, M., and E. Feinler, "DOD Internet [RFC952] Harrenstien, K., Stahl, M., and E. Feinler, "DOD Internet
Host Table Specification", RFC 952, October 1985. Host Table Specification", RFC 952, October 1985.
7.2. URIs 7.2. References -\- Informative
[attrleaf-fix]
Crocker, D., "Changes to Rationalize Underscore DNS Node
Names", I-D draft-crocker-attrleaf-simplification-00,
2017.
7.3. URIs
[1] mailto:dnsop@ietf.org [1] mailto:dnsop@ietf.org
Appendix A. Acknowledgements Appendix A. Acknowledgements
Thanks go to Bill Fenner, Dick Franks, Tony Hansen, Martin Hoffmann, Thanks go to Bill Fenner, Dick Franks, Tony Hansen, Martin Hoffmann,
Paul Hoffman, Peter Koch, Olaf Kolkman, Murray Kucherawy, John Paul Hoffman, Peter Koch, Olaf Kolkman, Murray Kucherawy, John
Levine, and Andrew Sullivan for diligent review of the (much) earlier Levine, Benno Overeinder, and Andrew Sullivan for diligent review of
drafts. For the later enhancements, thanks to: Stephane Bortzmeyer, the (much) earlier drafts. For the later enhancements, thanks to:
Alissa Cooper, Bob Harold, Benjamin Kaduk, Mirja Kuehlewind, Warren Stephane Bortzmeyer, Alissa Cooper, Bob Harold, Benjamin Kaduk, Mirja
Kumari, John Levine, Joel Jaeggli, Benno Overeinder, Eric Rescorla, Kuehlewind, Warren Kumari, John Levine, Joel Jaeggli, Benno
Adam Roach, Petr &#352;pa&#269;ek, Ond&#345;ej Sury, Paul Vixie, Tim Overeinder, Eric Rescorla, Adam Roach, Petr &#352;pa&#269;ek,
Wicinski, and Paul Wouters. Ond&#345;ej Sury, Paul Vixie, Tim Wicinski, and Paul Wouters.
Special thanks to Ray Bellis for his persistent encouragement to Special thanks to Ray Bellis for his persistent encouragement to
continue this effort, as well as the suggestion for an essential continue this effort, as well as the suggestion for an essential
simplification to the registration model. simplification to the registration model.
Author's Address Author's Address
Dave Crocker Dave Crocker
Brandenburg InternetWorking Brandenburg InternetWorking
675 Spruce Dr. 675 Spruce Dr.
 End of changes. 37 change blocks. 
63 lines changed or deleted 121 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/