From 09d3194a7ecf097ca792a2a8201560906e6d3843 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Thu, 4 Jul 2002 00:30:38 +0000 Subject: [PATCH] new draft --- doc/draft/draft-hall-dns-datatypes-00.txt | 2036 +++++++++++++++++++++ 1 file changed, 2036 insertions(+) create mode 100644 doc/draft/draft-hall-dns-datatypes-00.txt diff --git a/doc/draft/draft-hall-dns-datatypes-00.txt b/doc/draft/draft-hall-dns-datatypes-00.txt new file mode 100644 index 0000000000..21eef1b4d6 --- /dev/null +++ b/doc/draft/draft-hall-dns-datatypes-00.txt @@ -0,0 +1,2036 @@ + + + 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 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 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]