[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Internet-Draft                                                Ted Hardie
Expires: December 2002                                      Nominum, Inc.



           A DNS RR for Pointers to RRs outside class IN
                  <draft-hardie-out-rr-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

   This Internet-Draft will expire in December 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract

   The Domain Name System is a global distributed lookup system with
   delegation.  In the original specification of the DNS [RFC 1035],
   CLASSes were described as parallel data structures within a single
   namespace but with potentially different delegations of authority.
   [BCP 42] defines a different vision, in which different CLASSes
   represent fundamentally different namespaces.  Though [BCP 42]
   includes procedures for assignment of CLASSes, there has been
   little use of this axis of extensibility; in practice, CLASS IN is
   the only widely deployed CLASS in the DNS.  The ubiquity of CLASS
   IN for name to IP address mapping has caused a vicious cycle in
   which extensions are placed within that CLASS to take advantage of
   its global deployment, with each addition further increasing its
   gravitational attraction.  This document describes a Resource
   Record for use within CLASS IN that contains a pointer to a CLASS
   outside of IN.  This mechanism is intended to allow administrators
   to indicate that a named resource identified within CLASS IN is
   also present in a different namespace, potentially under a different
   name.  This cross-class pointer will allow the DNS to handle
   new namespaces with mechanisms appropriate to those namespaces
   while providing a connection to the globally deployed CLASS IN
   namespace.




Table of Contents

   1.    Terminology
   2.    Introduction
   3.    The OUT RR
   3.1   OUT Presentation format
   3.2   OUT RDATA Format
   3.3   Examples
   3.3.1 Example 1
   3.4.2 Example 2
   4.    Use of the OUT RR
   5.    Alternatives
   6.    Security Considerations
   7.    IANA Considerations
   8.    IAB Considerations
   9.    References
   10.    Acknowledgments
   11.    Author's Address
   12.    Full Copyright Statement





1. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].

2. Introduction

   The Domain Name System is a distributed lookup system with
   delegation.  Though the DNS was initially described as related to a
   single namespace[RFC 1035], its inclusion of CLASSes which may
   derive from different roots creates a de facto mechanism for using
   the DNS with multiple namespaces.  The DNS uses common resource
   record and packet formats for all CLASSes, but the namespaces thus
   created are fully independent.  This independence means that a name
   within one class has no necessary relationship to the same name in
   a different CLASS.

   This independence is architecturally sound in principle, but the
   deployment history of the DNS shows that resource records have been
   highly concentrated in the CLASS IN namespace.  Because developers
   of new RRs wish to take immediate advantage of the deployed DNS
   infrastructure, they use CLASS IN even in situations where the use
   of a new namespace would produce a better long term result.  This
   document proposes a mechanism by which a Resource Record within
   CLASS IN can be used as a pointer to a NAME in a CLASS outside IN.
   It presumes that a cross-class pointer mechanism will allow
   the development of namespaces outside CLASS IN without requiring
   CLASS IN to be replaced or its resource records redeveloped
   in the new CLASSes.


3. The OUT RR

   The OUT RR is a CLASS IN RR used to store a pointer to related data
   stored in a non-CLASS IN DNS namespace.  The type number for the
   OUT RR is to be assigned by IANA.  The OUT RR occurs in CLASS IN
   only.  The format for the OUT RR is:

   NAME TTL IN OUT IN-EXTERNAL-CLASS IN-EXTERNAL-NAME

   Each OUT RR stores a single pointer, as a pair composed of an
   IN-EXTERNAL-CLASS and an IN-EXTERNAL-NAME.  Even if a NAME in CLASS
   IN maps to multiple IN-EXTERNAL-NAMEs in the same
   IN-EXTERNAL-CLASS, each pair should be stored in a separate OUT RR.


3.1 OUT Presentation format

   The format for the OUT RR is:

   NAME TTL IN OUT IN-EXTERNAL-CLASS IN-EXTERNAL-NAME

   IN-EXTERNAL-CLASS is represented in decimal format when a mnemonic for
   the class has not been established.



3.2 OUT RDATA Format

   The RDATA section of the OUT RR in transmission contains RDLENGTH
   bytes of binary data.  The OUT RDATA is formed by concatenating the
   CLASS bytes for the IN-EXTERNAL-CLASS and the octets representing
   the IN-EXTERNAL-NAME in the IN-EXTERNAL-CLASS.  CLASS assignments
   are maintained by IANA according to the assignment criteria set out
   in [BCP42].


3.3 Examples

3.3.1 Example 1

   A lookup is made against a DNS record in class IN for a device
   which runs the IP version of BACNet (Building Automation and
   Control Network; see Annex J of ANSI/ASHRAE Standard 135-2001).
   The property manager for the property at which the device is
   present maintains information on all its BACNet devices in its own
   namespace within the private use CLASS space set out in [BCP42].
   In addition to reporting the data available within CLASS IN, the
   DNS server reports the IN-EXTERNAL-CLASS and NAME at which more
   information is available.

   firealarm.example.com 3600 IN A           10.0.0.20
   firealarm.example.com 3600 IN OUT  65410  SA_TEMP.AHU4.BLDG20.PAO

   A lookup in the private class 65410 might return some set of
   BACNet properties associated with that device:

   SA_TEMP.AHU4.BLD20.PAO 3600 65410 OBJ_ID    2492492
   SA_TEMP.AHU4.BLD20.PAO 3600 65410 OBJ_NAME  SA_TEMP
   SA_TEMP.AHU4.BLD20.PAO 3600 65410 OBJ_TYPE  Analog.Input
   SA_TEMP.AHU4.BLD20.PAO 3600 65410 Vendor_ID Example_Technologies

   Note that the property manager may choose to keep all of its BACNet
   devices within this namespace, whether or not the devices are
   IP-addressable.  Note also that this example relates to a
   private namespace maintained by a property manager and should
   not be taken to imply that the above CLASS or RRs have been
   specified for use with BACNet.


3.3.2 Example 2

   A lookup is made against a DNS record in class IN for a server which
   is part of a Content Delivery Network.  The Content Delivery
   Network maintains its own DNS namespace within the private use
   CLASS space set out in [BCP42].  In addition to reporting the data
   available within CLASS IN, it reports the NAME at which further
   information is available within its own namespace.

   newsservice.example.com. 600 IN A    10.0.0.1
   newsservice.example.com. 600 IN OUT  65500 surrogate1.cluster4.west.nam.

   A DNS client configured to use private use CLASS 65500 can then
   present the NAME surrogate1.cluster4.west.nam to the appropriate
   DNS servers and retrieve resources records from that private
   address space.  Within a CDN context, this might provide
   information on the state of that surrogate, which might include
   information from resource record types that do not exist within
   CLASS IN.  For example:

   Surrogate1.cluster4.west.nam 600 65300 USERS newsservice.example.com
   Surrogate1.cluster4.west.nam 600 65300 USERS homepage.example.com
   Surrogate1.cluster4.west.nam 600 65300 USERS info-gov.example.org
   Surrogate1.cluster4.west.nam 600 65300 USERS sports-scores.example.net

   might report the set of users for a specific surrogate to those who have
   configured their DNS for lookups into that private use CLASS.


3.3.3 Example 3

   A lookup is made against a DNS record in class IN for a host which
   subscribes to a service that reports other proximate participating
   hosts.  By storing a pointer to its NAME in that service's private
   use CLASS, a host advertises to those looking it up in CLASS IN
   that it participates and what to use to lookup related records.  A
   query in CLASS IN thus might return:

   hostname.example.com.    600 IN A    10.0.0.100
   hostname.example.com.    600 IN OUT  65400 u103.rwc.ca.us.loc.

   A user of the proximity service can then present the NAME
   u103.rwc.ca.us.loc. to the DNS servers for CLASS 65400 and receive
   appropriate information.  For a proximity service a lookup might
   yield something like:

   u103.rwc.ca.us.loc.  100 65400 1000m u202.mp.ca.us.loc.
   u103.rwc.ca.us.loc.  100 65400 1000m u002.pa.ca.us.loc.
   u103.rwc.ca.us.loc.  100 65400 1000m u333.rwc.ca.us.loc.

   reporting the 4 hosts which were within 1000 meters.  This data
   again contains resource records (and might well correspond to query
   types) that do not exist with CLASS IN.


4. Use of the OUT RR

   This RR MUST NOT be used for pointers within CLASS IN.  Use of this
   resource record as a pointer to a NAME within CLASS IN could easily
   create conflicts with the information published for the original
   NAME.  If, for example, a lookup resulted in a CNAME record and an
   OUT record pointing to CLASS IN, conflicts over which resource
   record's data to use to derive an IP address might occur.  In
   certain circumstance, it may also create a resolution loop that
   current use of the DNS system is not designed to detect.  OUT
   Resource Records pointing to CLASS IN MUST be treated as an error
   by applications which receive them, and it would be useful if
   server implementations reported attempts to use such pointers to
   their administrators.

5. Alternatives

   The OUT resource record presumes a benefit to mapping a name in one
   namespace to a name in another namespace.  In some cases, it can be
   difficult to see when that mapping between namespaces is required
   and when an additional resource record type in the existing
   namespace is sufficient.  In general, two or more namespaces are
   required when there are distinguishable collections of identifiers,
   rather than when there are additional attributes to existing
   identifiers.  In gross terms, the OUT RR allows the DNS to indicate
   that something identified within one set (CLASS IN) is also a
   member of another set, possibly under a different identifier; using
   additional RRs within CLASS IN, even private RRs within CLASS IN,
   does not imply the existence of another set.


6. Security Considerations

   The storage of data within the DNS makes available information to an
   Internet-scale audience.  Revealing information about the namespaces in
   which data is stored provides a hint to potential attackers about the
   information and should be released only after due consideration of the
   benefits and risks associated with that release.

7. IANA Considerations

   IANA is requested to allocate an RR type number within CLASS IN for
   the OUT resource record type.

8. IAB Considerations

   The use of pointers within CLASS IN to namespaces outside of CLASS
   IN risks creating a situation analogous to a split root for the
   DNS; indeed, it is a basic principal that the different DNS CLASSes
   do not need to share a single root.  This document does not propose
   to segment reachability information critical to the operation of
   the Internet into different namespaces, but it does posit that some
   information belongs in namespaces outside CLASS IN.  That risks the
   application namespace of the Internet being fragmented, even if the
   Internet's reachability information is not.  This fragmentation may
   well be appropriate in certain instances and inappropriate in
   others, and due care must be given to the creation and use of
   namespaces outside CLASS IN.


9. References

   TBA

10. Acknowledgments

   Paul Mockapetris, David Conrad, and Andreas Gustafsson were all
   kind enough to provide feedback on early drafts of this document;
   that kindness should not be construed, however, as approval of
   the ideas contained in the document.

11. Author's Address

   Ted Hardie
   Nominum, Inc.
   2385 Bay Road
   Redwood City, CA  94063
   USA

   EMail: Ted.Hardie@nominum.com


12.  Full Copyright Statement

   Copyright (C) The Internet Society (2002). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

   Funding for the RFC editor function is currently provided by the
   Internet Society.