[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[idn] draft-hall-dns-datatypes-00.txt
- To: IDN <idn@ops.ietf.org>
- Subject: [idn] draft-hall-dns-datatypes-00.txt
- From: "Eric A. Hall" <ehall@ehsco.com>
- Date: Fri, 28 Jun 2002 09:30:08 -0500
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530
I've submitted the attached I-D to the draft editor but since it probably
won't appear in the pool for a while...
This will eventually have to be dealt with in DNSEXT but if anybody here
has any substantive changes that need to be made, I'd like to get those
addressed in an updated draft beforehand.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
INTERNET-DRAFT Eric A. Hall
Document: draft-hall-dns-datatypes-00.txt June 2002
Expires: December 2002
Domain Name Data-Types
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
This document defines syntax and structural rules for a namespace
of internationalized domain names, and also clarifies the syntax
and structural rules for the existing DNS namespace. Furthermore,
this document defines syntax and structural rules for specific
types of labels and domain names, and also defines usage rules for
specific resource records within the domain name system. This
document specifically does not describe any mechanisms for
interacting with these namespaces, domain names or resource
records, but instead focuses exclusively on the syntax and
structural rules.
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
Table of Contents
1. Abstract.................................................1
2. Introduction.............................................3
3. Background and Overview..................................3
4. The Namespaces...........................................7
4.1. The Class IN Hierarchy.................................7
4.2. The DNS Namespace......................................9
4.2.1. Length Restrictions in the DNS Namespace.............9
4.2.2. Characters Restrictions in the DNS Namespace........10
4.2.3. The DNS Namespace Escape Syntax.....................11
4.3. The Internationalized Namespace.......................13
4.3.1. Length Restrictions in the i18n Namespace...........14
4.3.2. Character Restrictions in the i18n Namespace........15
5. The DNS Data-Types......................................16
5.1. Syntax Validation.....................................16
5.2. Defining New Data-Types...............................17
5.3. The Root Label and Domain Name........................18
5.4. The Hostname Labels and Domain Names..................19
5.4.1. Legacy Hostnames....................................19
5.4.2. Internationalized Hostnames.........................20
5.5. The Octet Label and Domain Name.......................21
5.6. The Mailbox Labels and Domain Names...................22
5.6.1. Legacy Mailboxes....................................23
5.6.2. Internationalized Mailboxes.........................24
5.7. The Service Locator Labels and Domain Names...........24
5.7.1. Legacy Service Locators.............................24
5.7.2. Internationalized Service Locators..................25
6. Resource Records and Query Types........................25
6.1. Resource Records......................................25
6.2. Query Types...........................................34
7. Security Considerations.................................35
8. IANA Considerations.....................................35
9. References..............................................36
10. Acknowledgements........................................38
11. Author's Address........................................39
Hall I-D Expires: December 2002 [page 2]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
2. Introduction
The IDN working group has been developing mechanisms for
supporting and interacting with internationalized domain names,
although a prerequisite to the completion of any such work is the
description of the internationalized namespace itself. During this
work, it has also been determined that certain clarifications to
the existing DNS namespace are also necessary.
Encodings, protocols and other mechanisms for accessing domain
names and resource records within the internationalized namespace
are purposefully not described in this document.
Discussion of this document and related work items is currently
being held on the "idn@ops.ietf.org" mailing list. To join the
list, send a message to <idn-request@ops.ietf.org> with the single
word "subscribe" in the body of the message.
Subsequent versions of this draft will be brought to DNSEXT for
standards-track development, and will be discussed on the
"namedroppers@ops.ietf.org" mailing list. To join that list, send
a message to <namedroppers-request@ops.ietf.org> with the single
word of "subscribe" in the body of the message.
3. Background and Overview
The Internet (and the ARPANET before it) has had a formal
namespace of network resources since RFC 608 [RFC608]. Over the
years, however, the syntax rules associated with the global
namespace have been changed, with various updates and
clarifications being provided in RFC 810 [RFC810], RFC 882
[RFC882], RFC 952 [RFC952], RFC 1034 [RFC1034], RFC 1123 [RFC1123]
and RFC 2181 [RFC2181], with each revision expanding upon the
namespace syntax to accommodate a more flexible usage model.
The original namespace of network resources defined in [RFC608]
used a flat HOSTS.TXT database as a simple list of systems and
their network addresses, using a limited subset from the seven-bit
US-ASCII charset [ASCII] for the system names. Essentially, the
database format was the namespace, with all network services using
this one-dimensional namespace for the purpose of specifying
systems by name, regardless of whether these hostnames were used
for intra-protocol services or for subsequent lookup operations.
Hall I-D Expires: December 2002 [page 3]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
The format of the underlying database (and thus the namespace) was
redefined by [RFC810] to reflect the coexistence of ARPANET and
Internet networks and nodes, redefined again by [RFC952] to allow
for multi-label hostnames, and updated in [RFC1123] to slightly
expand the allowable character repertoire. Throughout these
revisions, the syntax of the namespace was changed somewhat,
although it continued to be one-dimensional in nature, reflecting
the limitations of the underlying HOSTS.TXT database file.
Once the Domain Name System (DNS) specifications were published
(first in [RFC882] and RFC 883 [RFC883], then later in [RFC1034]
and RFC 1035 [RFC1035]), the database of network resources and the
hostname syntax separated into distinct entities. Although DNS
uses an eight-bit syntax internally and allows any of the eight-
bit codepoint values to be used for any purposes, most
applications and protocols restrict their usage of the namespace
to well-known data-types which only use subsets of the available
namespace. This has resulted in a distinctly layered namespace,
where applications and protocols use the data-type subsets, while
the DNS itself uses the full range of characters.
For example, [RFC1034] states that "the old rules for HOSTS.TXT
should be followed" for domain names which reference host systems,
and most of the application protocols have followed this advice.
For all practical purposes, this means that the legacy hostname
syntax is implicitly a strong data-type with formal syntax rules,
even though it only represents a subset of the global DNS
namespace. Meanwhile, a variety of protocol-specific data-types
have also been defined for network resources which are not hosts,
and these data-types have also been implemented by applications
which work with those kinds of resources.
In the end, the DNS namespace essentially exists as two separate
layers, with the namespace at large being defined by the
underlying DNS service, but with applications and protocols using
the data-types and syntax rules which reflect their usage.
Moving forward, the IDN working group has developed an
internationalized namespace which uses characters from the
Universal Character Set (UCS) [ISO-10646] (a.k.a. Unicode
[UNICODE])]. Note that the UCS (and thus the namespace) only
defines characters and their logical codepoint values, while
external codecs are required to encode the canonical UCS
characters into sequences which are suitable for specific
environments. As such, the canonical UCS characters cannot be
Hall I-D Expires: December 2002 [page 4]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
exchanged in their raw form, but instead can be only exchanged in
their encoded form.
Furthermore, there are no characters in the UCS character
repertoire for "octet value 0xHH", so the internationalized
namespace cannot directly support the eight-bit values used in the
DNS namespace. For these reasons, the internationalized and DNS
namespaces have to be defined and managed separately, with the
internationalized namespace representing logical UCS characters,
and with the DNS namespace representing raw and uninterpreted
eight-bit values. However, these namespaces can coexist within the
class IN database hierarchy as long as the underlying domain names
are encoded in a compatible and consistent form. At that point,
the only substantive difference between the two namespaces is in
the canonical characters which are used by the presentation-layer
namespaces at large.
Cumulatively, this means that the internationalized namespace
operates at three distinct layers. First of all, applications and
protocols have to choose an internationalized data-type which is
capable of supporting the characters they need for their domain
names, while the protocols also have to choose the encoding
formats they will use for the domain names that they exchange.
Meanwhile, the end-system applications may need to use another
encoding format whenever they map these domain names to the
available lookup service(s).
| HOSTS.TXT | DNS Names | IDNs |
--------------+---------------+---------------+---------------+
Application | database | protocol | data-type |
Presentation | subset | subset | specific |
| | | (UCS range) |
--------------+---------------+---------------+---------------+
Protocol | database | data-type | protocol |
Transfer | subset | specific | encoding |
| | (7- or 8-bit) | (7- or 8-bit) |
--------------+---------------+---------------+---------------+
Subsequent | HOSTS.TXT | 8-bit DNS | 8-bit DNS |
Lookups | subset | or HOSTS.TXT | or HOSTS.TXT |
| | subset | subset |
--------------+---------------+---------------+---------------+
Figure 1: Logical namespace layers and their representations.
The different models which have been described in this section are
illustrated in Figure 1 above. As can be seen, the hostname syntax
Hall I-D Expires: December 2002 [page 5]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
defined for use with the HOSTS.TXT database essentially provided a
monolithic and one-dimensional namespace for applications to use,
while the DNS namespace provides multiple data-types for
applications and protocols to use, with these data-types
representing logical subsets of the underlying eight-bit
namespace. Finally, the internationalized namespace also uses
logical data-types for the applications and protocols, but also
requires that protocols define encoding formats for the domain
names they use internally, and for the domain names they pass to
the underlying lookup services.
Collectively, there are a variety of different data elements
discussed above which require definitions or clarifications.
Originally, this document was only meant to provide definitions
for the internationalized namespace and its associated data-types,
although several issues with the DNS namespace and data-types have
also been encountered which require clarifications and definitions
of their own. In particular, since the internationalized namespace
is unable to use the eight-bit codepoint values from the DNS
namespace, the legacy hostname data-type must be defined with an
explicit syntax and its usage must be restricted to specific
scenarios in order for those domain names to be accessible from
the internationalized namespace. Subsequently, this requires that
DNS resource records also be redefined to use the data-types which
are appropriate to the data they represent, thereby ensuring that
host resources in the common hierarchy are always accessible to
both namespaces.
On the surface, some of this work may appear to be a reversal of
existing standards, since the DNS specifications and the
clarifications made in [RFC2181] explicitly allow eight-bit
codepoint values to be used with any domain name. In truth,
however, this redefinition is a codification of existing practices
and recommendations. Specifically, this document encourages
applications to define their own data-types and syntax rules when
needed but also requires that the common hostname syntax be
supported in those places where hosts are specifically referenced,
which is essentially a restatement of the [RFC1034] requirements.
The only real difference here is that this document also requires
that resource records be explicitly restricted to use the
appropriate data-types, rather than being allowed to diverge at
will. While this is a reversal of policy as defined in [RFC2181],
this is necessary in order to ensure basic interoperability across
the different namespaces, and is also necessary in order to
Hall I-D Expires: December 2002 [page 6]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
prevent basic interoperability problems from developing due to
fragmentation of the class IN hierarchy.
4. The Namespaces
Conceptually, the DNS namespace and the internationalized
namespace are separate, in that they allow for different ranges of
characters, with the namespaces containing different identifiers.
However, both of the namespaces reside in the class IN hierarchy
and share a common root in that class, and are effectively the
same namespace when the identifiers have been encoded into a
compatible and consistent form.
Applications and protocols which specifically utilize any of the
data-types defined in this document MUST conform to the syntax
rules associated with the parent namespace for that data-type. For
example, if an application specifically claims to support the
internationalized hostname data-type then that application MUST
conform to the requirements associated with the internationalized
namespace at large, while applications which claim to conform to
the legacy mailbox data-type MUST conform to the requirements of
the DNS namespace.
If a protocol supports some other external namespace (such as LDAP
directories), then the syntax rules for that protocol SHOULD
define specific handling rules which clearly state how that
protocol will use each of the namespaces defined here.
4.1. The Class IN Hierarchy
The IN class use a hierarchical structure, where each domain name
is represented by a series of labels, and where the entire
sequence of labels represents a globally-unique domain name in the
hierarchy. Essentially, the IN class hierarchy represents the
database portion of the DNS, and therefore represents the storage,
transfer and processing services which are used to construct the
DNS namespace. Note that the namespace syntax (such as length and
character restrictions) is discussed separately in section 4.2.
Also note that alternative classes may have their own structural
rules which are different from those used in the IN class.
When a domain name from the IN class is used in the DNS, the
constituent labels are typically treated as binary sequences (but
not always), with each label being prefaced by a length indicator.
Hall I-D Expires: December 2002 [page 7]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
The labels are ordered from right-to-left, with the least-specific
label at the right edge of the domain name, and with the most-
specific labels at the left edge. The right-most label will have a
length indicator with the value of zero (it is truly a null
label), and represents the root of the class IN hierarchy which is
by definition the least-specific label in the hierarchy.
When a domain name is used for lookups, the entire sequence of
labels act as a lookup key against a globally-distributed
hierarchy of database partitions and their leaf-nodes. Some or all
of the labels will identify a specific database partition in the
hierarchy, while any remaining labels will identify a particular
leaf-node within a partition. As a lookup is processed, the input
domain name is matched against the contents of the current
partition, with the results of this comparison operation either
being a referral to another partition, an answer, or an error. If
a referral is returned, the matching process is restarted at the
referenced partition, with this process repeating until either an
answer or an error is returned.
Domain names from the DNS namespace which are written out in
longhand form are usually written as character sequences, with the
labels typically being separated by a Full-Stop character (0x2E)
from [ASCII]. When used with longhand domain names in the
internationalized namespace, the separator mark is either a
trailing Full-Stop (U+002E), an Ideographic Full-Stop (U+3002), an
Ideographic Full-Width Full-Stop (U+FF0E), or an Ideographic Half-
Width Full-Stop (U+FF61) from the UCS. When any of the ideographic
forms are used, they MUST be converted to the traditional Full-
Stop character when the domain name labels are normalized, and
MUST NOT be exchanged with other applications or protocols in
their provided form.
Although the separator frequently appears to represent the length
indicators in the domain name system, this is not always true. For
example, domain names which are written out in longhand form do
not typically use a Full-Stop character at the beginning of the
domain name to represent the length indicator from the first
label, nor do they typically provide a trailing Full-Stop
character to represent the root of the hierarchy.
Outside of the domain name system, domain names are typically
treated as simple identifiers, with no database context being
implied. Humans normally treat domain names as simple identifiers
of named network resources, without concern for the leaf-node or
partitions which may be referenced. Meanwhile, most applications
Hall I-D Expires: December 2002 [page 8]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
and protocols also treat domain names as simple identifiers,
although many of them apply syntactical analysis to the domain
name before performing any additional processing (even in these
situations, however, the domain name will not normally be analyzed
for database context).
Note that a one-to-one match between labels, partitions and leaf-
nodes is neither required nor implied. Multiple labels may be used
to refer to a partition or a leaf-node, as desired. In most cases,
the specific database context of a domain name cannot be
determined without querying DNS directly.
4.2. The DNS Namespace
These rules represent the allowable syntax of all domain names
within the IN class hierarchy as defined by [RFC1034] and
[RFC1035]. Alternative classes may define their own namespaces and
rules. Subsets of these rules are defined for specific labels and
domain names in section 5. The rules provided in this section
specifically apply to the DNS namespace at large, and do not
define any formal data-types.
4.2.1. Length Restrictions in the DNS Namespace
A label from the DNS namespace is restricted to a minimum of one
octet and a maximum of 63 octets, inclusive.
A domain name from the DNS namespace is restricted to a minimum of
one octet and a maximum of 255 octets, inclusive. Any number of
labels may be provided in a domain name, but the maximum length
restriction MUST NOT be exceeded.
Note that many delegation bodies have defined their own minimum
length rules for their zones. For example, the historic generic
top-level domains (such as com, net and org) require a minimum of
two characters for all immediate delegations, while some of the
newer generic TLDs have three- and four-character minimums. Since
these rules only affect the delegations within those zones (and
not the subordinate delegations from the child zones), this usage
is not in conflict with any of the other rules defined in this
document, and is expressly allowed.
Whenever a domain name is written in longhand form, it SHOULD be
restricted to a maximum length which allows a direct conversion to
Hall I-D Expires: December 2002 [page 9]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
the DNS format. In particular, a longhand domain name SHOULD allow
a length indicator to be added to the first label in the DNS
domain name, and SHOULD allow a length indicator to be added to
the end of the domain name (representing the root domain), if
necessary. In the common case, a longhand domain name will only
allow for 253 octets of data so that it can be directly converted
to the DNS format.
If a longhand domain name uses the escape syntax described in
section 4.2.3, the allowable length of the longhand domain name
MAY be extended to accommodate the escape sequence, since a multi-
byte escape sequence will generally collapse to a single octet in
the DNS message.
Applications and protocols which need to specify the root domain
explicitly MUST allow a single Full-Stop character to be specified
in the longhand domain name for this purpose. Other application-
or protocol-specific syntaxes MAY also be supported for this
purpose, if necessary. Note that this usage is not required to be
supported unless the application needs to explicitly reference the
root domain for some purpose, but since the root domain is not
addressable as a host system, this is not a common scenario.
4.2.2. Characters Restrictions in the DNS Namespace
The lower seven-bit range of values (0x00 through 0x7F) from the
DNS namespace MUST be interpreted as characters from [ASCII].
The eight-bit range of values (0x80 through 0xFF) are defined in
[RFC1034] as opaque octets, with no default character assignments.
Therefore, eight-bit values from the DNS namespace MUST NOT be
interpreted as any specific charset, characters or encoding, and
SHOULD NOT be rendered as such unless the protocol in use has
defined a specific data-type which explicitly states otherwise.
When a domain name from the DNS namespace is stored, transferred
or compared, the capitalization of the [ASCII] characters in that
domain name MUST be preserved as they were provided to the current
operation. Secondarily, whenever two domain names from the DNS
namespace are compared, the [ASCII] characters in the domain names
MUST be treated as case-neutral for the purposes of comparison.
Note that these rules combine such that the capitalization of the
input domain name will be preserved across a search operation. For
example, the search input of "A.example.COM" MUST match the stored
Hall I-D Expires: December 2002 [page 10]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
domain name of "a.EXAMPLE.com", and the capitalization of the
input domain name MUST be used for the resulting output. However,
if the queried domain name referenced "HOST.c.EXAMPLE.net", that
domain name MUST be provided in its original capitalization.
In those scenarios where the input and output domain names are
different but they exist in the same branch of the class IN
hierarchy, the secondary references to the common domains MUST
inherit the capitalization of the input domain name. For example,
if the search input of "A.example.COM" matches with
"a.EXAMPLE.com" but that domain name only exists as an alias for
the domain name of "HOST.b.EXAMPLE.com", then the output domain
name MUST be provided as "HOST.b.example.COM", with the
capitalization of the input domain name being used to construct
the overlapping domain names in the output.
These rules guarantee that the output from the compression
algorithm defined in [RFC1035] is always valid. Unless a protocol
specifically states otherwise, these rules MUST be followed for
all applications and protocols which use domain names and labels
from the DNS namespace as specific data.
4.2.3. The DNS Namespace Escape Syntax
Although DNS uses raw eight-bit codepoint values, less than half
of the codepoint values have defined character equivalents from
[ASCII] which can be rendered, which means that most of the
codepoint values cannot be written in a longhand domain name which
supports those values.
For example, the octet label data-type supports 256 possible
codepoint values (0x00 through 0xFF), while the mailbox label
data-type supports all 128 of the seven-bit character codes
defined in [ASCII] (0x00 through 0x7F), but only the printable
subset of characters from [ASCII] have defined character
representations (0x21 through 0x7E). As such, longhand domain
names which use these data-types are generally restricted to the
printable subset.
Furthermore, some of these domain names make use of characters
which are "confusing" to applications and/or their resolvers. For
example, many email addresses make use of the Full-Stop character
within the local-part element, although this character can easily
be misinterpreted as a label separator rather than an embedded
Full-Stop character.
Hall I-D Expires: December 2002 [page 11]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
[RFC1035] defined a syntax for escaping these characters within
the zone database, but it does not require (nor imply) that this
mechanism should be supported in other applications, with the
result being that most of these applications do not adequately
support the necessary syntax. This document corrects this
shortcoming by requiring that any application which supports the
octet label or mailbox label data-types MUST allow longhand domain
names to use the escaping syntax defined herein.
Note that these syntax rules only apply to the octet label and
mailbox label data-types. The remaining data-types have tighter
character ranges, and do not contain characters which require
escaping. Furthermore, applications MUST NOT allow these other
data-types to use the escaping syntax whatsoever, as this could
result in unexpected characters being inserted into the label or
domain name, thereby triggering unexpected failures in other
applications or systems.
The escape syntax uses the Reverse-Solidus (0x5C) character as an
escape flag, with this flag preceding a printable [ASCII]
character or a three-digit decimal value for a specific codepoint
value. For example, if a label contains an embedded Full-Stop
character, that character may be escaped as either "\." or "\046"
(where "46" is the decimal value of the Full-Stop character's
codepoint value from [ASCII]).
This escape syntax MUST be used to encapsulate Full-Stop (0x2E),
Reverse-Solidus (0x5C), Double-Quote (0x22), a non-printing
character from [ASCII] (0x00 through 0x20, or 0x7F) or any of the
eight-bit codepoint values (0x80 through 0xFF) whenever one of
these domain names is written in longhand form. Protocols which
exchange the octet or mailbox data-types as textual data MUST
support the use of this escaping syntax within that data. Other
application- or protocol-specific syntaxes MAY also be supported
for this purpose, if necessary.
However, DNS messages MUST NOT contain the escape sequences, and
MUST always use the raw octet value of the escaped character. As
such, the escape syntax MUST be interpreted by an application or a
resolver (depending on the resolver's capabilities) before these
characters are passed into DNS.
Hall I-D Expires: December 2002 [page 12]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
4.3. The Internationalized Namespace
These rules represent the allowable syntax of all domain names
within the internationalized IN class namespace. Alternative
classes may define their own namespaces and rules. Subsets of
these rules are defined for specific labels and domain names in
section 5. Conversely, the rules provided in this section apply to
the internationalized namespace at large, and do not define any
formal data-types.
Note that the internationalized namespace is a logical namespace,
and does not exist in the same way that the DNS namespace exists.
Instead of being a direct mapping to the underlying database, the
internationalized namespace is defined as a range of UCS character
codes which may be accessed or represented with any of several
different encoding mechanisms.
Mechanisms which have been discussed for this purpose include
codecs that convert the UCS character codes into seven-bit [ASCII]
sequences compatible with the legacy hostname syntax, UCS transfer
encodings such as UTF-8, and legacy charsets which can be mapped
to the UCS repertoire. Any of these mechanisms (or any others) can
be used to represent, store, transfer and compare domain names in
the internationalized namespace, as is necessary for the
application or protocol at hand.
For example, an internationalized protocol may use UTF-8 domain
names as protocol data or arguments, although it may be necessary
to convert a domain name into a hostname-compatible encoding
whenever a lookup operation is performed. In this scenario, the
logical internationalized namespace will be accessed through two
different mechanisms, although the canonical domain name will
still be represented as the UCS characters. Similarly, conversion
between two or more access mechanisms will likely require an
intermediate conversion to UCS first, and in this regard, the
canonical UCS characters will represent the logical namespace.
Note that this document does not define or describe any codecs or
namespace-access mechanisms. However, these different mechanisms
have affected the structure and syntax rules of the
internationalized namespace at large.
Hall I-D Expires: December 2002 [page 13]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
4.3.1. Length Restrictions in the i18n Namespace
For the purposes of defining boundary conditions, a label in the
internationalized namespace is restricted to a minimum of one UCS
character and a maximum of 63 UCS characters, while a domain name
in the internationalized namespace is restricted to a maximum of
255 UCS characters, inclusive. Note that this rule specifically
refers to the canonical UCS characters, rather than any encoded
form. Encoding will often result in labels and domain names with a
fewer or greater number of octets, depending on the encoding
algorithm in use. For example, an application which uses UCS-4 to
represent internationalized domain names will require 32 bits for
each UCS character, while an application which uses UTF-8 can
require up to 48 bits for each character.
The canonical UCS characters will frequently require conversion
into a transfer encoding which will be subject to its own length
requirements. For example, the ASCII-compatible encoding mechanism
defined in [PUNYCODE] and [IDNA] is subject to the length
restrictions inherent in the DNS namespace. Although all encodings
have their own requirements, [IDNA] is the only encoding which is
known to have hard limits beyond its control. As such, labels in
the internationalized namespace MUST be restricted to lengths
which can be encoded in their [IDNA] encoded form, with the
resulting sequence being limited to the DNS namespace restrictions
defined in section 4.2.1. This rule MUST be enforced regardless of
any other codecs or access mechanisms which may be available that
offer larger sizes.
These rules combine so that an application can restrict the input
of a label or domain name (such as in a form) to a certain number
of characters, but once the internationalized domain name has been
provided and normalized into its canonical form, any subsequent
verification of that domain name MUST ensure that the [IDNA]
encoded form of that domain name will comply with the DNS
namespace limits, which is a maximum of 63 octets for a label, and
255 octets for a domain name.
As with the DNS namespace, domain names written in longhand form
MUST leave room for any omitted length indicators when these
boundary conditions are tested. In particular, this includes the
length indicator at the beginning of the first label and the
length indicator at the end of the domain name, both of which are
frequently omitted from longhand domain names.
Hall I-D Expires: December 2002 [page 14]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
4.3.2. Character Restrictions in the i18n Namespace
The logical internationalized namespace uses the entire UCS,
including character codes which are currently unassigned.
Currently the UCS occupies a 21-bit range of character code
values, containing tens of thousands of assigned characters, and
hundreds of thousands of unassigned characters, although this
repertoire is expected to grow in size over time.
Internationalized label and domain name data-types MUST declare
their own specific ranges of supportable UCS characters, and MUST
also define any normalization, case-conversion, and any other
transformations which are needed for that data-type. The
guidelines and rules for the development of these
internationalized domain name data-types are provided in
STRINGPREP [STRINGPREP].
In the normal scenario, the data-type rules will result in labels
and domain names containing case-specific, strongly-normalized UCS
characters. As a result, the internationalized namespace is case-
specific, meaning that all storage, transfer, comparison and
conversion operations MUST always preserve the capitalization and
normalization of the data as it is processed.
Since the domain name provided to the original application can be
significantly different from the domain name which is subsequently
passed to the underlying protocol, the original domain name MUST
NOT be provided to any other applications or protocols if at all
possible. Note that certain situations are unavoidable, such as a
user copying the hostname from a manually-entered URL into an
email message, where the original sequence will not reflect any
subsequent normalization. However, this type of bleed-over MUST
NOT occur if it can be presented by an application with simple
measures.
If a label ONLY contains character codes from the seven-bit
[ASCII] range of characters (U+0000 through U+007F), then that
label MUST be treated as a legacy label from the DNS namespace for
the purposes of comparison. In other words, labels which only
contain seven-bit [ASCII] MUST be compared as case-neutral
sequences, while all other labels MUST be compared as case-exact
sequences. In all situations, the output capitalization MUST
reflect the capitalization of the input domain name (since these
labels will have been capitalized and normalized according to
Hall I-D Expires: December 2002 [page 15]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
their domain name syntax rules, the answer data will also be
provided in the appropriate form if this rule is always followed).
5. The DNS Data-Types
As part of the efforts towards strongly defining strict data-
types, this document defines syntax rules for different kinds of
domain names and labels. Some of the domain name data-types will
only contain labels of a single data-type, while some domain name
data-types may contain multiple label data-types. For example, a
legacy hostname domain name can only contain legacy hostname
labels, while an internationalized service locator domain name can
contain a mix of different label types.
When one of the internationalized data-types is used with an
internationalized protocol, one or more encoding syntaxes MUST be
specified by the underlying protocol before the data can be
exchanged in a meaningful form. Note that RFC 2277 [RFC2277]
states that the preferred encoding for internationalized protocol
data is UTF-8.
When one of the internationalized data-types is used with a legacy
protocol which only has explicit support for [ASCII], the
internationalized data-type MUST be encoded into an ASCII-
compatible form before the data can exchanged. The [IDNA]
specification describes one such mechanism, and is the preferred
encoding form whenever legacy protocols are required to be used.
5.1. Syntax Validation
Each label in a domain name has specific syntax rules which
reflect on the data provided in that label. Therefore,
applications which validate domain names against a particular
data-type SHOULD apply the appropriate syntax rules to each label,
as well as validating the domain name in its entirety.
While it may appear that this model is overtly ambiguous, the
process of determining the appropriate syntax can be fairly simple
if the data-types are consistently enforced. For example, most of
the domain name data-types use relatively simple sequences of
label data-types, and most applications only support a single
domain name data-type for any particular protocol usage. Thus, it
is a simple matter to determine if the domain name is valid by
comparing it to the syntax rules for the expected usage.
Hall I-D Expires: December 2002 [page 16]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
In those cases where the application or protocol allows multiple
kinds of domain name to be used, it is still possible to apply
some fairly simple lexical analysis to determine the domain name
which is in use (a service location label is different from a
hostname label, while mailbox labels and octet labels may contain
specific escape sequences, and so forth). In those cases where
multiple data-types are supported and the domain name data-type
cannot be determined (this may happen with an application such as
"dig" or "nslookup", for example), then the application MAY choose
to simply validate the domain name against the relevant namespace
and leave it at that. However, this level of detachment SHOULD NOT
be the default behavior; applications SHOULD attempt to validate
the labels and domain names to the best of their ability using the
available syntax rules.
Specifically, the syntax of a label SHOULD be validated whenever a
resource record is added to the replication master for a zone, or
whenever an application first creates a domain name for use within
that application or its associated network service. These rules
are specifically designed to avoid garbage-in, garbage-out
syndrome. Subsequent applications and protocol end-points MAY
perform syntax validation of any domain names, and specific
application protocols MAY require verification by the application
end-points, although this will not be required if the
participating end-points have performed the necessary validation.
5.2. Defining New Data-Types
Application protocols MAY define any new label or domain name
data-types which are needed, although these data-types MUST
conform to the rules which govern the controlling namespace, as
described in section 4.
Application protocols SHOULD reuse one of the hostname syntaxes if
at all possible, since these syntaxes have the widest deployment,
and this will facilitate faster adoption of the protocol.
If a protocol needs to support a broader syntax for uses other
than referring to hostnames in the DNS or internationalized
namespaces, then the protocol SHOULD indicate which operations or
external syntaxes require specific exceptions, and document those
exception syntaxes separately if possible. For example, if a
protocol is capable of using DNS and LDAP equally, this SHOULD be
stated explicitly when the protocol-specific data-types are
Hall I-D Expires: December 2002 [page 17]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
defined, and a subset data-type which applies specifically to DNS
lookups SHOULD also be defined.
5.3. The Root Label and Domain Name
Whenever the DNS message format is used to transport a domain
name, [RFC1034] requires the root domain to be specified. However,
most applications and protocols do not require or even allow the
root domain to be specified as part of the domain names they use
internally. In these cases, the applications and protocols will
typically leave it up to the local resolver to fully-qualify the
domain name as provided, although this process can fail and cause
unexpected domain name to be used (see RFC 1535 [RFC1535] for an
example and a discussion of this problem).
There are two separate considerations here. First is that an
application may need to fully-qualify the domain name in order to
prevent misinterpretation. Secondarily, some applications and
protocols require that the root domain be provided as the complete
domain name, or as part of a domain name (such as a service
locator domain name associated with the root zone). The root label
is defined to suit both of those purposes, where this is needed.
It can be used to explicitly terminate a fully-qualified domain
name, and it can be used to explicitly represent the root domain
as a standalone entity.
In a multi-label domain name, the root label is represented by a
trailing separator mark. The root label MAY be used at the end of
any domain name, regardless of its data-type.
In those cases where the root label is provided by itself, the
separator mark will specifically represent the root domain of the
class IN hierarchy. Note that the root domain is not currently
defined as a host (it does not have an IP address), so it cannot
currently be used as a connection identifier.
Application protocols SHOULD support the use of a standalone root
label as an explicit domain name, although this is specifically
not required. Where a protocol defines this usage, it SHOULD NOT
be a mandatory requirement for all implementations. Other
application- or protocol-specific syntaxes MAY also be supported
for this purpose, if necessary. Applications MUST follow the
protocol-specific guidelines on this subject.
Hall I-D Expires: December 2002 [page 18]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
5.4. The Hostname Labels and Domain Names
Hostnames identify specific systems and zone partitions by name,
and are the most widely used of all the data-types. Hostnames are
used as the owner name and data values of almost all the common
resource records, are used as the connection identifier for almost
all protocol-specific syntaxes and generalized applications, and
are used for storing system names in local hosts databases, among
other purposes.
Since hostnames have such a broad number of uses and potential
storage formats, they also have the strictest syntax rules. A
hostname is not valid unless each label and the entire domain
validate successfully.
5.4.1. Legacy Hostnames
A legacy hostname domain name is a sequence of one or more legacy
hostname labels, with an optional root label at the end.
Applications which use legacy "hostnames" as specific data-types
MUST validate the hostname domain name and label sequences
separately and cumulatively.
Note that the syntax for legacy hostnames has undergone many
subtle and varied shifts over the years, with multiple updates and
revisions allowing for slightly different syntaxes. This document
unifies these definitions and clarifies some ambiguities, and is
to be considered the definitive reference on the definition of a
valid legacy hostname label and domain name.
A legacy hostname label may only contain the Hyphen (0x2D), the
numerals "0" through "9" (0x30 through 0x39), the uppercase
letters "A" through "Z" (0x41 through 0x5A), and the lowercase
letters "a" through "z" (0x61 through 0x7A) from [ASCII]. The
first and last character in a hostname label MUST NOT be a Hyphen
character, but any other character sequence is valid within the
confines of a hostname label.
A legacy hostname domain name is a sequence of one or more legacy
hostname labels. However, at least one of the labels MUST contain
at least one alphabetic character (a domain name which consists
entirely of numeric values has the potential to be confused with
an IP address, and this rule prevents this ambiguity). A legacy
hostname domain name MAY contain an optional root label at the end
Hall I-D Expires: December 2002 [page 19]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
of the domain name, although this usage MUST be explicitly allowed
by the application protocol in use.
With the exception of the optional root label at the end of a
domain name, a legacy hostname domain name MUST NOT contain any
other label data-types. If any of the labels do not validate as
legacy hostname labels, or if the entire domain name does not
validate as a legacy hostname domain name, then the entire domain
name MUST be rejected for use as a legacy hostname domain name.
The length rules associated with the DNS namespace are
specifically adopted as the length rules for the legacy hostname
label and domain name data-types. This definition updates the
definitions provided in [RFC952] and [RFC1123], which had set
these lengths at different values. As such, any system which
implements a HOSTS.TXT database (or a local equivalent, such as
the "/etc/hosts" file on traditional UNIX systems) MUST conform to
the length restrictions defined in section 4.2.1.
The syntax rules defined above are somewhat tighter than the
syntax allowed in [RFC2181]. However, no standards-track network
services have defined hostname syntax rules to use the allowable
syntax from [RFC2181]. Instead, almost all application protocols
and network services use stricter rules which are highly similar
to those defined here.
Applications and protocols which need to support internationalized
hostnames MUST use the syntax defined in section 5.4.2.
Applications and protocols which need to support eight-bit octets
in their domain names MUST either use the octet label syntax
described in section 5.5 or define a new syntax specifically for
use with that network service. In either event, new resource
records are also likely to be required.
5.4.2. Internationalized Hostnames
An internationalized hostname domain name is a sequence of one or
more internationalized hostname labels, with an optional root
label at the end. Applications MUST validate the domain name and
label sequences separately and cumulatively.
The syntax for internationalized hostname labels is defined in
NAMEPREP [NAMEPREP], while this document defines the syntax for
internationalized hostname domain names.
Hall I-D Expires: December 2002 [page 20]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
The international hostname label rules defined in NAMEPREP require
that a label be lowercased and normalized with Unicode
normalization form KC prior to use. Due to the massive number of
characters which are available for use with internationalized
hostname labels, this document cannot summarize the entire set.
Note that an internationalized hostname label which only contains
seven-bit codepoint values from the [ASCII] range MUST also
validate as a legacy hostname label, using the rules described in
section 5.4.1. This is necessary in order for a label to be
reusable in both namespaces.
An internationalized hostname domain name is a sequence of
internationalized hostname labels, with the additional requirement
that at least one of the labels MUST contain a non-numeric
character. An internationalized hostname domain name MAY contain
an optional root label at the end of the domain name, although
this usage MUST be explicitly allowed by the application protocol
in use.
With the exception of the optional root label at the end of a
domain name, an internationalized hostname domain name MUST NOT
contain any other label data-types. If any of the labels do not
validate as internationalized hostname labels, or if the entire
domain name does not validate as an internationalized hostname
domain name, then the entire domain name MUST be rejected for use
as an internationalized hostname domain name.
5.5. The Octet Label and Domain Name
The DNS namespace allows labels to contain eight-bit codepoint
values, although no standardized representation or interpretation
of these values is defined. While [RFC2181] allows these codepoint
values to be used with any domain name or label, this document
restricts the usage of these values to the octet label data-type.
A octet label essentially provides a direct pass-thru mapping to
the underlying DNS namespace. No additional restrictions or
interpretations are defined. Multiple octet labels may be used in
conjunction with multiple legacy hostname labels (with an optional
root label at the end of the end of the domain name) to form an
octet domain name.
Hall I-D Expires: December 2002 [page 21]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
The UCS character repertoire does not provide any mechanisms for
specifying raw octet values, but instead only identifies
characters and their codepoint values. As such, eight-bit
codepoint values are not accessible to applications which use the
internationalized namespace. Instead, those applications will be
required to use the DNS namespace directly whenever an octet
domain name contains eight-bit codes. However, if the domain name
only contains seven-bit characters, then that label can be
accessed from the internationalized namespace.
For this reason, applications and protocols SHOULD give preference
to the range of characters defined for legacy hostname labels, as
this allows the domain name to be accessed from the largest number
of sources. However, applications MUST allow the full eight-bit
range of values to be specified if the octet domain name data-type
is required for the protocol at hand, with the caveat that these
labels will be inaccessible from the internationalized namespace.
If a octet label contains a Full-Stop (0x2E), Reverse-Solidus
(0x5C), Double-Quote (0x22), a non-printing character from [ASCII]
(0x00 through 0x20, or 0x7F) or any of the eight-bit codepoint
values (0x80 through 0xFF), then those characters MUST be escaped
(using the syntax rules provided in section 4.2.3) whenever the
domain name is written in longhand form.
Any number of octet labels may be assigned to a leaf-node in the
DNS namespace. However, zone delegations use NS and SOA resource
records which use hostname labels, so a fully-qualified domain
name outside of the root zone MUST contain at least one legacy
hostname label. Since this usage allows for a variable number of
octet labels, and since applications outside of the domain name
system cannot determine the database context of any given label,
this can result in some ambiguity. However, no standards-track
network services outside of the DNS currently require the use of
octets, so this is fairly narrow area.
5.6. The Mailbox Labels and Domain Names
A variety of resource records make use of mailbox label and domain
name data-types in order to encapsulate email addresses into the
domain name system (this model allows email addresses to use the
DNS compression service). Although there are no known application
protocols outside of DNS which use this data-type, the label type
still has to be defined for use with DNS, and is therefore defined
with its own syntax in this document.
Hall I-D Expires: December 2002 [page 22]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
5.6.1. Legacy Mailboxes
The legacy mailbox domain name consists of a single legacy mailbox
label followed by one or more legacy hostname labels. In this
model, the legacy mailbox label represents the local-part element
from an RFC 2822 [RFC2822] email address, while the legacy
hostname labels represent the mail domain element from an
[RFC2822] email address. When a legacy mailbox domain name is
expanded and mapped to an [RFC2822] email address, the legacy
mailbox label goes on the left of the "@" separator, while the
hostname labels go on the right of the "@" separator.
The local-part element is defined in [RFC2822] as being either a
dot-atom or a quoted-string. The dot-atom syntax allows for a
relatively complete set of [ASCII] punctuation, numbers and
alphabetic characters, while the quoted-string syntax allows for
nearly all of the other characters from [ASCII] (certain control
characters are globally prohibited in [RFC2822], and these apply
to the quoted-string syntax as well).
In order to accommodate as many email addresses as possible, these
characters are defined as valid for a legacy mailbox label as
well. However, if a legacy mailbox label contains a Full-Stop
(0x2E), Reverse-Solidus (0x5C), Double-Quote (0x22), or any non-
printing character from [ASCII] (0x00 through 0x20, or 0x7F), then
those characters MUST be escaped using the syntax rules provided
in section 4.2.3 whenever the domain name is written out in
longhand form.
Note that [RFC2821] defines the maximum length of a local-part
element as 64 characters, although the maximum length of a legacy
label is 63 characters. As a result, not all local-parts can be
supported by the legacy mailbox label.
Also note that [RFC2822] also defines the syntax of a "mail
domain" as the dot-atom data-type, which allows for a larger
subset of [ASCII] characters than the legacy hostname data-type
allows. However, [RFC2821] also requires that mail domains be
queried through DNS with MX and A resource records, both of which
specify host systems. As such, the dot-atom syntax has never been
usable with the legacy hostname data-type for the purpose of mail
routing. The requirements for stronger data-types and syntax
checks defined in this document do not affect this fundamental
conflict other than to highlight its presence.
Hall I-D Expires: December 2002 [page 23]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
5.6.2. Internationalized Mailboxes
Legacy mailbox labels MAY be used with internationalized hostname
labels to form an internationalized mailbox domain name. In this
model, the legacy mailbox label represents a legacy local-part,
while the internationalized hostname labels represent an
international mail domain.
However, note that an internationalized local-part syntax has not
yet been defined, and until such a time, an internationalized
mailbox label syntax cannot be defined.
5.7. The Service Locator Labels and Domain Names
The service locator label and domain name syntax is used to
provide service-specific redirection functions for a particular
domain name. This usage is specific to DNS, so it does not have
general applicability outside of the domain name system, although
the label type still has to be supported, and is therefore defined
with its own syntax in this document.
5.7.1. Legacy Service Locators
The service locator label and domain name syntax is defined in RFC
2782 [RFC2782]. In summary, a legacy service locator domain name
consists of two legacy service locator labels which uniquely
identify a specific network service, with the remainder of the
domain name containing hostname and/or root labels.
The service locator labels are identical to the legacy hostname
label syntax, with the additional requirement that a service
locator label MUST begin with an Underscore (0x5F) character (this
usage prevents the SRV resource record's owner domain name from
colliding with other owner domain names). In this model, a
registered network service is assigned a _service._proto label
sequence, with this sequence being appended to the left of a
legacy hostname domain name. Application clients can then issue
queries for the fully-qualified service locator domain name, with
the resulting answer data providing indicating which hosts offer
that service on behalf of the queried domain name.
Hall I-D Expires: December 2002 [page 24]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
Note that zone delegation requires the use of legacy hostname
labels, so a fully-qualified domain name for an SRV resource
record associated with a domain name outside of the root zone MUST
contain at least one legacy hostname label. However, an
application can also query for an SRV resource record associated
with the root domain itself, and in that scenario, the fully-
qualified domain name would be "_service._proto.", with the
trailing separator mark explicitly representing the root domain.
5.7.2. Internationalized Service Locators
Service locator labels MAY be used with internationalized hostname
labels. In this model, the legacy service locator labels represent
a known service associated with an international domain.
Note that [RFC2277] says that protocol identifiers do not need to
be internationalized. As such, there is no requirement foreseen to
allow non-ASCII characters in the service locator label syntax.
6. Resource Records and Query Types
This section describes the domain name data-types in use with all
of the registered resource records and query-types. These
definitions include the valid owner domain names for a particular
kind of resource record, and also include the valid domain names
for the resource record data sections. Note that each of these
rules only use domain name data-types, while those data-types are
defined by constituent sets of label data-types.
6.1. Resource Records
Resource records may be provided in any section of a DNS message.
When they are provided in the question section as the query
question, they only have owner names. When they are provided in
any other section, they have owner names and resource record data.
All resource records have owner name syntax rules, while those
resource records which also provide domain names in resource
record data also have syntax rules for those domain names.
All new resource records MUST be defined with syntax rules
appropriate to that resource record.
Hall I-D Expires: December 2002 [page 25]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
Resource Record Name: IPv4 Address
Resource Record Mnemonic: A
Resource Record Code: 1
Defined In: [RFC1035]
Owner Name: Hostname
Resource Record Data: (no domain name data-types)
Resource Record Name: Name Server
Resource Record Mnemonic: NS
Resource Record Code: 2
Defined In: [RFC1035]
Owner Name: Hostname (delegated zone partition)
Resource Record Data: Hostname (authoritative server)
Note: All domain delegations MUST use the hostname data-type.
Resource Record Name: Mail Destination
Resource Record Mnemonic: MD
Resource Record Code: 3
Defined In: [RFC1035]
Owner Name: Hostname (mail domain)
Resource Record Data: Hostname (delivery server)
Note: Obsoleted and deprecated by RFC1035 in favor of MX
Resource Record Name: Mail Forwarder
Resource Record Mnemonic: MF
Resource Record Code: 4
Defined In: [RFC1035]
Owner Name: Hostname (mail domain)
Resource Record Data: Hostname (relay server)
Note: Obsoleted and deprecated by RFC1035 in favor of MX
Resource Record Name: Canonical Name
Resource Record Mnemonic: CNAME
Resource Record Code: 5
Defined In: [RFC1035]
Owner Name: inherited from target owner name
Resource Record Data: inherited from target owner name
Note: The owner domain name and resource record data are both
inherited from the target of the CNAME resource record. For
example, if a CNAME resource record references an A resource
record, then the owner name and the resource record data
both use the Hostname domain name data-type. However, if a
CNAME resource record references an SRV resource record,
then the owner name and the resource record data both use
the Service Locator domain name data-type.
Hall I-D Expires: December 2002 [page 26]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
Resource Record Name: Start-of-Authority
Resource Record Mnemonic: SOA
Resource Record Code: 6
Defined In: [RFC1035]
Owner Name: Hostname
Resource Record Data: multiple fields (see below)
MNAME: Hostname (replication master server)
RNAME: Mailbox (administrator's email address)
SERIAL: (no domain name data-types)
REFRESH: (no domain name data-types)
RETRY: (no domain name data-types)
EXPIRE: (no domain name data-types)
MINIMUM: (no domain name data-types)
Resource Record Name: Mailbox
Resource Record Mnemonic: MB
Resource Record Code: 7
Defined In: [RFC1035]
Owner Name: Mailbox (recipient email address)
Resource Record Data: Hostname (delivery server)
Resource Record Name: Mail Group
Resource Record Mnemonic: MG
Resource Record Code: 8
Defined In: [RFC1035]
Owner Name: Mailbox (original email address)
Resource Record Data: Mailbox (expanded email address)
Resource Record Name: Mail Rename
Resource Record Mnemonic: MR
Resource Record Code: 9
Defined In: [RFC1035]
Owner Name: Mailbox (original email address)
Resource Record Data: Mailbox (new email address)
Resource Record Name: Null
Resource Record Mnemonic: NULL
Resource Record Code: 10
Defined In: [RFC1035]
Owner Name: Legacy Octets
Resource Record Data: (no domain name data-types)
Hall I-D Expires: December 2002 [page 27]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
Resource Record Name: Well-Known Services
Resource Record Mnemonic: WKS
Resource Record Code: 11
Defined In: [RFC1035]
Owner Name: Hostname
Resource Record Data: (no domain name data-types)
Resource Record Name: Pointer
Resource Record Mnemonic: PTR
Resource Record Code: 12
Defined In: [RFC1035]
Owner Name: inherited from target owner name
Resource Record Data: inherited from target owner name
Note: Although PTR resource records are most often used to provide
reverse-lookup mappings, the data can be used for any domain
name which needs to point to another domain name. As such,
the owner name and the resource record data must both
inherit the domain name data-type in use with the
destination.
Resource Record Name: Host Information
Resource Record Mnemonic: HINFO
Resource Record Code: 13
Defined In: [RFC1035]
Owner Name: Hostname
Resource Record Data: (no domain name data-types)
Resource Record Name: Mail List Information
Resource Record Mnemonic: MINFO
Resource Record Code: 14
Defined In: [RFC1035]
Owner Name: Mailbox (mailing list primary address)
Resource Record Data: multiple fields (see below)
RMAILBOX: Mailbox / Root (responsible party address)
EMAILBOX: Mailbox / Root (error-handler mailbox)
Note: MINFO defines an application-specific interpretation for the
root domain in the resource record as an alternative to the
Mailbox data-type.
Hall I-D Expires: December 2002 [page 28]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
Resource Record Name: Mail Exchange
Resource Record Mnemonic: MX
Resource Record Code: 15
Defined In: [RFC1035]
Owner Name: Hostname (mail domain)
Resource Record Data: multiple fields (see below)
PREFERENCE: (no domain name data-types)
DESTINATION: Hostname (mail server)
Resource Record Name: Text
Resource Record Mnemonic: TXT
Resource Record Code: 16
Defined In: [RFC1035]
Owner Name: Legacy Octets
Resource Record Data: (no domain name data-types)
Note: The TXT resource record is commonly used as a proving ground
for new resource records, and this must continue to be
supported.
Resource Record Name: Responsible Person
Resource Record Mnemonic: RP
Resource Record Code: 17
Defined In: RFC 1183 [RFC1183]
Owner Name: Hostname
Resource Record Data: multiple fields (see below)
RMAILBOX: Mailbox (responsible person contact address)
DETAILS: Legacy Octets (pointer to TXT record)
Note: Binding this resource record to the hostname data-type may
artificially limits its usefulness, although it results in
greater predictability and consistency in the
internationalized namespace.
Resource Record Name: AFS Database Entry
Resource Record Mnemonic: AFSDB
Resource Record Code: 18
Defined In: [RFC1183]
Owner Name: Hostname
Resource Record Data: multiple fields (see below)
PREFERENCE: (no domain name data-types)
DESTINATION: Hostname (AFS server)
Hall I-D Expires: December 2002 [page 29]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
Resource Record Name: X.25 Number
Resource Record Mnemonic: X.25
Resource Record Code: 19
Defined In: [RFC1183]
Owner Name: Hostname (host)
Resource Record Data: (no domain name data-types)
Resource Record Name: ISDN Number
Resource Record Mnemonic: ISDN
Resource Record Code: 20
Defined In: [RFC1183]
Owner Name: Hostname (host)
Resource Record Data: (no domain name data-types)
Resource Record Name: Route-Through
Resource Record Mnemonic: RT
Resource Record Code: 21
Defined In: [RFC1183]
Owner Name: Hostname (host)
Resource Record Data: multiple fields (see below)
PREFERENCE: (no domain name data-types)
DESTINATION: Hostname (next-hop host)
Resource Record Name: OSI NSAP Address
Resource Record Mnemonic: NSAP
Resource Record Code: 22
Defined In: RFC 1706 [RFC1706]
Owner Name: Hostname
Resource Record Data: (no domain name data-types)
Resource Record Name: OSI NSAP Pointer
Resource Record Mnemonic: NSAP-PTR
Resource Record Code: 23
Defined In: [RFC1706]
Owner Name: Hostname (hexadecimal NSAP address)
Resource Record Data: Hostname (host)
Resource Record Name: Signature
Resource Record Mnemonic: SIG
Resource Record Code: 24
Defined In: RFC 2535 [RFC2535] and RFC 2931 [RFC2931]
Owner Name: Hostname (?)
Resource Record Data: (no domain name data-types)
Hall I-D Expires: December 2002 [page 30]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
Resource Record Name: Public Key
Resource Record Mnemonic: KEY
Resource Record Code: 25
Defined In: [RFC2535]
Owner Name: Legacy Octets
Resource Record Data: (no domain name data-types)
Note: The owner name must be treated as unstructured, since the
KEY resource record may be bound to any domain name.
Resource Record Name: Pointer to X.400 Mapping
Resource Record Mnemonic: PX
Resource Record Code: 26
Defined In: RFC 2163 [RFC2163]
Owner Name: Hostname (encoded X.400 mail domain)
Resource Record Data: multiple fields (see below)
RFC822-MAIL: Hostname (mail domain)
X400-MAIL: Hostname (mail domain)
Resource Record Name: Geographical Position
Resource Record Mnemonic: GPOS
Resource Record Code: 27
Defined In: RFC 1712 [RFC1712]
Owner Name: Hostname
Resource Record Data: (no domain name data-types)
Resource Record Name: IPv6 Simple Address
Resource Record Mnemonic: AAAA
Resource Record Code: 28
Defined In: RFC 1886 [RFC1886]
Owner Name: Hostname
Resource Record Data: (no domain name data-types)
Resource Record Name: Location
Resource Record Mnemonic: LOC
Resource Record Code: 29
Defined In: RFC 1876 [RFC1876]
Owner Name: Hostname
Resource Record Data: (no domain name data-types)
Hall I-D Expires: December 2002 [page 31]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
Resource Record Name: Next Record
Resource Record Mnemonic: NXT
Resource Record Code: 30
Defined In: [RFC2535]
Owner Name: Legacy Octets
Resource Record Data: multiple fields (see below)
NEXT-OWNER: Legacy Octets (the next domain name)
TYPE: (no domain name data-types)
Note: The owner name must be treated as unstructured, since the
NXT resource record may be bound to any domain name.
Resource Record Name: Service Locator
Resource Record Mnemonic: SRV
Resource Record Code: 33
Defined In: [RFC2782]
Owner Name: Service Locator
Resource Record Data: multiple fields (see below)
PRIORITY: (no domain name data-types)
WEIGHT: (no domain name data-types)
PORT: (no domain name data-types)
TARGET: Hostname (target server)
Resource Record Name: ATM Address
Resource Record Mnemonic: ATMA
Resource Record Code: 34
Defined In: N/A (see ATM Forum standards)
Owner Name: Hostname
Resource Record Data: (no domain name data-types)
Resource Record Name: Naming Authority Pointer
Resource Record Mnemonic: NAPTR
Resource Record Code: 35
Defined In: RFC 2915 [RFC2915]
Owner Name: Hostname
Resource Record Data: multiple fields (see below)
ORDER: (no domain name data-types)
PREFERENCE: (no domain name data-types)
FLAGS: (no domain name data-types)
SERVICE: (no domain name data-types)
REGEXPS: (no domain name data-types)
REPLACEMENT: Hostname / Service Locator (see notes)
Note: The domain name provided in the REPLACEMENT sub-field can
reference a NAPTR, SRV or A resource record by its owner
name, depending on the value of the FLAGS sub-field.
Hall I-D Expires: December 2002 [page 32]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
Resource Record Name: Key Exchange
Resource Record Mnemonic: KX
Resource Record Code: 36
Defined In: RFC 2230 [RFC2230]
Owner Name: Legacy Octets (any domain name)
Resource Record Data: multiple fields (see below)
PREFERENCE: (no domain name data-types)
DESTINATION: Hostname (key server)
Note: The owner name must be treated as unstructured, since the KX
resource record may be bound to any domain name.
Resource Record Name: Certificate
Resource Record Mnemonic: CERT
Resource Record Code: 37
Defined In: RFC 2538 [RFC2538]
Owner Name: Hostname
Resource Record Data: (no domain name data-types)
Note: The owner name must be treated as unstructured, since the
CERT resource record may be bound to any domain name.
Resource Record Name: IPv6 Complex Address
Resource Record Mnemonic: A6
Resource Record Code: 38
Defined In: RFC 2874 [RFC2874]
Owner Name: Hostname (host)
Resource Record Data: (no domain name data-types)
Resource Record Name: Domain Name Redirection
Resource Record Mnemonic: DNAME
Resource Record Code: 39
Defined In: RFC 2672 [RFC2672]
Owner Name: Hostname
Resource Record Data: Hostname
Resource Record Name: Extended Option
Resource Record Mnemonic: OPT
Resource Record Code: 41
Defined In: RFC 2671 [RFC2671]
Owner Name: Root
Resource Record Data: (no domain name data-types)
Hall I-D Expires: December 2002 [page 33]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
Resource Record Name: Transaction Key
Resource Record Mnemonic: TKEY
Resource Record Code: 249
Defined In: RFC 2930 [RFC2930]
Owner Name: Legacy Octets
Resource Record Data: (no domain name data-types)
Note: The owner name must be treated as unstructured, since the
TKEY resource record may be bound to any domain name.
Resource Record Name: Transaction Signature
Resource Record Mnemonic: TSIG
Resource Record Code: 250
Defined In: RFC 2845 [RFC2845]
Owner Name: Legacy Octets
Resource Record Data: (no domain name data-types)
Note: The owner name must be treated as unstructured, since the
TSIG resource record may be bound to any domain name.
6.2. Query Types
Apart from the resource records defined in section 6.1 above,
there are also a handful of query types. Query types are only
provided in the question section of a DNS message, and do not have
resource record data. However, their owner names have domain name
data-types which require standardization.
All new query-types MUST be defined with syntax rules appropriate
to that query-type.
Query Name: Incremental Transfer
Query Mnemonic: IXFR
Query Code: 251
Defined In: RFC 1995 [RFC1995]
Owner Name: Hostname
Query Name: Zone Transfer
Query Mnemonic: AXFR
Query Code: 252
Defined In: [RFC1035]
Owner Name: Hostname
Hall I-D Expires: December 2002 [page 34]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
Query Name: Mailbox Records
Query Mnemonic: MAILB
Query Code: 253
Defined In: [RFC1035]
Owner Name: Mailbox
Note: This query-type requests all of the Mailbox, Mail Group,
Mail Rename and Mail List resource records associated with
an email address.
Query Name: Mail Transfer Records
Query Mnemonic: MAILA
Query Code: 254
Defined In: [RFC1035]
Owner Name: Hostname
Note: Obsoleted and deprecated by RFC1035 in favor of MX, but used
to request all of the Mail Forwarder and Mail Destination
resource records associated with a mail domain.
Query Name: All Records
Query Mnemonic: "*" or ALL
Query Code: 255
Defined In: [RFC1035]
Owner Name: Hostname
7. Security Considerations
This document does not change any on-the-wire formats, and
therefore does not introduce any new security risks within the
affected protocols. However, it is the author's hope that by
defining strict syntaxes for domain names and labels that overall
security can be improved as a result of higher predictability and
better development practices.
8. IANA Considerations
This document requires the use of an EDNS extended label type
identification code. This document uses the b000011 ELT code.
Hall I-D Expires: December 2002 [page 35]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
9. References
[RFC608] RFC 608, "HOST NAMES ON-LINE", M. Kudlick, January
1974.
[RFC810] RFC 810, "DoD INTERNET HOST TABLE SPECIFICATION", E.
Feinler et al, March 1982.
[RFC882] RFC 882, "DOMAIN NAMES - CONCEPTS and FACILITIES",
P. Mockapetris, November 1983.
[RFC952] RFC 952, "DOD INTERNET HOST TABLE SPECIFICATION", K.
Harrenstien et al, October 1985.
[RFC1034] RFC 1034, "DOMAIN NAMES - CONCEPTS and FACILITIES",
P. Mockapetris, November 1987.
[RFC1123] RFC 1123, "Requirements for Internet Hosts --
Application and Support", R. Braden, October 1989.
[RFC2181] RFC 2181, "Clarifications to the DNS
Specification", R. Elz et al, July 1997.
[ASCII] "ANSI X3.4-1968. USA Standard Code for Information
Interchange", ANSI.
[RFC883] RFC 883, "DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION", P. Mockapetris, November 1983.
[RFC1035] RFC 1035, "DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION", P. Mockapetris, November 1987.
[ISO-10646] "ISO/IEC 10646-1:2000. International Standard --
Information technology -- Universal Multiple-Octet Coded
Character Set (UCS) -- Part 1: Architecture and Basic
Multilingual Plane" and "Part 2: Supplementary Planes",
ISO.
[UNICODE] "The Unicode Consortium, The Unicode Standard,
Version 3.0", Addison-Wesley: Reading, MA, 2000. Update to
version 3.1, 2001. Update to version 3.2, 2002.
[PUNYCODE] Internet-Draft, "Punycode:An encoding of Unicode
for use with IDNA", A. Costello, May 2002.
Hall I-D Expires: December 2002 [page 36]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
[IDNA] Internet-Draft, "Internationalizing Domain Names In
Applications (IDNA)", P. Faltstrom et al, May 2002.
[STRINGPREP] Internet-Draft, "Preparation of
Internationalized Strings", P. Hoffman et al, May 2002.
[NAMEPREP] Internet-Draft, "Nameprep: A Stringprep Profile
for Internationalized Domain Names", P. Hoffman et al, May
2002.
[RFC1535] RFC 1535, "A Security Problem and Proposed
Correction With Widely Deployed DNS Software", E. Gavron,
October 1993.
[RFC2821] RFC 2821, "Simple Mail Transfer Protocol", J.
Klensin, April 2001.
[RFC2822] RFC 2822, "Internet Message Format", P. Resnick,
April 2001.
[RFC2782] RFC 2782, "A DNS RR for specifying the location of
services (DNS SRV)", A. Gulbrandsen et al, February 2000.
[RFC2277] RFC 2277, "IETF Policy on Character Sets and
Languages", H. Alvestrand, January 1998.
[RFC1183] RFC 1183, "New DNS RR Definitions", C. Everhart et
al, October 1990.
[RFC1706] RFC 1706, "DNS NSAP Resource Records", B. Manning
et al, October 1994.
[RFC2535] RFC 2535, "Domain Name System Security Extensions",
D. Eastlake, March 1999.
[RFC2931] RFC 2931, "DNS Request and Transaction Signatures (
SIG(0)s )", D. Eastlake, September 2000.
[RFC2163] RFC 2163, "Using the Internet DNS to Distribute
MIXER Conformant Global Address Mapping (MCGAM)", C.
Allocchio, January 1998.
[RFC1712] RFC 1712, "DNS Encoding of Geographical Location",
C. Farrell et al, November 1994.
Hall I-D Expires: December 2002 [page 37]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
[RFC1886] RFC 1886, "DNS Extensions to support IP version 6",
S. Thomson et al, December 1995.
[RFC1876] RFC 1876, "A Means for Expressing Location
Information in the Domain Name System", C. Davis et al,
January 1996.
[RFC2915] RFC 2915, "The Naming Authority Pointer (NAPTR) DNS
Resource Record", M. Mealling et al, September 2000.
[RFC2230] RFC 2230, "Key Exchange Delegation Record for the
DNS", R. Atkinson, November 1997.
[RFC2538] RFC 2538, "Storing Certificates in the Domain Name
System (DNS)", D. Eastlake et al, March 1999.
[RFC2874] RFC 2874, "DNS Extensions to Support IPv6 Address
Aggregation and Renumbering", M. Crawford et al, July 2000.
[RFC2672] RFC 2672, "Non-Terminal DNS Name Redirection", M.
Crawford, August 1999.
[RFC2671] RFC 2671, "Extension Mechanisms for DNS (EDNS0)",
P. Vixie, August 1999.
[RFC2930] RFC 2930, "Secret Key Establishment for DNS (TKEY
RR)", D. Eastlake, September 2000.
[RFC2845] RFC 2845, "Secret Key Transaction Authentication
for DNS (TSIG)", P. Vixie et al, May 2000.
[RFC1995] RFC 1995, "Incremental Zone Transfer in DNS", M.
Ohta, August 1996.
10. Acknowledgements
The author made multiple attempts at avoiding this work. David
Hopwood and Mark Andrews are credited with arguing that it needed
to be done, and John Klensin is credited with providing helpful
feedback on how it should be done.
Hall I-D Expires: December 2002 [page 38]
INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
11. Author's Address
Eric A. Hall
ehall@ehsco.com
Hall I-D Expires: December 2002 [page 39]