DNS NSAP Resource Records
RFC 1637

Document Type RFC - Experimental (June 1994; No errata)
Obsoleted by RFC 1706
Obsoletes RFC 1348
Was draft-manning-dns-nsap (individual)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1637 (Experimental)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         B. Manning
Request for Comments: 1637                               Rice University
Obsoletes: 1348                                               R. Colella
Category: Experimental                                              NIST
                                                               June 1994

                       DNS NSAP Resource Records

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Abstract

   The Internet is moving towards the deployment of an OSI lower layers
   infrastructure. This infrastructure comprises the connectionless
   network protocol (CLNP) and supporting routing protocols. Also
   required as part of this infrastructure is support in the Domain Name
   System (DNS) for mapping between names and NSAP addresses.

   This document defines the format of one new Resource Record (RR) for
   the DNS for domain name-to-NSAP mapping. The RR may be used with any
   NSAP address format. This document supercedes RFC 1348.

   NSAP-to-name translation is accomplished through use of the PTR RR
   (see STD 13, RFC 1035 for a description of the PTR RR). This paper
   describes how PTR RRs are used to support this translation.

Manning & Colella                                               [Page 1]
RFC 1637                      DNS NSAP RRs                     June 1994

1.  Introduction

   The Internet is moving towards the deployment of an OSI lower layers
   infrastructure. This infrastructure comprises the connectionless
   network protocol (CLNP) [6] and supporting routing protocols. Also
   required as part of this infrastructure is support in the Domain Name
   System (DNS) [8] [9] for mapping between domain names and OSI Network
   Service Access Point (NSAP) addresses [7] [Note: NSAP and NSAP
   address are used interchangeably throughout this memo].

   This document defines the format of one new Resource Record (RR) for
   the DNS for domain name-to-NSAP mapping. The RR may be used with any
   NSAP address format.

   NSAP-to-name translation is accomplished through use of the PTR RR
   (see RFC 1035 for a description of the PTR RR). This paper describes
   how PTR RRs are used to support this translation.

   This memo assumes that the reader is familiar with the DNS. Some
   familiarity with NSAPs is useful; see [2] or [7] for additional
   information.

2.  Background

   The reason for defining DNS mappings for NSAPs is to support CLNP in
   the Internet. Debugging with CLNP ping and traceroute is becoming
   more difficult with only numeric NSAPs as the scale of deployment
   increases. Current debugging is supported by maintaining and
   exchanging a configuration file with name/NSAP mappings similar in
   function to hosts.txt. This suffers from the lack of a central
   coordinator for this file and also from the perspective of scaling.
   The former is the most serious short-term problem. Scaling of a
   hosts.txt-like solution has well-known long-term scaling
   difficiencies.

   A second reason for this work is the proposal to use CLNP as an
   alternative to IP: "TCP and UDP with Bigger Addresses (TUBA), A
   Simple Proposal for Internet Addressing and Routing" [1]. For this to
   be practical, the DNS must be capable of supporting CLNP addresses.

3.  Scope

   The methods defined in this paper are applicable to all NSAP formats.
   This includes support for the notion of a custom-defined NSAP format
   based on an AFI obtained by the IAB for use in the Internet.

   As a point of reference, there is a distinction between registration
   and publication of addresses. For IP addresses, the IANA is the root

Manning & Colella                                               [Page 2]
RFC 1637                      DNS NSAP RRs                     June 1994

   registration authority and the DNS a publication method. For NSAPs,
   addendum two of the network service definition, ISO8348/Ad2 [7] is
   the root registration authority and this memo defines how the DNS is
   used as a publication method.

4.  Structure of NSAPs

   NSAPs are hierarchically structured to allow distributed
   administration and efficient routing. Distributed administration
   permits subdelegated addressing authorities to, as allowed by the
   delegator, further structure the portion of the NSAP space under
   their delegated control.  Accomodating this distributed authority
   requires that there be little or no a priori knowledge of the
   structure of NSAPs built into DNS resolvers and servers.
Show full document text