RFC 1637 (rfc1637) - Page 2 of 11

DNS NSAP Resource Records

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