< draft-ietf-dnsop-alt-tld-08.txt   draft-ietf-dnsop-alt-tld-09.txt >
dnsop W. Kumari dnsop W. Kumari
Internet-Draft Google Internet-Draft Google
Intended status: Informational A. Sullivan Intended status: Informational A. Sullivan
Expires: September 4, 2017 Dyn Expires: July 22, 2018 Oracle
March 3, 2017 January 18, 2018
The ALT Special Use Top Level Domain The ALT Special Use Top Level Domain
draft-ietf-dnsop-alt-tld-08 draft-ietf-dnsop-alt-tld-09
Abstract Abstract
This document reserves a string (ALT) to be used as a TLD label in This document reserves a string (ALT) to be used as a TLD label in
non-DNS contexts. It also provides advice and guidance to developers non-DNS contexts. It also provides advice and guidance to developers
developing alternative namespaces. developing alternative namespaces.
[Ed note: Text inside square brackets ([]) is additional background [Ed note: Text inside square brackets ([]) is additional background
information, answers to frequently asked questions, general musings, information, answers to frequently asked questions, general musings,
etc. They will be removed before publication. This document is etc. They will be removed before publication. This document is
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 September 4, 2017. This Internet-Draft will expire on July 22, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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. Requirements notation . . . . . . . . . . . . . . . . . . 2 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The ALT namespace . . . . . . . . . . . . . . . . . . . . . . 4 3. The ALT namespace . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Choice of the ALT Name . . . . . . . . . . . . . . . . . 5 3.1. Choice of the ALT Name . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4.1. Domain Name Reservation Considerations . . . . . . . . . 5 4.1. Domain Name Reservation Considerations . . . . . . . . . 5
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 8 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Many protocols and systems need to name entities. Names that look Many protocols and systems need to name entities. Names that look
like DNS names (a series of labels separated with dots) have become like DNS names (a series of labels separated with dots) have become
common, even in systems that are not part of the global DNS common, even in systems that are not part of the global DNS
administered by IANA. This document reserves the label "ALT" (short administered by IANA. This document reserves the label "ALT" (short
for "Alternative") as a Special Use Domain ([RFC6761]). This label for "Alternative") as a Special Use Domain ([RFC6761]). This label
is intended to be used as the final (rightmost) label to signify that is intended to be used as the final (rightmost) label to signify that
the name is not rooted in the DNS, and that should not be resolved the name is not rooted in the DNS, and that it should not be resolved
using the DNS protocol. using the DNS protocol.
1.1. Requirements notation 1.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
skipping to change at page 3, line 44 skipping to change at page 3, line 44
separate from, the global DNS. They often use a pseudo-TLD to cause separate from, the global DNS. They often use a pseudo-TLD to cause
resolution in the alternative namespace, using browser plugins, shims resolution in the alternative namespace, using browser plugins, shims
in the name resolution process, or simply applications that perform in the name resolution process, or simply applications that perform
special handling of this particular alternative namespace. An special handling of this particular alternative namespace. An
example of such a system is the Tor network's [Dingledine2004] use of example of such a system is the Tor network's [Dingledine2004] use of
the ".onion" Special-Use Top-Level Domain Name (see [RFC7686]). the ".onion" Special-Use Top-Level Domain Name (see [RFC7686]).
In many cases, the creators of these alternative namespaces have In many cases, the creators of these alternative namespaces have
chosen a convenient or descriptive string and started using it. chosen a convenient or descriptive string and started using it.
These strings are not registered anywhere nor are they part of the These strings are not registered anywhere nor are they part of the
DNS. However, to users and to some applications they appear to be DNS. However, to users and to some applications, they appear to be
TLDs; and issues may arise if they are looked up in the DNS. This TLDs; and issues may arise if they are looked up in the DNS. This
document suggests that name resolution libraries (stub resolvers) document suggests that name resolution libraries (stub resolvers)
recognize names ending in ".alt" as special, and not attempt to look recognize names ending in ".alt" as special, and not attempt to look
them up using the DNS protocol in order to limit the effects of them up using the DNS protocol in order to limit the effects of
queries accidentally leaking into the DNS. queries accidentally leaking into the DNS.
The techniques in this document are primarily intended to address the The techniques in this document are primarily intended to address the
"Experimental Squatting Problem", the "Land Rush Problem" and "Name "Experimental Squatting Problem", the "Land Rush Problem" and "Name
Collisions" issues discussed in [I-D.ietf-dnsop-sutld-ps] (which Collisions" issues discussed in [I-D.ietf-dnsop-sutld-ps] (which
contains much additional background, etc). contains much additional background, etc).
skipping to change at page 4, line 31 skipping to change at page 4, line 31
As names beneath ALT are in an alternative namespace, they have no As names beneath ALT are in an alternative namespace, they have no
significance in the regular DNS context and so should not be looked significance in the regular DNS context and so should not be looked
up in the DNS context. up in the DNS context.
Groups wishing to create new alternative namespaces may create their Groups wishing to create new alternative namespaces may create their
alternative namespace under a label that names their namespace under alternative namespace under a label that names their namespace under
the ALT label. They should attempt to choose a label that they the ALT label. They should attempt to choose a label that they
expect to be unique and, ideally, descriptive. There is no IANA expect to be unique and, ideally, descriptive. There is no IANA
registry for names under the ALT TLD - it is an unmanaged namespace, registry for names under the ALT TLD - it is an unmanaged namespace,
and developers are responsible for dealing with any collisions that and developers are responsible for dealing with any collisions that
may occur under .alt. Informal lists of namespaces under .alt may may occur under .alt. Informal lists of namespaces under .alt may be
appear to assist the developer community. created to assist the developer community.
[Editor note (to be removed before publication): There was
significant discussion on an IANA registry for the ALT namespace -
please consult the lists for full thread, but the consensus was that
it would be better for the IETF / IANA to not administer a registry
for this. It is expected one or more unofficial lists will be
created where people can list the strings that they are using. ]
Currently deployed projects and protocols that are using pseudo-TLDs Currently deployed projects and protocols that are using pseudo-TLDs
may choose to move under the ALT TLD, but this is not a requirement. may choose to move under the ALT TLD, but this is not a requirement.
Rather, the ALT TLD is being reserved so that current and future Rather, the ALT TLD is being reserved so that current and future
projects of a similar nature have a designated place to create projects of a similar nature have a designated place to create
alternative resolution namespaces that will not conflict with the alternative resolution namespaces that will not conflict with the
regular DNS context. regular DNS context.
3.1. Choice of the ALT Name 3.1. Choice of the ALT Name
A number of names other than "ALT" were considered and discarded. In A number of names other than "ALT" were considered and discarded.
order for this technique to be effective the names need to continue While these are not DNS names, in order for this technique to be
to follow both the DNS format and conventions (a prime consideration effective the names need to continue to follow both the DNS format
for alternative name formats is that they can be entered in places and conventions (a prime consideration for alternative name formats
that normally take DNS context names); this rules out using suffixes is that they can be entered in places that normally take DNS context
that do not follow the usual letter, digit, and hyphen label names); this rules out using suffixes that do not follow the usual
convention. letter, digit, and hyphen label convention.
A short label was deemed desirable for a number of reasons,
including:
o this is a switch to other resolution contexts, some which may have
long labels (for example derived from public keys).
o some queries will undoubtedly leak into the DNS. As many of these
alternate resolution systems are specifically designed for
privacy, limiting how far they leak is desirable.
o as there are not protocol police, the label needs to be attractive
to implementors of alternate resolution contexts so that they are
willing to use this.
4. IANA Considerations 4. IANA Considerations
The IANA is requested to add the ALT string to the "Special-Use The IANA is requested to add the ALT string to the "Special-Use
Domain Name" registry ([RFC6761], and reference this document. Domain Name" registry ([RFC6761], and reference this document.
4.1. Domain Name Reservation Considerations 4.1. Domain Name Reservation Considerations
This section is to satisfy the requirement in Section 5 of RFC6761. This section is to satisfy the requirement in Section 5 of RFC6761.
The string ".alt." (and names ending with the string .alt) are The string ".alt." (and names ending with the string .alt) are
special in the following ways: special in the following ways:
1. Users are expected to know that strings that end in .alt behave 1. Users are expected to know that strings that end in .alt behave
differently to normal DNS names. Users are expected to have differently to normal DNS names. Users are expected to have
applications running on their machines that intercept strings of applications running on their machines that intercept strings of
the form <namespace>.alt and perform special handing of them. If the form <namespace>.alt and perform special handing of them, or
the user tries to resolve a name of the form <namespace>.alt that applications themselves will recognize the strings as
without the <namespace> plugin installed, the request will leak special, and perform special handling. If the user tries to
into the DNS, receive a negative response, and the resolution resolve a name of the form <namespace>.alt without the
will fail. <namespace> plugin installed (or in the wrong application), the
request will leak into the DNS, receive a negative response, and
the resolution will fail.
2. Writers of application software that implement a non-DNS 2. Writers of application software that implement a non-DNS
namespace are expected to intercept names of the form namespace are expected to intercept names of the form
<namespace>.alt and perform application specific handing with <namespace>.alt and perform application specific handing with
them. Other applications are not required to perform any special them. Other applications are not required to perform any special
handing (but may choose to provide helpful informational messages handing (but may choose to provide helpful informational messages
if able). if able).
3. Writers of name resolution APIs and libraries which operate in 3. Writers of name resolution APIs and libraries which operate in
the DNS context should not attempt to look these names up in the the DNS context should not attempt to look these names up in the
skipping to change at page 6, line 19 skipping to change at page 6, line 24
ending in .alt are not DNS names, and were leaked into the DNS ending in .alt are not DNS names, and were leaked into the DNS
context (for example, by a missing browser plugin). This context (for example, by a missing browser plugin). This
information may be useful for support or debugging purposes. information may be useful for support or debugging purposes.
7. DNS Registries/Registrars MUST NOT grant requests to register 7. DNS Registries/Registrars MUST NOT grant requests to register
".alt" names in the normal way to any person or entity. These ".alt" names in the normal way to any person or entity. These
".alt" names are defined by protocol specification to be ".alt" names are defined by protocol specification to be
nonexistent, and they fall outside the set of names available for nonexistent, and they fall outside the set of names available for
allocation by registries/registrars. allocation by registries/registrars.
[ Ed note: The above list (esp. 4 and 5) was changed between version Earlier versions of this document requested that .ALT be added to the
-07 and -08, and instruction to add .ALT to the "Locally Served "Locally Served Zones" registry, and that a DNSSEC insecure
Zones" registry was removed. This was in response to discussions in delegation (a delegation with no DS record) be created at the root.
the DNSOP Interim Meeting (2017-02) and discussions on the DNSOP list Significant discussion on the DNSOP list (and an interim meeting)
on "correct" behavior of leaking .alt queries and the interaction generated the consensus that these names are specifically not DNS
with DNSSEC. This topic generated in excess of 160 dense emails, but names, and that them leaking into the DNS is an error. This means
the summary was that that A: these are not DNS names (similar to that the current (non-delegated) response of NXDOMAIN is correct as
.onion), and B: a delegation would need to be inserted in the ICANN/ there is no DNS domain .alt, and so the document was updated to
IANA root zone in order to avoid SERVFAIL responses if this were remove these requests.
added to "Locally Served". The consensus was that it is better to
not request adding this to Locally Served (and so avoiding having to
ask ICANN to create a process to create a "TLD" for the purposes of
insecure delegation). ]
5. Privacy Considerations 5. Privacy Considerations
This document reserves ALT to be used to indicate that a name is not This document reserves ALT to be used to indicate that a name is not
a DNS name, and so should not attempt to be resolved using the DNS. a DNS name, and so should not attempt to be resolved using the DNS.
Unfortunately, these queries will undoubtedly leak into the DNS - for Unfortunately, these queries will undoubtedly leak into the DNS - for
example, a user may receive an email containing a hostname which example, a user may receive an email containing a hostname which
should be resolved using a specific resolution context (implemented should be resolved using a specific resolution context (implemented
by a specific application or resolution mechanism). If the user does by a specific application or resolution mechanism). If the user does
not have that particular application installed (and their stub not have that particular application installed (and their stub
skipping to change at page 7, line 34 skipping to change at page 7, line 36
Arturo Servin, Paul Vixie, Suzanne Woolf for feedback. Arturo Servin, Paul Vixie, Suzanne Woolf for feedback.
Christian Grothoff was also very helpful. Christian Grothoff was also very helpful.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997, <https://www.rfc-editor.org/info/
<http://www.rfc-editor.org/info/rfc2119>. rfc2119>.
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC
6303, DOI 10.17487/RFC6303, July 2011, 6303, DOI 10.17487/RFC6303, July 2011, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6303>. editor.org/info/rfc6303>.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, DOI 10.17487/RFC6761, February 2013, RFC 6761, DOI 10.17487/RFC6761, February 2013,
<http://www.rfc-editor.org/info/rfc6761>. <https://www.rfc-editor.org/info/rfc6761>.
[RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use
Domain Name", RFC 7686, DOI 10.17487/RFC7686, October Domain Name", RFC 7686, DOI 10.17487/RFC7686, October
2015, <http://www.rfc-editor.org/info/rfc7686>. 2015, <https://www.rfc-editor.org/info/rfc7686>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <http://www.rfc-editor.org/info/rfc7719>. 2015, <https://www.rfc-editor.org/info/rfc7719>.
8.2. Informative References 8.2. Informative References
[Dingledine2004] [Dingledine2004]
Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The
Second-Generation Onion Router", , 8 2004, Second-Generation Onion Router", , 8 2004,
<<https://svn.torproject.org/svn/projects/design-paper/ <<https://svn.torproject.org/svn/projects/design-paper/
tor-design.html>>. tor-design.html>>.
[I-D.ietf-dnsop-nsec-aggressiveuse] [I-D.ietf-dnsop-nsec-aggressiveuse]
Fujiwara, K., Kato, A., and W. Kumari, "Aggressive use of Fujiwara, K., Kato, A., and W. Kumari, "Aggressive use of
DNSSEC-validated Cache", draft-ietf-dnsop-nsec- DNSSEC-validated Cache", draft-ietf-dnsop-nsec-
aggressiveuse-08 (work in progress), January 2017. aggressiveuse-10 (work in progress), May 2017.
[I-D.ietf-dnsop-sutld-ps] [I-D.ietf-dnsop-sutld-ps]
Lemon, T., Droms, R., and W. Kumari, "Special-Use Names Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain
Problem Statement", draft-ietf-dnsop-sutld-ps-02 (work in Names Problem Statement", draft-ietf-dnsop-sutld-ps-08
progress), January 2017. (work in progress), August 2017.
Appendix A. Changes / Author Notes. Appendix A. Changes / Author Notes.
[RFC Editor: Please remove this section before publication ] [RFC Editor: Please remove this section before publication ]
From -07 to -08: From -07 to -08:
o Made it clear that this is only for non-DNS. o Made it clear that this is only for non-DNS.
o As per Interim consensus, removed the "add this to local zones" o As per Interim consensus, removed the "add this to local zones"
skipping to change at page 11, line 27 skipping to change at page 11, line 29
Warren Kumari Warren Kumari
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US US
Email: warren@kumari.net Email: warren@kumari.net
Andrew Sullivan Andrew Sullivan
Dyn Oracle
150 Dow Street 150 Dow Street
Manchester, NH 03101 Manchester, NH 03101
US US
Email: asullivan@dyn.com Email: asullivan@dyn.com
 End of changes. 20 change blocks. 
55 lines changed or deleted 60 lines changed or added

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