bind9/doc/draft/draft-hall-dns-datatypes-00.txt

  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]