RFC 1637 (rfc1637) - Page 2 of 11
DNS NSAP Resource Records
Alternative Format: Original Text Document
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