Applications Area S. Moonesamy
Internet-Draft
Intended Status: Informational
Expires: January 2, 2013 July 1, 2012
Domain Names in Application-Layer Protocols
draft-moonesamy-apps-domain-names-00
Abstract
Application-layer protocols generally use global addresses. The
global address is based on the Domain Name System (DNS) as it
provides a namespace structure which can used to generate a global
address. This document discusses about domain names in applications
and the history of domain names in application-layer protocols.
Status of this Memo
This Internet-Draft is submitted to IETF 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) 2012 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
Moonesamy Expires January 2, 2013 [Page 1]
Internet-Draft Domain Names in Applications July 1, 2012
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Domain Names in Application-Layer Protocols . . . . . . . . . . 3
3.1. File Transfer Protocol . . . . . . . . . . . . . . . . . . 3
3.2. Hypertext Transfer Protocol . . . . . . . . . . . . . . . . 3
3.3. Simple Mail Transfer Protocol . . . . . . . . . . . . . . . 3
4. Domain Part . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Domain Name System . . . . . . . . . . . . . . . . . . . . 3
4.2. Domain Part Syntax . . . . . . . . . . . . . . . . . . . . 4
4.3 Using the Domain Part . . . . . . . . . . . . . . . . . . . 4
5. Internationalization Considerations . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9.1. Normative References . . . . . . . . . . . . . . . . . . . 5
9.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Application-layer protocols generally use global addresses. The
global address is based on the Domain Name System (DNS) [RFC1034] as
it provides namespace where authority can be delegated. In addition,
DNS can provide the information which is necessary for applications
to exchange messages. This document discusses about domain names in
applications and the history of domain names in application
protocols.
2. History
The Simple Mail Transfer Protocol (SMTP) was specified as a standard
in RFC 821 [RFC0821]. It used the then recently introduced concept
of domains in the ARPA Internet mail system. The use of domains
changed the address space from a flat global space of simple
character string host names to a hierarchically structured rooted
tree of global addresses. The host name was replaced by a domain and
host designator which is a sequence of domain element strings
separated by periods.
It was usually assumed that a mail service would be available at a
domain name. There were situations where hosts were not accessible
Moonesamy Expires January 2, 2013 [Page 2]
Internet-Draft Domain Names in Applications July 1, 2012
over the Internet. The DNS mail-exchange (MX) Resource Record
[RFC1035] was specified RFC 974 [RFC0974] to provide routing
information which can be used to locate a mail service for a domain
name. Some general requirements which may be applicable to all
application-layer protocols were set in RFC 1123 [RFC1123]. That
document introduced the term "fully-qualified domain name" (FQDN).
3. Domain Names in Application-Layer Protocols
3.1. File Transfer Protocol
The File Transfer protocol (FTP) [RFC0959] requires IP addresses
instead of domain names to transfer files from or to a host.
3.2. Hypertext Transfer Protocol
A fully-qualified domain name is generally used by the Hypertext
Transfer Protocol (HTTP) [RFC2616] to access a resource referenced by
a Uniform Resource Identifier (URI) [RFC3986]. URIs generally
contain a fully-qualified domain name component which is intended for
lookup in the DNS.
3.3. Simple Mail Transfer Protocol
The domain part used in the Simple Mail Transfer Protocol (SMTP)
[RFC5321] are expected to be fully-qualified domain names.
4. Domain Part
The syntax of a valid Internet hostname was specified in RFC 952
[RFC0952]. The determination of what constitutes a valid hostname or
fully-qualified domain name is known as the LDH rule. Components of
a fully-qualified domain are delimited by a period ("."). The (DNS)
term "label" is used to refer to a component. A label can contain
characters such as letters, digits or hyphens. The first and last
characters in a label cannot be a hyphen.
It is recommended to use a fully-qualified domain name in an
application-layer protocol as such a domain part is globally
addressable. Using a fully-qualified domain name also ensures that
the domain part can be interpreted consistently regardless of
context.
4.1. Domain Name System
The Domain Name System (DNS) protocol [RFC1035] uses the following
syntax:
Moonesamy Expires January 2, 2013 [Page 3]
Internet-Draft Domain Names in Applications July 1, 2012
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case
<digit> ::= any one of the ten digits 0 through 9
Note that while upper and lower case letters are allowed in domain
names, no significance is attached to the case. That is, two names
with the same spelling but different case are to be treated as if
identical.
There are also some restrictions on the length [RFC1035]. A label is
63 octets or less. A (domain) name is 255 octets or less.
4.2. Domain Part Syntax
The DNS specifications provide general rules for constructing domain
names. Both the rules defined in the DNS specifications and the
application-layer protocol specification are applicable for a domain
part.
RFC 5321 [RFC5321] uses the following Augmented Backus-Naur Form
(ABNF) [RFC5234]:
Domain = sub-domain *("." sub-domain)
sub-domain = Let-dig [Ldh-str]
Let-dig = ALPHA / DIGIT
Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
To ensure consistency, this syntax is recommended when designing a
new application-layer protocol which defines a domain part.
4.3 Using the Domain Part
Moonesamy Expires January 2, 2013 [Page 4]
Internet-Draft Domain Names in Applications July 1, 2012
Application-layer protocols use the domain part in different ways.
In HTTP, for example, the domain part can be resolved to an IP
address to connect to the target host. In SMTP, the target host is
not necessarily the final destination of a message; the domain part
can be used to derive routing information.
5. Internationalization Considerations
RFC 5890 [RFC5890] discusses about Internationalized Domain Names for
Applications (IDNA). It is recommended that application-layer
protocol implementers read the document if they are taking decisions
about the handling of domain name strings.
6. Security Considerations
The DNS security extensions, known as DNSSEC [RFC4033], provides
origin authentication and integrity assurance services for DNS data.
Any application should use a security-aware resolver for DNS queries.
7. IANA Considerations
This document does not require any action from IANA.
[RFC Editor: Please remove this section]
8. Acknowledgments
The idea for this document came up after the author read a message
from Barry Leiba about the domain names. Some parts of the document
would never have been written if John Klensin did not patiently
explain why the author was wrong in discussions about RFC 5321. The
author would like to thank Craig Partridge for taking the time to
reply to a question about RFC 974 a few years ago. David H. Crocker
introduced the term "global address" in RFC 822. Parts of Section
4.1 was extracted from RFC 1035 written by P. Mockapetris. Section
4.2 is from RFC 5321 written by John Klensin.
9. References
9.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
Moonesamy Expires January 2, 2013 [Page 5]
Internet-Draft Domain Names in Applications July 1, 2012
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008.
9.2. Informative References
[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10,
RFC 821, August 1982.
[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
9, RFC 959, October 1985.
[RFC0974] Partridge, C., "Mail routing and the domain system", STD
10, RFC 974, January 1986.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[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.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010.
Authors' Addresses
S. Moonesamy
76, Ylang Ylang Avenue
Quatre Bornes
Mauritius
Moonesamy Expires January 2, 2013 [Page 6]
Internet-Draft Domain Names in Applications July 1, 2012
EMail: sm+ietf@elandsys.com
Moonesamy Expires January 2, 2013 [Page 7]