Internet DRAFT - draft-lewis-user-assigned-tlds
draft-lewis-user-assigned-tlds
Independent Submission E. Lewis
Internet-Draft ICANN
Expires: September 9, 2015 Date: March 9, 2015
User Assigned ISO 3166-1 Alpha-2 Codes
and the DNS Root Zone
draft-lewis-user-assigned-tlds-00
Abstract
The practice governing the delegation of ASCII two-letter domain names in
the DNS root zone is to follow the ISO 3166-1 standard?s alpha 2 codes.
This standard is maintained by the ISO 3166 Maintenance Agency. Contained
within the gamut of ISO 3166-1 alpha 2 codes is a set of values designated
as User Assigned. This document recommends that values designated as user
assigned be reserved from delegation in the root zone. A specific range of
these codes is assigned expressly for private-use.
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 http://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 September 9, 2015.
Copyright Notice
Copyright (c) 2015 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
(http://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
0. NOTE TO RFC EDITOR AND REVIEWERS . . . . . . . . . . . . . . 1
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Private-Use Top-Level Domains . . . . . . . . . . . . . . . . 1
3. Future-User Top-Level Domains . . . . . . . . . . . . . . . . 1
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 1
5. Security Considerations . . . . . . . . . . . . . . . . . . . 1
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 1
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 1
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 1
0. NOTE TO RFC EDITOR AND REVIEWERS
A suitable venue for discussion of this document is the dnsop working
group. Private comments may also be directed at the editor.
This section (and sub-sections) should be removed prior to publication.
There is potential use of standards track language. For now "MUST NOT/
are not" is in the document, hedging the issue of what track this takes.
This is a -00, comments expected. ;)
1. Introduction
The practice governing the delegation of ASCII two-letter domain names in
the DNS [STD 13] root zone is to follow the ISO 3166-1 standard [ISO3166-1].
The ISO 3166-1 standard provides for multiple types of codings, with the
ASCII two-letter codes (known as "alpha 2" codes) being used in the DNS to
potentially represent countries and territories as country-code top-level
domains (ccTLDs) [RFC1591]. The interrelationship is documented in "ICANN
and the ISO, A Common Interest in ISO Standard 3166" [ICANNISO].
In addition to these assigned codes, there are values designated as "User
Assigned". This document recommends that these values designated as Special
Use Domain Names [RFC 6761] be set-aside from possible delegation in the
root zone to enable applications and usages that are either non-global or
use DNS-like identifiers.
Quoting ISO 3166-1:2013 clause 8.1.3 "User-assigned code elements":
"If users need code elements to represent country names not included
in this part of ISO 3166, the series of letters AA, QM to QZ, XA to
XZ, and ZZ, and the series AAA to AAZ, QMA to QZZ, XAA to XZZ, and
ZZA to ZZZ respectively and the series of numbers 900 to 999 are
available.
NOTE Users are advised that the above series of codes are not
universals, those code elements are not compatible between different
entities."
For the purposes of this document, ISO 3166-1 "alpha-2 user-assigned codes"
are defined to be AA, QM to QZ, XA to XZ, and ZZ. The ranges ("to") are
alphabetic and contain only characters in the US-ASCII definition [RFC20].
The codes are case insensitive.
2. Private-Use Top-Level Domains
Two areas of identifier use have been identified that can benefit from the
use of private-use namespace:
1. Local-only usage. In locally configured environments where
Internet traffic will not traverse the global Internet. While it is
preferred that such usages use sub-domains within another domain
registered for the specific hosting entity, not all such configurations
have such a domain available. This is analogous to the use of private
addressing described in [RFC 1918].
2. Use by DNS-like applications. Some applications use network identifiers
that are similar in appearance to domain names, and may be interpreted
by software as domain names, but are not intended to use the global
DNS resolution service (such as connecting to the DNS root servers via
port 53 and performing recursive lookups). Using namespace allocated
for private-use will guard against conflicts with the global DNS
resolution system.
This document sets aside the range XA to XZ for as private-use TLDs that can
be used to support these two functions. The permanent reservation of these
user-assigned codes for this purpose by the standard allows for the
assumption that these codes will never risk requiring delegation through
future assignment to represent a country or territory.
3. Future-Use Top-Level Domains
It is unclear which future applications may require specific top-level
domains for which delegation and assignment through the regular root zone
management process is not appropriate. This document sets aside the
remaining user-assigned codes AA, QM to QZ, and ZZ, for such purposes.
These codes are reserved for future protocol uses to be defined by a future
Standards Track RFC that updates this document.
4. IANA Considerations
There currently exists an IANA registry of Special Use Domain Names, where
the alpha-2 user-assigned codes are to be added. The procedure for adding
names to that registry is defined in "Special-Use Domain Names" [RFC 6761].
The documented procedure is heavily dependent on demonstrated protocol use
of a name that justifies being reserved on the basis of "special use."
This proposal is not based on demonstrated use but rather the need to
provide clarity on what "User Assigned" means in the context of the root
zone, and to document that practice governing delegation in the root zone.
So while this proposal fails the test of RFC 6761, based on other merits,
the alpha-2 user-assigned codes ought to be added to that registry.
This proposal notes that other users of the ISO 3166-1 standard have used
"User Assigned" for other purposes. For example, "XK" is reportedly used in
other applications as a temporary country-code to represent Kosovo. This
reservation means that these User Assigned codes MUST NOT(/are not) be used
in the root zone for applications such as country-code top-level domains.
IANA is requested to:
1. add the alpha-2 user-assigned codes XA to XZ to the Special Use Domain
Names registry, designated as "Private Use".
2. add the alpha-2 user-assigned codes AA, QN to QZ, and ZZ as "Future Use".
4.1 Domain Name Reservation Considerations
Borrowing from RFC 6761, these are necessary definitions of strings
included in the Special Use Domain Name registry.
1. Users:
Are human users expected to recognize these names as special and
use them differently? In what way?
Not necessarily. Applications may decide to use names that end with the
alpha-2 user-assigned codes XA to XZ in scenarios where the name usage may
be confused or conflict with the DNS but without the intention of placing
data in the DNS. This is up to the application and (human) user.
2. Application Software:
Are writers of application software expected to make their
software recognize these names as special and treat them
differently? In what way? (For example, if a human user enters
such a name, should the application software reject it with an
error message?)
Applications may elect to use names ending with the alpha-2 user-assigned
codes XA to XZ for usages where the domain is neither required nor intended
to be placed in the root zone. The purpose of the reservation is to ensure
that any such use is not disrupted by additions to the root zone.
3. Name Resolution APIs and Libraries:
Are writers of name resolution APIs and libraries expected to
make their software recognize these names as special and treat
them differently? If so, how?
General purpose API's and libraries interacting with DNS need not be aware
of the special use of names ending in alpha-2 user assigned codes. Turnkey
API's and libraries can elect to treat names specially and avoid contacting
the root zone to resolve a name.
4. Caching DNS Servers:
Are developers of caching domain name servers expected to make
their implementations recognize these names as special and treat
them differently? If so, how?
No, no change to the basic DNS protocol elements.
5. Authoritative DNS Servers:
Are developers of authoritative domain name servers expected to
make their implementations recognize these names as special and
treat them differently? If so, how?
No, no change to the basic DNS protocol elements.
6. DNS Server Operators:
Does this reserved Special-Use Domain Name have any potential
impact on DNS server operators? If they try to configure their
authoritative DNS server as authoritative for this reserved name,
will compliant name server software reject it as invalid? Do DNS
server operators need to know about that and understand why?
Even if the name server software doesn't prevent them from using
this reserved name, are there other ways that it may not work as
expected, of which the DNS server operator should be aware?
No, the reservations do not, but if names ending with the alpha-2
user-assigned codes are seen in queries, the replies, if stemming from the
root zone, will be RCODE=NXDOMAIN [RFC 2308].
7. DNS Registries/Registrars:
How should DNS Registries/Registrars treat requests to register
this reserved domain name? Should such requests be denied?
Should such requests be allowed, but only to a specially-
designated entity? (For example, the name "www.example.org" is
reserved for documentation examples and is not available for
registration; however, the name is in fact registered; and there
is even a web site at that name, which states circularly that the
name is reserved for use in documentation and cannot be
registered!)
Policy regarding registration of domain name labels is defined in other
operational documents. (There is a difference between registration and
delegation of names.)
4.2 Other considerations
Other uses of domain names are to consider any names ending in alpha-2
user-assigned codes XA to XZ are reserved for private use. i.e., Issuance
of an Extended Validation Certificate [EVValidation] with a name contained
in the subjectAltName:dNSName field ending in an alpha-2 user-assigned code
XA to XZ as a name not registered properly under the root zone.
5. Security Considerations
Names appearing to be domain names ending in alpha-2 user-assigned codes
will be independent of the root zone, hence nothing can be said about their
security implications from the root zone perspective. Within the root zone
context, the names are not delegated but reported as reserved for this
purpose and noted in the IANA Special Use Domain Name registry.
6. Acknowledgements
David Conrad, Jaap Akkerhuis, Kal Feher, Andrew Sullivan, Kim Davies[6] so
far have played a role.
7. References
7.1. Normative References
[STD 13] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987 and Mockapetris, P.,
"Domain names - implementation and specification",
STD 13, RFC 1035, November 1987.
[RFC 20] Cerf, V., "ASCII format for network interchange",
STD 80, RFC 20, October 1969.
[RFC 1591] Postel, J., "Domain Name System Structure and Delegation",
RFC 1591, March 1994.
[RFC 1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC 2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
RFC 2308, March 1998.
[RFC 6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, February 2013.
[ISO 3166-1] ISO 3166-1:2013 "Codes for the representation of names of
countries and their subdivisions -- Part 1: Country codes"
7.2. Informative References
7.3. URIs
[ICANN ISO] https://www.icann.org/resources/pages/
icann-iso-3166-2012-05-09-en
[EVValidation] https://cabforum.org/wp-content/uploads/EV-V1_5_2Libre.pdf
8. Author's Address
Edward Lewis
ICANN
801 17th Street NW
Suite 401
Washington DC, 20006 US
edward.lewis@icann.org
Lewis Expires September 9, 2015 [Page 1]
