Internet DRAFT - draft-pfrc-2181-name-syntax
draft-pfrc-2181-name-syntax
INTERNET-DRAFT Declan Ma, Ed.
Intended Status: Proposed Standard zDNS Ltd.
Expires: 2015-10-15 2015-05-22
DNS Name Syntax
draft-pfrc-2181-name-syntax-00
Abstract
RFC 2181 collected eight independent considerations and created a single
docuement to address each of them in turn. Over the following two decades
it has become clear that each of these items should be considered and evovolve
in its own right, as suggested in RFC 2181. This document extracts the exact
text from RFC 2181 and places it into its own track.
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) 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
Declan Ma, Ed. Expires 2015-10-15 [Page 1]
INTERNET DRAFT DNS Name Syntax 2015-05-22
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Name syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4 Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 4
Declan Ma, Ed. Expires 2015-10-15 [Page 2]
INTERNET DRAFT DNS Name Syntax 2015-05-22
1 Introduction
This document is intended to describe the issue of what makes a valid
DNS label.
2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3 Name syntax
Occasionally it is assumed that the Domain Name System serves only
the purpose of mapping Internet host names to data, and mapping
Internet addresses to host names. This is not correct, the DNS is a
general (if somewhat limited) hierarchical database, and can store
almost any kind of data, for almost any purpose.
The DNS itself places only one restriction on the particular labels
that can be used to identify resource records. That one restriction
relates to the length of the label and the full name. The length of
any one label is limited to between 1 and 63 octets. A full domain
name is limited to 255 octets (including the separators). The zero
length full name is defined as representing the root of the DNS tree,
and is typically written and displayed as ".". Those restrictions
aside, any binary string whatever can be used as the label of any
resource record. Similarly, any binary string can serve as the value
of any record that includes a domain name as some or all of its value
(SOA, NS, MX, PTR, CNAME, and any others that may be added).
Implementations of the DNS protocols must not place any restrictions
on the labels that can be used. In particular, DNS servers must not
refuse to serve a zone because it contains labels that might not be
acceptable to some DNS client programs. A DNS server may be
configurable to issue warnings when loading, or even to refuse to
load, a primary zone containing labels that might be considered
questionable, however this should not happen by default.
Note however, that the various applications that make use of DNS data
can have restrictions imposed on what particular values are
acceptable in their environment. For example, that any binary label
can have an MX record does not imply that any binary name can be used
as the host part of an e-mail address. Clients of the DNS can impose
whatever restrictions are appropriate to their circumstances on the
values they use as keys for DNS lookup requests, and on the values
Declan Ma, Ed. Expires 2015-10-15 [Page 3]
INTERNET DRAFT DNS Name Syntax 2015-05-22
returned by the DNS. If the client has such restrictions, it is
solely responsible for validating the data from the DNS to ensure
that it conforms before it makes any use of that data.
See also [RFC1123] section 6.1.3.5.
4 Security Considerations
It may be observed that in section 3.2.1 of RFC1035, which defines
the format of a Resource Record, that the definition of the TTL field
contains a throw away line which states that the TTL of an SOA record
should always be sent as zero to prevent caching. This is mentioned
nowhere else, and has not generally been implemented. Implementations
should not assume that SOA records will have a TTL of zero, nor are
they required to send SOA records with a TTL of zero.
5 References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[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.
[RFC2199] Ramos, A., "Request for Comments Summary RFC Numbers 2100-
2199", RFC 2199, January 1998.
6 Authors' Addresses
Declan Ma, Ed.
ZDNS Ltd.
4, South 4th Street, Zhongguancun,
Haidian, Beijing 100190,
China
Declan Ma, Ed. Expires 2015-10-15 [Page 4]
