INTERNET-DRAFT Edward Lewis draft-lewis-dns-undocumented-types-01.txt NeuStar, Inc. Intended status: Informational October 2011 IANA Allocated DNS RRtype Codes Without Documentation Abstract In the IANA registry of Resource Record (RR) TYPEs, as of October 1, 2011, there are 10 type code values allocated with references that are individual email boxes and not stable documents. Some of the registrations represent works in progress and such a reference is viable. Some registrations are dormant or dead efforts. In all cases it would be helpful to have some reference to material describing the type. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 13, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1.0 Introduction In the IANA registry of Resource Record (RR) TYPEs, as of October 1, 2011, there are 10 type code values allocated with references that are individual email boxes and not stable documents. Some of the registrations represent works in progress and such a reference is viable. Some registrations are dormant or dead efforts. In all cases it would be helpful to have some reference to material describing the type. The current roster of undocumented RR types is as follows. Note that for the purposes of this list, an internet draft is considered to be insufficient, even if that is all that is needed to initially obtain a registration. TYPE Value and meaning Reference ------- ----------------------------------------- --------- EID 31 Endpoint Identifier [Patton] NIMLOC 32 Nimrod Locator [Patton] SINK 40 SINK [Eastlake] NINFO 56 NINFO [Reid] RKEY 57 RKEY [Reid] TALINK 58 Trust Anchor LINK [Wijngaards] CDS 59 Child DS [Barwood] URI 256 URI [Faltstrom] CAA 257 Certification Authority Authorization [Hallam-Baker] TA 32768 DNSSEC Trust Authorities [Weiler] This document is not intended to cast any commentary on these types, just provide a guide or landing place for those trying to research the types. For this reason, there is no special meaning to any standards language, no possible connotation of "compliance" to this document. 2.0 Documenting the types In this section, each type will be presented, including a basic description of the syntax. This is significant only because it reveals any need to consider message compression or DNSSEC downcasing. For these types those needs should not arise, but, broken software may exist that does compress or downcase the records. 2.1 EID (31) EID stands for Endpoint IDentifier. The last known IETF document describing this is draft-ietf-nimrod-dns-00 and is available on tools.ietf.org. The definition of the RDATA portions is stated as this: * RDATA: a string of octets containing the Endpoint Identifier. The value is the binary encoding of the Identifier, meaningful only to the system utilizing it. The draft expired in April 1996. EID and the next type, NIMLOC, were defined to support NIMROD, which is documented in a few RFC documents:RFC-1753, RFC-1992, RFC-2102, and RFC-2103. An additional reference is an unpublished online note by Noel Chiappa, who invented NIMROD: <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt> 2.2 NIMLOC (32) NIMLOC stands for Nimrod Locator. The last known document describing this is draft-ietf-nimrod-dns-00 and is available on tools.ietf.org. The definition of the RDATA portions is stated as this: * RDATA: a variable length string of octets containing the Nimrod Locator. The value is the binary encoding of the Locator specified in the Nimrod protocol[[[ref to be supplied]]]. Note the "ref to be supplied." That is in the original text. The draft expired in April 1996. Another version of that document has been located at the following URL: http://ana-3.lcs.mit.edu/~jnc/nimrod/dns.txt This appears to be an update (a would be "-01") to the draft. 2.3 SINK (40) The SINK RR was last described in draft-eastlake-kitchen-sink-02, which is available on tools.ietf.org. The RDATA consisted of three fields, "coding", "subcoding" and "data" which are summarized in this paragraph from the last known draft. The "coding" and "subcoding" octets are always present. The "data" portion is variable length and could be null in some cases. The size of the "data" portion can always be determined by subtracting 2 from the SINK resource record RDLENGTH. The coding octet gives the general structure of the data. The subcoding octet provides additional information depending on the value of the coding octet. The draft expired in October 1997. 2.4 NINFO (56) The NINFO RR was the result of a name change from the proposed ZS RR, the latter is described in draft-reid-dnsext-zs-01. The draft is available on the tools.ietf.org web site. The RDATA consists of "ZS-DATA" which is described in the following: where: ZS-DATA One or more character-strings. The draft expired January 2009. 2.5 RKEY (57) The RKEY RR was last defined in draft-reid-dnsext-rkey-00, which expired in January 2009. This draft is available on the tools.ietf.org web site. The RDATA syntax is defined to be the same as the DNSKEY RR [RFC 4034], with the protocol field being 1. 2.6 TALINK (58) TALINK stands for Trust Anchor Link and is last defined in the draft named draft-wijngaards-dnsop-trust-history-02, available on the tools.ietf.org site. The RDATA section is defined as two fully qualified domain names that are not subject to message compression nor DNSSEC downcasing. The draft expired in February 2010. 2.7 CDS (59) CDS stands for "Child DS" and is described in an active internet draft named draft-barwood-dnsop-ds-publish-02. 2.8 URI (256) The URI RR type is last defined in draft-faltstrom-uri-06, which expired in April 2011. The draft is available on tools.ietf.org. The RDATA consists of two 16 bit fields called Priority and Weight and a series of text strings called the Target. 2.9 CAA (257) CAA is "Certification Authority Authorization" and is defined in the active draft draft-hallambaker-donotissue-04. 2.10 TA (32768) TA stands for "Trust Anchor" and, as far as can be determined, not defined in an IETF document. (The ATMA record is also not mentioned in an IETF document.) The record is described in a document named INI1999-19.pdf on the www.watson.org web site. In that document, the RDATA is described as "The fields in the TA record contain exactly the same data as the DS record and use the same IANA-assigned values in the algorithm and digest type fields as the DS record." The following appears on the IANA webpage for DNS Parameters: Deploying DNSSEC Without a Signed Rott[sic]. TR 1999-19, Information Networking Institute, Carnegie Mellon U, April 2004. http://cameo.library.cmu.edu/ http://www.watson.org/~weiler/INI1999-19.pdf The DS record is defined in RFC4034. 3. IANA Considerations IANA is requested to include the names of the documents where the allocated types are described. In some cases there is a danger that a document may cease to be available. In other cases, some individuals are prolific writers and, to the author's credit, quite active in contributing material. Unfortunately, this makes it hard to find a RR definition when all that is listed is a person's email address. 4. All other considerations There are no other considerations in this document. Security is not a topic of interest. 5. Acknowledgements Contributions from Ran Atkinson and Shane Kerr helped fill in the sections on EID and NIMLOC. And address spelling mistakes. Sam Weiler contributed background for the TA type. 6. References All references are informative. [RFC1753] Chiappa, N., "IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture", RFC 1753, December 1994. [RFC1992] Castineyra, I., Chiappa, N., and M. Steenstrup, "The Nimrod Routing Architecture", RFC 1992, August 1996. [RFC2102] Ramanathan, R., "Multicast Support for Nimrod : Requirements and Solution Approaches", RFC 2102, February 1997. [RFC2103] Ramanathan, R., "Mobility Support for Nimrod : Challenges and Solution Approaches", RFC 2103, February 1997. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. 7. Author's Address Edward Lewis 46000 Center Oak Plaza Sterling, VA 20166 US EMail: ed.lewis@neustar.biz