RFC 1348 DNS NSAP RRs

Network Working Group                                     B. Manning
Request for Comments: 1348                           Rice University
Updates: RFCs 1034, 1035                                   July 1992

Записи DNS NSAP

DNS NSAP RRs

PDF

Статус документа

В этом документе определен экспериментальный протокол для сообщества Internet. Документ служит приглашением к дискуссии в целях развития протокола. Текущее состояние стандартизации протокола можно узнать из документа IAB Official Protocol Standards. Документ может распространяться без ограничений.

Введение

Данный документ RFC определяет формат двух новых записей о ресурсах (RR1) для системы доменных имен (DNS2), и резервирует соответствующую мнемонику типов DNS и цифровые коды. Этот формат может применяться с любыми предложениями, имеющими адрес переменного размера и предназначенными для CLNP3.

Документ предполагает знакомство читателя с системой DNS [3,4].

Предпосылки

В этом параграфе описано экспериментальное представление адресов NSAP в системе DNS. Для этого было несколько причин. Во-первых, представление обеспечивает простое документирование корректных адресов для использования в соответствующих CLNP хостах и маршрутизаторах.

Для поддержки NSAP требуется определить новую запись DNS (NSAP), в которой могут храниться более длинные адреса Internet (т. е., NSAP). Такая запись позволит отображать имена DNS на адреса NSAP и будет содержать данные для систем, которые могут применять TCP- или UDP-приложения Internet через CLNP.

Обратное преобразования (адреса NSAP в имена DNS) будет обеспечиваться за счет определения соответствующей записи о ресурсах. Эта запись, называемая NSAP-PTR, применяется по аналогии с записью in-addr.arpa.

Эти RR предназначены для использования в предложении [6] одного из членов рабочей группы NOOP в качестве адресов нового поколения сетей.

NSAP RR

Для NSAP RR определено мнемоническое обозначение NSAP и тип 22 (десятичное значение).

Номер протокола NSAP4 является уникальной строкой для транспортного сервиса OSI.

План нумерации следует RFC 1237 и определениями OSI для формата NSAP.

Запись NSAP использует формат

<owner> <ttl> <class> NSAP <length> <NSAP-address>

Все поля являются обязательными.

<length> показывает в октетах размер <NSAP-address>, как определено в разных национальных и международных стандартах;

<NSAP-address> содержит реальные октеты адреса, выделенного полномочным агентством. Формат адреса в первичных файлах зон (master file) представляет собой строку символов (<character-string>) синтаксически идентичную строкам в записях TXT и HINFO.

Формат NSAP не зависит от класса. Записи NSAP RR не требуют обработки раздела дополнений (additional section).

Например,

foo.bar.com.   IN NSAP 21 47000580ffff000000321099991111222233334444
host.school.de IN NSAP 17 39276f3100111100002222333344449876

Данные RR являются представлением цифр в формате ASCII, как двух значений <character-strings> (т. е., число символов в строке, затем сами символы).

NSAP-PTR RR

Для записей NSAP-PTR RR определено мнемоническое имя NSAP-PTR и код типа 23 (десятичный).

Функции этих записей аналогичны функциям записей PTR для адресов IP [4,7].

Запись NSAP-PTR использует формат

<NSAP-suffix> <ttl> <class> NSAP-PTR <owner>

Все поля являются обязательными.

<NSAP-suffix> указывает реальные значения октетов адреса, выделенные полномочным агентством для локальной (LOCAL) сети. В первичных файлах зон (master file) записи указываются в виде <character-string>, синтаксически идентично записям TXT и HINFO.

Записи NSAP-PTR не зависят от класса и не требуют обработки дополнительного раздела (additional section).

Например, записи

In net ff08000574.nsap-in-addr.arpa

будет соответствовать запись

444433332222111199990123000000ff NSAP-PTR foo.bar.com.

а записи

in net 11110031f67293.nsap-in-addr.arpa

будет соответствовать

67894444333322220000 NSAP-PTR host.school.de.

Данные RR являются представлением цифр в формате ASCII, как <character-string>.

Литература

[1] Stahl, M., “Domain Administrators Guide”, RFC 1032, Network Information Center, SRI International, November 1987.

[2] Lottor, M., “Domain Administrators Operations Guide”, RFC 1033, Network Information Center, SRI International, November, 1987.

[3] Mockapetris, P., “Domain Names – Concepts and Facilities”, RFC 1034, USC/Information Sciences Institute, November 1987.

[4] Mockapetris, P., “Domain Names – Implementation and Specification”, RFC 1035, USC/Information Sciences Institute, November 1987.

[5] Colella, R., Gardner, E., and R. Callon, “Guidelines for OSI NSAP Allocation in the Internet”, RFC 1237, NIST, Mitre, DEC, July 1991.

[6] Callon, R., “TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing”, Digital Equipment Corporation, RFC 1347, June 1992.

[7] Mockapetris, P., “DNS Encoding of Network Names and Other Types”, RFC 1101, USC/Information Sciences Institute, April 1989.

[8] ISO/IEC. Information Processing Systems — Data Communications — Network Service Definition Addendum 2: Network Layer Addressing. International Standard 8348/Addendum 2, ISO/IEC JTC 1, Switzerland, 1988.

[9] Bryant, P., “NSAPs”, PB660, IPTAG/92/23, SCIENCE AND ENGINEERING RESEARCH COUNCIL, RUTHERFORD APPLETON LABORATORY May 1992.

Вопросы безопасности

В этом документе не затрагиваются какие-либо вопросы безопасности.

Адрес автора

Bill Manning

Rice University – ONCS

PO Box 1892

6100 South Main

Houston, Texas 77251-1892

Phone: +1.713.285.5415

EMail: bmanning@rice.edu


Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Resource Record.

2Domain Name System.

3Connection Less Network Protocol.

4Network Service Access Protocol — протокол доступа в сеть.

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.