Internet DRAFT - draft-hoffman-dns-special-labels
draft-hoffman-dns-special-labels
Network Working Group P. Hoffman
Internet-Draft ICANN
Intended status: Standards Track October 1, 2018
Expires: April 4, 2019
IANA Registry for Special Labels in the DNS
draft-hoffman-dns-special-labels-00
Abstract
This document defines an new IANA registry for special labels in the
DNS. The registry is useful because the labels cause special
handling in DNS entities such as stub resolvers, recursive resolvers,
and applications that use DNS, and developers of software for those
entities should be aware of the many types of special labels in use.
[[ A GitHub repo for this document is at
https://github.com/paulehoffman/dns-special-labels ]]
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 4, 2019.
Copyright Notice
Copyright (c) 2018 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
Hoffman Expires April 4, 2019 [Page 1]
Internet-Draft Special Labels Registry October 2018
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
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition of the New IANA Registry . . . . . . . . . . . . . 3
3. Existing Special Labels . . . . . . . . . . . . . . . . . . . 3
3.1. The Root Label . . . . . . . . . . . . . . . . . . . . . 3
3.2. Underscore Labels . . . . . . . . . . . . . . . . . . . . 3
3.3. IDNA . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.4. Sentinel . . . . . . . . . . . . . . . . . . . . . . . . 3
3.5. MTA-STS . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
Some DNS-related RFCs define labels that are treated specially by
stub resolvers, by recursive resolvers, and by applications. It
would be useful for DNS software developers to know what the entire
set of such special labels are so they can determine if their
software needs to handle those labels different than other labels.
This document defines an IANA registry for special labels and lists
the initial entries for that registry.
The special labels defined in the various RFCs were developed after
extensive IETF evaluation of alternative patterns and approaches in
light of the desired behavior of the associated protocols. The group
designing each protocol looked at the many different ways that the
protocol might be best deployed.
1.1. Terminology
In this document, "left-most label" means the label that appears at
the left of a domain name when it is wire format or presentation
format, as defined in [I-D.ietf-dnsop-terminology-bis]. In an
application that uses IDNA [RFC5891] with one or more right-to-left
labels, the order of the labels might appear different in the
application.
Hoffman Expires April 4, 2019 [Page 2]
Internet-Draft Special Labels Registry October 2018
2. Definition of the New IANA Registry
The creation of the registry is defined in Section 4.
@@ Proposed rule for getting in the registry: @@
A label or label-type can be added to the registry only by IESG
approval. This approval will likely come when an Internet Draft is
progressed toward publication by the RFC Editor, but can come at any
time. The reason to require IESG approval as compared to something
less onerous such as "expert review" is that developers who rely on
the registry will expect it to contain labels and label types that
are relatively stable.
The columns of the registry are as follows:
@@ Define the columns here @@
3. Existing Special Labels
The following describes the labels that are the initial contents of
the registry described in Section 4.
3.1. The Root Label
According to [RFC1035], a zero-length label always indicates the root
label in a domain name.
3.2. Underscore Labels
In many protocols, one or more of the left-most labels might be a
label that starts with an underscore (_) character. Those labels are
considered special within the context of those protocols.
The use of underscore labels is described in
[I-D.ietf-dnsop-attrleaf] and [I-D.ietf-dnsop-attrleaf-fix].
3.3. IDNA
[RFC5891] defines "A-labels" as labels that begin with the characters
"xn-". These labels can appear at any position in a domain name.
3.4. Sentinel
[I-D.ietf-dnsop-kskroll-sentinel] (if approved as an RFC) defines
root-key-sentinel-is-ta-<key-tag> and root-key-sentinel-not-ta-<key-
tag> as special labels when they are the left-most label. In these
Hoffman Expires April 4, 2019 [Page 3]
Internet-Draft Special Labels Registry October 2018
labels, "<key-tag>" is an unsigned decimal integer that is zero-
padded to five digits.
3.5. MTA-STS
[RFC8461] defines "mta-sts" as as special label when it is the left-
most label.
4. IANA Considerations
@@@ Formally define the new registry here @@@
5. Security Considerations
This document doesn't introduce any new security considerations.
6. References
6.1. Normative References
[I-D.ietf-dnsop-attrleaf]
Crocker, D., "DNS Scoped Data Through "Underscore" Naming
of Attribute Leaves", draft-ietf-dnsop-attrleaf-13 (work
in progress), August 2018.
[I-D.ietf-dnsop-attrleaf-fix]
Crocker, D., "DNS Attrleaf Changes: Fixing Specifications
with Underscored Node Name Use", draft-ietf-dnsop-
attrleaf-fix-04 (work in progress), August 2018.
[I-D.ietf-dnsop-kskroll-sentinel]
Huston, G., Damas, J., and W. Kumari, "A Root Key Trust
Anchor Sentinel for DNSSEC", draft-ietf-dnsop-kskroll-
sentinel-15 (work in progress), July 2018.
[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>.
[RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891,
DOI 10.17487/RFC5891, August 2010,
<https://www.rfc-editor.org/info/rfc5891>.
[RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A.,
and J. Jones, "SMTP MTA Strict Transport Security (MTA-
STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018,
<https://www.rfc-editor.org/info/rfc8461>.
Hoffman Expires April 4, 2019 [Page 4]
Internet-Draft Special Labels Registry October 2018
6.2. Informative References
[I-D.ietf-dnsop-terminology-bis]
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", draft-ietf-dnsop-terminology-bis-14 (work in
progress), September 2018.
Appendix A. Acknowledgements
@@@ List folks who think of other new labels to add or come up with
additional wording for the document @@@
Author's Address
Paul Hoffman
ICANN
Email: paul.hoffman@icann.org
Hoffman Expires April 4, 2019 [Page 5]
