RFC 1706 HISTORIC DNS · OSI · ADDRESSING
DNS NSAP records: DNS NSAP Resource Records
How the DNS was taught to store OSI network addresses (NSAPs) under a domain name, and to look them up in reverse.
RFC EDITOR
Manning, B. and R. Colella, "DNS NSAP Resource Records", RFC 1706, DOI 10.17487/RFC1706, October 1994, <https://www.rfc-editor.org/info/rfc1706>.
BIBTEX
@misc{rfc1706,
series = {Request for Comments},
number = 1706,
howpublished = {RFC 1706},
publisher = {RFC Editor},
doi = {10.17487/RFC1706},
url = {https://www.rfc-editor.org/info/rfc1706},
author = {B. Manning and R. Colella},
title = {{DNS NSAP Resource Records}},
pagetotal = 10,
year = 1994,
month = oct,
} LINEAGE · FROM THE RFC INDEXOpen full graph →
RFC text
Contents
Network Working Group B. Manning
Request for Comments: 1706 ISI
Obsoletes: 1637, 1348 R. Colella
Category: Informational NIST
October 1994
DNS NSAP Resource Records
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
OSI lower layer protocols, comprising the connectionless network
protocol (CLNP) and supporting routing protocols, are deployed in
some parts of the global Internet. Maintenance and debugging of CLNP
connectivity is greatly aided by 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.
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.
This document obsoletes RFC 1348 and RFC 1637.
1. Introduction
OSI lower layer protocols, comprising the connectionless network
protocol (CLNP) [5] and supporting routing protocols, are deployed in
some parts of the global Internet. Maintenance and debugging of CLNP
connectivity is greatly aided by support in the Domain Name System
(DNS) [7] [8] for mapping between names and NSAP (network service
access point) addresses [6] [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 [1] or Annex A of [6] for
additional information.
2. Background
The reason for defining DNS mappings for NSAPs is to support the
existing CLNP deployment in the Internet. Debugging with CLNP ping
and traceroute has become more difficult with only numeric NSAPs as
the scale of deployment has increased. 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 describes the most serious short-term
problem. Scaling of a hosts.txt-like solution has well-known long-
term scaling difficiencies.
3. Scope
The methods defined in this paper are applicable to all NSAP formats.
As a point of reference, there is a distinction between registration
and publication of addresses. For IP addresses, the IANA is the root
registration authority and the DNS a publication method. For NSAPs,
Annex A of the network service definition, ISO8348 [6], describes 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.
For the purposes of this memo, NSAPs can be thought of as a tree of
identifiers. The root of the tree is ISO8348 [6], and has as its
immediately registered subordinates the one-octet Authority and
Format Identifiers (AFIs) defined there. The size of subsequently-
defined fields depends on which branch of the tree is taken. The
depth of the tree varies according to the authority responsible for
defining subsequent fields.
An example is the authority under which U.S. GOSIP defines NSAPs [2].
Under the AFI of 47, NIST (National Institute of Standards and
Technology) obtained a value of 0005 (the AFI of 47 defines the next
field as being two octets consisting of four BCD digits from the
International Code Designator space [3]). NIST defined the subsequent
fields in [2], as shown in Figure 1. The field immediately following
0005 is a format identifier for the rest of the U.S. GOSIP NSAP
structure, with a hex value of 80. Following this is the three-octet
field, values for which are allocated to network operators; the
registration authority for this field is delegated to GSA (General
Services Administration).
The last octet of the NSAP is the NSelector (NSel). In practice, the
NSAP minus the NSel identifies the CLNP protocol machine on a given
system, and the NSel identifies the CLNP user. Since there can be
more than one CLNP user (meaning multiple NSel values for a given
"base" NSAP), the representation of the NSAP should be CLNP-user
independent. To achieve this, an NSel value of zero shall be used
with all NSAP values stored in the DNS. An NSAP with NSel=0
identifies the network layer itself. It is left to the application
retrieving the NSAP to determine the appropriate value to use in that
instance of communication.
When CLNP is used to support TCP and UDP services, the NSel value
used is the appropriate IP PROTO value as registered with the IANA.
For "standard" OSI, the selection of NSel values is left as a matter
of local administration. Administrators of systems that support the
OSI transport protocol [4] in addition to TCP/UDP must select NSels
for use by OSI Transport that do not conflict with the IP PROTO
values.
|--------------|
| <-- IDP --> |
|--------------|-------------------------------------|
| AFI | IDI | <-- DSP --> |
|-----|--------|-------------------------------------|
| 47 | 0005 | DFI | AA |Rsvd | RD |Area | ID |Sel |
|-----|--------|-----|----|-----|----|-----|----|----|
octets | 1 | 2 | 1 | 3 | 2 | 2 | 2 | 6 | 1 |
|-----|--------|-----|----|-----|----|-----|----|----|
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
DFI DSP Format Identifier
AA Administrative Authority
Rsvd Reserved
RD Routing Domain Identifier
Area Area Identifier
ID System Identifier
SEL NSAP Selector
Figure 1: GOSIP Version 2 NSAP structure.
In the NSAP RRs in Master Files and in the printed text in this memo,
NSAPs are often represented as a string of "."-separated hex values.
The values correspond to convenient divisions of the NSAP to make it
more readable. For example, the "."-separated fields might correspond
to the NSAP fields as defined by the appropriate authority (RARE,
U.S. GOSIP, ANSI, etc.). The use of this notation is strictly for
readability. The "."s do not appear in DNS packets and DNS servers
can ignore them when reading Master Files. For example, a printable
representation of the first four fields of a U.S. GOSIP NSAP might
look like
47.0005.80.005a00
and a full U.S. GOSIP NSAP might appear as
47.0005.80.005a00.0000.1000.0020.00800a123456.00.
Other NSAP formats have different lengths and different
administratively defined field widths to accomodate different
requirements. For more information on NSAP formats in use see RFC
1629 [1].
5. The NSAP RR
The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22
(decimal) and is used to map from domain names to NSAPs. Name-to-NSAP
mapping in the DNS using the NSAP RR operates analogously to IP
address lookup. A query is generated by the resolver requesting an
NSAP RR for a provided domain name.
NSAP RRs conform to the top level RR format and semantics as defined
in Section 3.2.1 of RFC 1035.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE = NSAP |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS = IN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
* NAME: an owner name, i.e., the name of the node to which this
resource record pertains.
* TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal).
* CLASS: two octets containing the RR IN CLASS code of 1.
* TTL: a 32 bit signed integer that specifies the time interval in
seconds that the resource record may be cached before the source
of the information should again be consulted. Zero values are
interpreted to mean that the RR can only be used for the
transaction in progress, and should not be cached. For example,
SOA records are always distributed with a zero TTL to prohibit
caching. Zero values can also be used for extremely volatile data.
* RDLENGTH: an unsigned 16 bit integer that specifies the length in
octets of the RDATA field.
* RDATA: a variable length string of octets containing the NSAP.
The value is the binary encoding of the NSAP as it would appear in
the CLNP source or destination address field. A typical example of
such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is
20 (decimal); "."s have been omitted to emphasize that they don't
appear in the DNS packets.
39840f80005a0000000001e13708002010726e00
NSAP RRs cause no additional section processing.
6. NSAP-to-name Mapping Using the PTR RR
The PTR RR is defined in RFC 1035. This RR is typically used under
the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names.
Similarly, the PTR RR is used to map from NSAPs to domain names under
the "NSAP.INT" domain. A domain name is generated from the NSAP
according to the rules described below. A query is sent by the
resolver requesting a PTR RR for the provided domain name.
A domain name is generated from an NSAP by reversing the hex nibbles
of the NSAP, treating each nibble as a separate subdomain, and
appending the top-level subdomain name "NSAP.INT" to it. For example,
the domain name used in the reverse lookup for the NSAP
47.0005.80.005a00.0000.0001.e133.ffffff000162.00
would appear as
0.0.2.6.1.0.0.0.f.f.f.f.f.f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0. \
0.8.5.0.0.0.7.4.NSAP.INT.
[Implementation note: For sanity's sake user interfaces should be
designed to allow users to enter NSAPs using their natural order,
i.e., as they are typically written on paper. Also, arbitrary "."s
should be allowed (and ignored) on input.]
7. Master File Format
The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files
conforms to Section 5, "Master Files," of RFC 1035. Below are
examples of the use of these RRs in Master Files to support name-to-
NSAP and NSAP-to-name mapping.
The NSAP RR introduces a new hex string format for the RDATA field.
The format is "0x" (i.e., a zero followed by an 'x' character)
followed by a variable length string of hex characters (0 to 9, a to
f). The hex string is case-insensitive. "."s (i.e., periods) may be
inserted in the hex string anywhere after the "0x" for readability.
The "."s have no significance other than for readability and are not
propagated in the protocol (e.g., queries or zone transfers).
;;;;;;
;;;;;; Master File for domain nsap.nist.gov.
;;;;;;
@ IN SOA emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. (
1994041800 ; Serial - date
1800 ; Refresh - 30 minutes
300 ; Retry - 5 minutes
604800 ; Expire - 7 days
3600 ) ; Minimum - 1 hour
IN NS emu.ncsl.nist.gov.
IN NS tuba.nsap.lanl.gov.
;
;
$ORIGIN nsap.nist.gov.
;
; hosts
;
bsdi1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00
IN A 129.6.224.161
IN HINFO PC_486 BSDi1.1
;
bsdi2 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
IN A 129.6.224.162
IN HINFO PC_486 BSDi1.1
;
cursive IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00
IN A 129.6.224.171
IN HINFO PC_386 DOS_5.0/NCSA_Telnet(TUBA)
;
infidel IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00
IN A 129.6.55.164
IN HINFO PC/486 BSDi1.0(TUBA)
;
; routers
;
cisco1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00
IN A 129.6.224.151
IN A 129.6.225.151
IN A 129.6.229.151
;
3com1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00
IN A 129.6.224.111
IN A 129.6.225.111
IN A 129.6.228.111
;;;;;;
;;;;;; Master File for reverse mapping of NSAPs under the
;;;;;; NSAP prefix:
;;;;;;
;;;;;; 47.0005.80.005a00.0000.0001.e133
;;;;;;
@ IN SOA emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. (
1994041800 ; Serial - date
1800 ; Refresh - 30 minutes
300 ; Retry - 5 minutes
604800 ; Expire - 7 days
3600 ) ; Minimum - 1 hour
IN NS emu.ncsl.nist.gov.
IN NS tuba.nsap.lanl.gov.
;
;
$ORIGIN 3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT.
;
0.0.1.6.1.0.0.0.f.f.f.f.f.f IN PTR bsdi1.nsap.nist.gov.
;
0.0.2.6.1.0.0.0.f.f.f.f.f.f IN PTR bsdi2.nsap.nist.gov.
;
0.0.1.7.1.0.0.0.f.f.f.f.f.f IN PTR cursive.nsap.nist.gov.
;
0.0.4.6.1.0.0.0.f.f.f.f.f.f IN PTR infidel.nsap.nist.gov.
;
0.0.1.5.1.0.0.0.a.a.a.a.a.a IN PTR cisco1.nsap.nist.gov.
;
0.0.1.1.1.0.0.0.a.a.a.a.a.a IN PTR 3com1.nsap.nist.gov.
8. Security Considerations
Security issues are not discussed in this memo.
9. Authors' Addresses
Bill Manning
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA. 90292
USA
Phone: +1.310.822.1511
EMail: bmanning@isi.edu
Richard Colella
National Institute of Standards and Technology
Technology/B217
Gaithersburg, MD 20899
USA
Phone: +1 301-975-3627
Fax: +1 301 590-0932
EMail: colella@nist.gov
10. References
[1] Colella, R., Gardner, E., Callon, R., and Y. Rekhter, "Guidelines
for OSI NSAP Allocation inh the Internet", RFC 1629, NIST,
Wellfleet, Mitre, T.J. Watson Research Center, IBM Corp., May
1994.
[2] GOSIP Advanced Requirements Group. Government Open Systems
Interconnection Profile (GOSIP) Version 2. Federal Information
Processing Standard 146-1, U.S. Department of Commerce, National
Institute of Standards and Technology, Gaithersburg, MD, April
1991.
[3] ISO/IEC. Data interchange - structures for the identification of
organization. International Standard 6523, ISO/IEC JTC 1,
Switzerland, 1984.
[4] ISO/IEC. Connection oriented transport protocol specification.
International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986.
[5] ISO/IEC. Protocol for Providing the Connectionless-mode Network
Service. International Standard 8473, ISO/IEC JTC 1,
Switzerland, 1986.
[6] ISO/IEC. Information Processing Systems -- Data Communications --
Network Service Definition. International Standard 8348, ISO/IEC
JTC 1, Switzerland, 1993.
[7] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[8] Mockapetris, P., "Domain Names -- Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
AI ELI5
On this page
PROBLEMOperators running OSI's CLNP in the Internet had to debug with numeric NSAP addresses and a shared name/address file, which lacked a central coordinator and scaled poorly.
MECHANISMA new DNS resource record, NSAP (TYPE 22), maps a domain name to a binary NSAP. Reverse lookups reuse the PTR record under the NSAP.INT domain, with the NSAP's hex digits reversed one per label.
STATUS TODAYThe RFC is now marked Historic. It obsoletes RFC 1348 and RFC 1637, and the unit metadata lists RFC 9121 as updating it.
§1Why NSAPs Needed Names
OSI lower layer protocols, including the connectionless network protocol (CLNP) and its routing protocols, were deployed in some parts of the Internet. Maintaining and debugging CLNP is easier if the Domain Name System can map between names and NSAP (network service access point) addresses.
At the time, debugging with CLNP ping and traceroute got harder as deployment grew, because only numeric NSAPs were available. People kept and swapped a configuration file of name/NSAP pairs, similar to hosts.txt. The RFC names two problems: nobody coordinated the file, and a hosts.txt-style approach scales badly.
The memo defines one new resource record for name-to-NSAP mapping. It works with any NSAP format. It treats DNS only as a way to publish addresses; registration of NSAPs stays with the authority described in ISO 8348.
Long number addresses are hard to remember, so people kept a messy shared list of names. This gives them a proper name book instead.
§2How NSAPs Are Structured
NSAPs are hierarchical so that authority can be handed down and routing stays efficient. The RFC asks DNS resolvers and servers to know little or nothing in advance about NSAP structure, because delegated authorities define their own fields. It describes NSAPs as a tree whose root is ISO 8348 and whose first level is the one-octet Authority and Format Identifiers (AFIs).
As an example it walks through the U.S. GOSIP layout: AFI 47, then the value 0005 that NIST obtained, then a format identifier 80, then a three-octet field allocated to network operators through GSA, and so on down to the last octet.
That last octet is the NSelector (NSel), which identifies the CLNP user. Because one system may have several, all NSAPs stored in the DNS use NSel=0, and the application decides which value to use. When CLNP carries TCP and UDP, the NSel is the IANA-registered IP PROTO value.
For readability NSAPs are written with periods between hex groups, such as 47.0005.80.005a00. The periods never appear in DNS packets.
An NSAP is like a long address with country, city, street and house number. The last number says which person in the house should get the message, and the name book always writes zero there.
§3The NSAP Resource Record
The record has the mnemonic NSAP and TYPE code 22 (decimal). A query asks the resolver for an NSAP record for a domain name, much like an IP address lookup. The record follows the standard resource record layout of RFC 1035, with these fields:
NAME: the owner name.TYPE: 22.CLASS: IN, code 1.TTL: a 32-bit signed integer giving seconds the record may be cached; zero means use only for the transaction in progress.RDLENGTH: an unsigned 16-bit length in octets.RDATA: the binary NSAP exactly as it would appear in a CLNP source or destination address field.
The RFC's sample NSAP, 39840f80005a0000000001e13708002010726e00, has an RDLENGTH of 20. NSAP records cause no additional section processing.
The record is a small card with the name on the front and the long number address on the back, plus a note saying how long to keep the card before checking again.
- 22TYPE — The NSAP resource record type code (decimal).
- 1CLASS IN — The Internet class code used with the record.
- 0NSel — NSelector value used for every NSAP stored in the DNS.
§4Finding a Name from an NSAP
Going the other way uses the existing PTR record from RFC 1035. That record normally lives under IN-ADDR.ARPA for IPv4 addresses. For NSAPs it lives under the NSAP.INT domain.
To build the name, take the NSAP's hex digits (nibbles), reverse their order, treat each nibble as its own subdomain label, and append NSAP.INT. A resolver then asks for a PTR record at that name. The RFC suggests that user interfaces let people type NSAPs in their natural order and ignore stray periods.
To look up a name from a number, you spell the number backwards, one digit at a time, and look in a special section of the book.
NSAP and its reverse lookup name
NSAP:
47.0005.80.005a00.0000.0001.e133.ffffff000162.00
Reverse lookup name:
0.0.2.6.1.0.0.0.f.f.f.f.f.f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0. \
0.8.5.0.0.0.7.4.NSAP.INT.§5Master Files and Security
In master files, NSAP and PTR records follow Section 5 of RFC 1035. The NSAP record adds one new RDATA format: 0x followed by a variable-length string of hex digits. It is case-insensitive, and periods after the 0x may be added for readability but are not sent in queries or zone transfers.
The RFC includes a sample zone for nsap.nist.gov with hosts such as bsdi1 and routers such as cisco1, each with an NSAP record and often A records, plus a matching reverse zone with PTR records.
The security section says only that security issues are not discussed in the memo.
The examples show a real-looking page from the name book, with computers and their long numbers. The RFC does not talk about safety at all.
§6References
[1]RFC 1629Colella, R., Gardner, E., Callon, R., and Y. Rekhter, "Guidelines for OSI NSAP Allocation in the Internet", RFC 1629, May 1994.May 1994
[2]GOSIP Advanced Requirements Group. Government Open Systems Interconnection Profile (GOSIP) Version 2. FIPS 146-1, April 1991.
[6]ISO/IEC. Information Processing Systems -- Data Communications -- Network Service Definition. International Standard 8348, 1993.
[7]RFC 1034Mockapetris, P., "Domain Names -- Concepts and Facilities", STD 13, RFC 1034, November 1987.November 1987[8]RFC 1035Mockapetris, P., "Domain Names -- Implementation and Specification", STD 13, RFC 1035, November 1987.November 1987