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] [IDOT] [SAC053] 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]