[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/