[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
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