INTERNET-DRAFT S. Moonesamy
Intended Status: BCP
Expires: January 14, 2014 July 13, 2013
The case of dotless domains
draft-moonesamy-dotless-domains-00
Abstract
The Charleston Road Registry sent a letter to the Internet
Corporation for Assigned Names and Numbers Board requesting
permission to expand its application for ".search" to run that
generic top-level domain (gTLD) as a dotless domain.
This memo discusses about the case of the dotless domains in terms of
the technical standards published by the IETF.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2013 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
S. Moonesamy Expires January 14, 2014 [Page 1]
INTERNET DRAFT The case of the dotless domains July 13, 2013
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
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Dotless domains . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Search List . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Domain names in Application Protocols . . . . . . . . . . . . . 4
4.1. File Transfer Protocol . . . . . . . . . . . . . . . . . . 4
4.2. Hypertext Transfer Protocol . . . . . . . . . . . . . . . . 4
4.3. Internet Message Access Protocol . . . . . . . . . . . . . 4
4.4. Simple Mail Transfer Protocol . . . . . . . . . . . . . . . 4
4.5. Extensible Messaging and Presence Protocol . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 5
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
S. Moonesamy Expires January 14, 2014 [Page 2]
INTERNET DRAFT The case of the dotless domains July 13, 2013
1. Background
On April 6, 2013 the Charleston Road Registry, wholly owned by
Google, sent a letter [CRR] to the Internet Corporation for Assigned
Names and Numbers (ICANN) Board requesting permission to expand its
application for ".search" to run that generic top-level domain (gTLD)
as a dotless domain. According to the letter the proposed ".search"
gTLD will signal to the general population of Internet users that
".search" websites are indeed websites that offer search
functionality, adhering to basic technical standards and providing
users with a simple, common interface.
On July 10, 2013 the Internet Architecture Board (IAB) issued a
statement on dotless domains [IDOT]. According to the statement the
IAB believes that ICANN Security and Stability Advisory Committee
report on dotless domains [SAC053] is a reasonable summary of the
technical problems that arise from the implementation of dotless
domains. The Internet Engineering Task Force (IETF) takes no
position on the accuracy or inaccuracy of the technical analysis in
the IAB statement or in the ICANN report.
This memo discusses about the case of the dotless domains in terms of
the technical standards published by the IETF.
2. Dotless domains
A domain name [RFC1034] usually contains two or more components,
known as labels, with a dot (".") used to separate each label. As an
example, the "www.example.net" domain name has three labels, "www",
"example" and "net".
A host contains a a DNS resolver which converts domain names to IP
addresses. Currently, "www.example.net" or "example.net" can be
resolved to an IP address. There is an assumption that "net" cannot
be resolved to an IP address; i.e. a domain name shall comprise two
or more labels. A dotless domain is a domain name which contains one
label only.
3. Search List
When the user enters a name, the domain names in the search list are
used as suffixes to the user-supplied name, one by one, until a
domain name with the desired associated data is found, or the search
list is exhausted [RFC1123]. The search list expander can require
two or more interior dots in a generated domain name before it tries
the user-supplied name in a query. An implementation is only
conditionally compliant with the requirements for Internet hosts
[RFC1123] if it does not follow the search list expander requirement.
S. Moonesamy Expires January 14, 2014 [Page 3]
INTERNET DRAFT The case of the dotless domains July 13, 2013
4. Domain names in Application Protocols
The syntax of a legal hostname was specified in RFC 952 [RFC0952] and
modified in RFC 1123 [RFC1123]. "hostname" and domain name" are used
interchangeably in the specifications about application protocols.
This section discusses about the usage of domain names in these
specifications.
4.1. File Transfer Protocol
The File Transfer Protocol (FTP) is specified in RFC 959 [RFC0959].
There is a presumption that a FTP implementation will follow the
requirements set in RFC 1123 [RFC1123].
4.2. Hypertext Transfer Protocol
The Hypertext Transfer Protocol (HTTP) is specified in RFC 2616
[RFC2616]. According to RFC 2616, if a proxy receives a host name
which is not a fully qualified domain name, it may add its domain to
the hostname it received. If a proxy receives a fully qualified
domain name, the proxy must not change the hostname.
The Uniform Resource Identifier (URI) [RFC3896] specification defines
the hostname component used for HTTP. According to the specification,
the syntax is defined in Section 3.5 of [RFC1034] and Section 2.1 of
[RFC1123]. RFC 3896 [RFC3896] does not restrict the hostname beyond
what is necessary for interoperability.
4.3. Internet Message Access Protocol
The Internet Message Access Protocol (IMAP version 4rev 1) is
specified in RFC 3501 [RFC3501]. The specification does not contain
any restriction which prevents a dotless domain from being used.
4.4. Simple Mail Transfer Protocol
The Simple Mail Transfer Protocol (SMTP) is specified in RFC 5321
[RFC5321]. According to RFC 5321, a domain name (or often just a
"domain") consists of one or more components, separated by dots if
more than one appears. In the case of a top-level domain used by
itself in an email address, a single string is used without any dots.
The ABNF syntax [RFC5324] is as follows:
Domain = sub-domain *("." sub-domain)
There isn't any restriction in RFC 5321 [RFC5321] which prevents a
dotless domain from being used.
S. Moonesamy Expires January 14, 2014 [Page 4]
INTERNET DRAFT The case of the dotless domains July 13, 2013
4.5. Extensible Messaging and Presence Protocol
The Extensible Messaging and Presence Protocol (XMPP) is specified in
RFC 6120 [RFC6120]. The specification mentions that fully qualified
domain names (FQDNs) are typically resolved in DNS.
5. Security Considerations
RFC 6125 [RFC6125] specifies procedures for representing and
verifying the identity of application services. Given that dotless
domains have been used in local environments it is not possible to
provide any assurance about whether dotless domains can be safely
used on the Internet.
6. Conclusion
The rule of separation is a principle which states that policy and
technical mechanisms are kept separate. IETF specifications usually
provide guidance to ensure interoperability. Whether dotless domains
are harmful or not is a policy matter.
The rule of least surprise is a principle which states that it is
better to always do the less surprising thing. Implementations of
application protocols (see Section 4) can exhibit unexpected behavior
in processing dotless domains. RFC 1034 recommends that the prudent
user selects a domain name which satisfies both the rules of the
domain system and any existing rules for the object, whether these
rules are published or implied by existing programs. Dotless domains
do not fit within the rule of least surprise.
7. IANA Considerations
[RFC Editor: please remove this section]
8. References
8.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
8.2. Informative References
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
host table specification", RFC 952, October 1985.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD
S. Moonesamy Expires January 14, 2014 [Page 5]
INTERNET DRAFT The case of the dotless domains July 13, 2013
9, RFC 959, October 1985.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, October 1989.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5324] DeSanti, C., Maino, F., and K. McCloghrie, "MIB for Fibre-
Channel Security Protocols (FC-SP)", RFC 5324, September
2008.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
[CRR] <http://www.icann.org/en/news/correspondence/falvey-to-willett-
06apr13-en.pdf>
[IDOT] <http://www.ietf.org/mail-archive/web/ietf-
announce/current/msg11669.html>
[SAC053] <http://www.icann.org/en/groups/ssac/documents/sac-053-
en.pdf>
Author's Addresses
S. Moonesamy
76, Ylang Ylang Avenue
Quatre Bornes
Mauritius
Email: sm+ietf@elandsys.com
S. Moonesamy Expires January 14, 2014 [Page 6]