Network Working Group C. Everhart
Request for Comments: 1183 Transarc
Updates: RFCs 1034, 1035 L. Mamakos
University of Maryland
R. Ullmann
Prime Computer
P. Mockapetris, Editor
ISI
October 1990
Новые определения DNS RR
New DNS RR Definitions
Статус документа
Этот документ определяет пять новых типов записей DNS для экспериментальных целей. RFC описывает экспериментальный протокол для Сообщества Internet и служит приглашением к обсуждению в целях развития протокола. Документ может распространяться свободно.
Введение
Этот документ определяет новые форматы записей RR для системы доменных имен (DNS) и резервирует соответствующие типы и цифровые коды. Определения приводятся в трех независимых разделах документа:
- расположение серверов баз данных AFS;
- местоположение ответственных лиц;
- представление адресов X.25 и ISDN и связывание маршрутов.
Все новые типы записей являются экспериментальными.
В данном документе предполагается знакомство читателя с DNS [3,4]. Приведенные в документе примеры являются иллюстративными и не обязательно отражают реальную ситуацию в Internet.
1. Расположение базы данных AFS
В этом документе определяется расширение DNS, позволяющее найти местоположение серверов как для AFS1, так и для среды OSF DCE2, использующей аутентификацию на базе HP/Apollo NCA, являющихся составными частями OSF DCE. Предполагается, что читатель знаком с AFS [5] и NCA [6].
Система AFS использует DNS для отображения доменных имен в имена серверов баз данных ячеек AFS. Служба именования DCE3 использует DNS аналогичным путем, отображая доменное имя ячейки на полномочные серверы имен для этой ячейки. Метод использует новый тип RR, которые обозначаются AFSDB и имеют код типа 18 (десятичное значение).
Записи AFSDB имеют следующий формат:
<owner> <ttl> <class> AFSDB <subtype> <hostname>
Оба поля RDATA являются обязательными для всех записей AFSDB. Поле <subtype> представляет собой 16-битовое целое число без знака. Поле <hostname> содержит доменное имя хоста, который является сервером для ячейки, заданной именем владельца (поле owner) RR.
Формат AFSDB RR не зависит от класса. Записи AFSDB требуют дополнительной обработки типа A для поля <hostname>. Таким образом, фактически разумней использовать новый код типа, нежели пытаться реализовать такую же функциональность с записями TXT RR.
Отметим, что формат AFSDB в master-файле идентичен формату MX. Для целей самой системы DNS субтип просто является целым числом. Современная семантика субтипа описаны ниже, но она может измениться в последующих RFC.
В случае субтипа 1 хост имеет сервер AFS Volume Location версии 3.0 для указанной ячейки AFS. В случае субтипа 2 хост имеет аутентифицированный сервер имен, содержащий узел корневого каталога ячейки для указанной именем ячейки DCE/NCA.
Использование субтипов обусловлено двумя причинами. Во-первых, пространство типов DNS RR ограничено. Во-вторых, предоставляемые услуги достаточно сильно различаются, что будет приводить к путанице для клиентов при попытках соединения с серверами ячеек, использующими протокол для одного сервиса, если ячейка предлагает только сервис другого типа.
В качестве примера использования таких RR предположим, что в Toaster Corporation развернутв AFS 3.0, но пока (еще) нет OSF DCE. Ячейка с именем toaster.com имеет три машины AFS 3.0 cell database server4: bigbird.toaster.com, ernie.toaster.com и henson.toaster.com. Эти машины будут указаны в трех записях AFSDB RR. В первичном файле эти записи могут иметь вид:
toaster.com. AFSDB 1 bigbird.toaster.com. toaster.com. AFSDB 1 ernie.toaster.com. toaster.com. AFSDB 1 henson.toaster.com.
В качестве другого примера использования таких RR предположим, что Femto College (домен femto.edu) развернул DCE и корневой каталог ячейки DCE обслуживается процессами, работающими на хостах green.femto.edu и turquoise.femto.edu. Кроме того, на файловых серверах DCE также применяются серверы поиска томов (совместимые с AFS 3.0) на хостах turquoise.femto.edu и orange.femto.edu. Эти машины будут указываться в записях AFSDB RR, которые в первичном файле могут иметь вид:
femto.edu. AFSDB 2 green.femto.edu. femto.edu. AFSDB 2 turquoise.femto.edu. femto.edu. AFSDB 1 turquoise.femto.edu. femto.edu. AFSDB 1 orange.femto.edu.
2. Ответственное лицо
Целью этого раздела является обеспечение стандартного метода связывания идентификатора ответственного лица с любым именем в системе DNS.
Система доменных имен функционирует, как распределенная базы данных, содержащая множество разных форм информации. Для конкретного имени или хоста можно узнать адрес IP, сведения о пересылке электронной почты, тип оборудования, операционную систему и многое другое.
Ключевой особенностью DNS является древовидная структура пространства имен, которое может быть поделено на части, называемые зонами, в целях распределения зон контроля и ответственности. Лицо, ответственное за данные зоны, указывается в записи SOA RR для этой зоны. В данном разделе описано расширение, которое позволяет назначить разных ответственных лиц для различных имен внутри зоны.
2.1. Идентификация ответственного лица
Зачастую оказывается желательной возможность идентификации ответственного лица для конкретного хоста. Если хост выключен или работает некорректно, зачастую непросто бывает связаться с теми, кто отвечает за устранение неполадок или ремонт хоста. Почта, отправленная по адресу POSTMASTER, не обеспечивает достаточно оперативной связи. Если хост является одной из множества рабочих станций, на этом хосте может просто не быть ответственного лица, с которым можно связаться.
Почтовый ящик POSTMASTER на хосте может быть удобен для решения проблем, связанных с электронной почтой, а также для связи с ответственным за зону лицом (запись SOA) при возникновении проблем с базой данных (DNS), однако запись RP позволяет связать позволяет связать почтовый ящик с лицом, которое не получает электронной почты или не связано непосредственно с проблемой (например, GATEWAY.ISI.EDU может указать адрес HOTLINE@BBN.COM, при этом GATEWAY может не получать электронной почты, а администратор зоны ISI окажется никак не связанным с работой шлюзов).
2.2. Запись RR для ответственного лица
Предлагается использовать новый тип RR5 с мнемоническим именем RP и кодом типа 17 (десятичный). Запись RP имеет следующий формат:
<owner> <ttl> <class> RP <mbox-dname> <txt-dname>
Оба поля RDATA являются обязательными и должны присутствовать во всех RP RR.
Первое поле <mbox-dname> указывает доменное имя, которое определяет почтовый адрес ответственного лица. Формат поля в master-файлах использует соглашения DNS для представления почтовых адресов, идентичные применяемым в поле RNAME записей SOA RR. При недоступности почтового ящика в качестве <mbox-dname> может быть указано имя корня домена (просто .).
Второе поле <txt-dname> указывает доменное имя, для которого имеются записи TXT RR. Впоследствии могут выполняться запросы для поиска соответствующих записей TXT в <txt-dname>. Это обеспечивает уровень косвенности, который позволяет ссылаться на запись из множества разных мест системы DNS. Имя корневого домена (.) может использоваться в качестве <txt-dname> для индикации отсутствия TXT_DNAME и связанных записей TXT RR.
Формат RP RR не зависит от класса. Записи RP не требуют дополнительной обработки раздела (дополнительная обработка TXT для <txt-dname> возможна в качестве опции, но только при запрете такой обработки для корня «.»).
Запись RR может быть связана с любым узлом системы DNS, а не только с ветвью дерева.
Запись TXT RR, связанная с TXT_DNAME, содержит текст в свободном формате, понятном человеку. Более подробное описание TXT RR приведено в документе [4].
В базе данных может присутствовать множество записей RP для одного имени. Значения TTL для них следует делать идентичными.
Примеры
Ниже приведено несколько примеров использования записей RP.
sayshell.umd.edu. A 128.8.1.14 MX 10 sayshell.umd.edu. HINFO NeXT UNIX WKS 128.8.1.14 tcp ftp telnet smtp RP louie.trantor.umd.edu. LAM1.people.umd.edu. LAM1.people.umd.edu. TXT ( "Louis A. Mamakos, (301) 454-2946, don't call me at home!" )
В этом примере почтовым адресом лица, ответственного за хост SAYSHELL.UMD.EDU, является louie@trantor.umd.edu. Запись TXT RR в LAM1.people.umd.edu обеспечивает дополнительную информацию об ответственном лице.
TERP.UMD.EDU. A 128.8.10.90 MX 10 128.8.10.90 HINFO MICROVAX-II UNIX WKS 128.8.10.90 udp domain WKS 128.8.10.90 tcp ftp telnet smtp domain RP louie.trantor.umd.edu. LAM1.people.umd.edu. RP root.terp.umd.edu. ops.CS.UMD.EDU. TRANTOR.UMD.EDU. A 128.8.10.14 MX 10 trantor.umd.edu. HINFO MICROVAX-II UNIX WKS 128.8.10.14 udp domain WKS 128.8.10.14 tcp ftp telnet smtp domain RP louie.trantor.umd.edu. LAM1.people.umd.edu. RP petry.netwolf.umd.edu. petry.people.UMD.EDU. RP root.trantor.umd.edu. ops.CS.UMD.EDU. RP gregh.sunset.umd.edu. . LAM1.people.umd.edu. TXT "Louis A. Mamakos (301) 454-2946" petry.people.umd.edu. TXT "Michael G. Petry (301) 454-2946" ops.CS.UMD.EDU. TXT "CS Operations Staff (301) 454-2943"
Этот набор записей включает два хоста TRANTOR.UMD.EDU и TERP.UMD.EDU, а также множество TXT RR. Отметим, что хосты TERP.UMD.EDU и TRANTOR.UMD.EDU ссылаются на одну пару записей TXT, хотя имена почтовых ящиков для этих хостов различаются (root.terp.umd.edu и root.trantor.umd.edu).
Здесь очевидны меры предосторожности, поскольку указаны 4 лица, к которым можно обратиться при возникновении проблем на хосте TRANTOR.UMD.EDU. В приведенном примере последняя запись RP RR для хоста TRANTOR.UMD.EDU указывает почтовый адрес (gregh.sunset.umd.edu), а не связанную с хостом запись TXT RR.
3. Адреса X.25 и ISDN, связывание маршрутов
В этом разделе описано экспериментальное представление адресов X.25 и ISDN в системе DNS, а также метод привязки маршрутов в сетях очень большого размера, аналогичный MX для маршрутизации почты.
Для описанных здесь записей имеется несколько экспериментальных применений. Эти RR обеспечивают простоту документирования корректных адресов для использования в статических конфигурациях IP/X.25 [11] и SMTP/X.25 [12].
Записи RR могут также автоматически применяться маршрутизаторами (обычно IP). Процедура будет отображать адрес IP на доменное имя, а то, в свою очередь, на каноническое имя, затем следовать записи RT и в заключение пытаться организовать соединение IP/X.25 для найденного адреса. В дополнение к этому заданные в конфигурации доменные имена могут статически преобразовываться в адреса IP, связанные с X.25/ISDN, а таблицы маршрутизации могут периодически обновлять.
Это обеспечивает функциональность, подобную ARP для распределенных сетей без широковещания и позволит расширять такие сети до сотен и тысяч хостов.
В дополнение к этому стандартизация привязки адресов упростит другие эксперименты по использованию X.25 и ISDN, особенно при серьезном тестировании интероперабельности. Основная работа в таких тестах заключается в создании статических таблиц, размер которых квадратично зависит от числа узлов.
Кроме того, эти записи RR могут использоваться в предложении одного из авторов [13] для сетей нового поколения.
3.1. Запись X25 RR
Запись X25 RR определяется с мнемоническим именем X25 и десятичным кодом типа 19.
Запись X25 имеет формат
<owner> <ttl> <class> X25 <PSDN-address>
Поле <PSDN-address> является обязательным для всех X25 RR.
Поле <PSDN-address> показывает адрес PSDN6 в формате X.121 [10], связанный с полем <owner>. Записи в master-файлах имеют формат <character-string>, синтаксически идентичный формату записей TXT и HINFO.
Формат записей X25 не зависит от класса. Записи X25 RR не требуют дополнительной обработки раздела.
Поле <PSDN-address> представляет собой строку десятичных цифр, начинающуюся с 4-значного кода DNIC7, как указано в стандарте X.121. Использование национальных префиксов (типа 0) недопустимо.
Например,
Relay.Prime.COM. X25 311061700956
3.2. Запись ISDN RR
Запись ISDN RR определяется с мнемоническим именем ISDN и десятичным кодом 20.
Номер ISDN8 является обычным телефонным номером. В намерения членов CCITT входит объединение всех телефонных сетей и сетей передачи данных в общий сервис.
План нумерации (E.163/E.164) совпадает с международным планом нумерации POTS9. В стандарте E.166 CCITT указано: «Пользователь телефонии E.163/E.164 может стать абонентом ISDN без смены телефонного номера.”
Запись ISDN имеет формат
<owner> <ttl> <class> ISDN <ISDN-address> <sa>
Поле <ISDN-address> является обязательным, <sa> – опциональным.
Значение <ISDN-address> указывает ISDN-номер абонента <owner> и значение DDI10 (если оно есть) в формате E.164 [8] и E.163 [7], ISDN и PSTN11. E.163 определяет коды стран, а E.164 — форму адресов. Записи в master-файлах используют формат <character-string>, синтаксически идентичный формату записей TXT и HINFO.
Поле <sa> задает субадрес (SA). Значение <sa> в master-файлах указывается в формате <character-string>, синтаксически идентичном формату записей TXT и HINFO.
Формат записей ISDN не зависит от класса, записи ISDN RR не требуют дополнительной обработки раздела.
Поле <ISDN-address> представляет собой строку символов (обычно десятичные цифры), начинающуюся с кода страны в соответствии с E.163 и заканчивающуюся номером DDI (если он имеется). Отметим, что ISDN в соответствии с Q.931 в общем случае может использовать любые символы IA5.
Поле <sa> представляет собой строку шестнадцатеричных цифр. Для цифр 0-9 конкретное представление при организации вызовов в соответствии с Q.931 идентично BCD.
Например,
Relay.Prime.COM. IN ISDN 150862028003217 sh.Prime.COM. IN ISDN 150862028003217 004
(отметим, что «1» указывает код страны для NAINA12, т. е. система «междугородных кодов» должна быть понятна жителям Северной Америки).
Данные RR являются цифрами в кодировке ASCII и представляются в форме одного или двух значений в формате <character-string> (число, за которым следуют символы).
Рекомендации CCITT E.166 [9] определяют префиксные коды для представления адресов ISDN (E.163/E.164) в формате адресации X.121 и PSDN (X.121) стандарта E.164. Это означает, что точные коды определяются на уровне стран и могут различаться в разных сетях. Хост, подключенный к сети ISDN может использовать адреса X25 и ISDN с добавлением локального префикса.
3.3. Запись RT RR
Запись RT13 RR определяется с мнемоническим именем RT и десятичным кодом 21.
Запись RT указывает маршрут для хостов, не имеющих своего адреса в распределенной сети. Запись используется аналогично MX RR.
Записи RT используют формат
<owner> <ttl> <class> RT <preference> <intermediate-host>
Оба поля RDATA являются обязательными для всех записей RT RR.
Первое поле <preference> представляет собой 16-битовое целое число, определяющее уровень предпочтения для маршрута. Более приоритетные маршруты обозначаются меньшими значениями.
Поле <intermediate-host> указывает доменное имя хоста, который будет служить промежуточной точкой на пути к хосту, заданному полем <owner>. Предполагается, что записи DNS RR, связанные с <intermediate-host> включают по крайней мере одну запись A, X25 или ISDN.
Формат RT RR не зависит от класса. Записи RT требуют дополнительной обработки раздела для записи X25, ISDN или A, связанной с хостом <intermediate-host>.
Например,
sh.prime.com. IN RT 2 Relay.Prime.COM. IN RT 10 NET.Prime.COM. *.prime.com. IN RT 90 Relay.Prime.COM.
Когда хост, ищущий записи DNS, пытается маршрутизаировать дейтаграмму, он сначала находит записи RT для хоста-адресата, которые указывают на хосты с адресными записями (A, X25, ISDN), совместимые с доступными хосту распределенными сетями. Если хост находит себя в наборе записей RT, он отбрасывает все записи RT, у которых уровень предпочтения не меньше его собственного. Если после этого записей RT не остается, он может использовать адресные записи самого адресата.
Для записей RT можно использовать шаблоны, как для MX. Цепочки записей RT некорректны, т. е., нельзя использовать записи RT RR для хоста, указанного записью RT.
Представление записей RT идентично представлению записей MX RR.
Литература
[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] Spector A., and M. Kazar, “Uniting File Systems”, UNIX Review, 7(3), pp. 61-69, March 1989.
[6] Zahn, et al., “Network Computing Architecture”, Prentice-Hall, 1989.
[7] International Telegraph and Telephone Consultative Committee, “Numbering Plan for the International Telephone Service”, CCITT Recommendations E.163., IXth Plenary Assembly, Melbourne, 1988, Fascicle II.2 (“Blue Book”).
[8] International Telegraph and Telephone Consultative Committee, “Numbering Plan for the ISDN Era”, CCITT Recommendations E.164., IXth Plenary Assembly, Melbourne, 1988, Fascicle II.2 (“Blue Book”).
[9] International Telegraph and Telephone Consultative Committee. “Numbering Plan Interworking in the ISDN Era”, CCITT Recommendations E.166., IXth Plenary Assembly, Melbourne, 1988, Fascicle II.2 (“Blue Book”).
[10] International Telegraph and Telephone Consultative Committee, “International Numbering Plan for the Public Data Networks”, CCITT Recommendations X.121., IXth Plenary Assembly, Melbourne, 1988, Fascicle VIII.3 (“Blue Book”); provisional, Geneva, 1978; amended, Geneva, 1980, Malaga-Torremolinos, 1984 and Melborne, 1988.
[11] Korb, J., “Standard for the Transmission of IP datagrams Over Public Data Networks”, RFC 877, Purdue University, September 1983.
[12] Ullmann, R., “SMTP on X.25”, RFC 1090, Prime Computer, February 1989.
[13] Ullmann, R., “TP/IX: The Next Internet”, Prime Computer (unpublished), July 1990.
[14] Mockapetris, P., “DNS Encoding of Network Names and Other Types”, RFC 1101, USC/Information Sciences Institute, April 1989.
Вопросы безопасности
Вопросы безопасности в данном документе не рассматриваются.
Адреса авторов
Craig F. Everhart
Transarc Corporation
The Gulf Tower
707 Grant Street
Pittsburgh, PA 15219
Phone: +1 412 338 4467
EMail: Craig_Everhart@transarc.com
Louis A. Mamakos
Network Infrastructure Group
Computer Science Center
University of Maryland
College Park, MD 20742-2411
Phone: +1-301-405-7836
Email: louie@Sayshell.UMD.EDU
Robert Ullmann 10-30
Prime Computer, Inc.
500 Old Connecticut Path
Framingham, MA 01701
Phone: +1 508 620 2800 ext 1736
Email: Ariel@Relay.Prime.COM
Paul Mockapetris
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: 213-822-1511
EMail: pvm@isi.edu
Перевод на русский язык
Николай Малых
1Изначально, Andrew File System. AFS – зарегистрированный торговый знак Transarc Corporation
2Open Software Foundation’s Distributed Computing Environment – среда распределенных вычислений фонда открытых программ.
3DCE Naming service.
4Сервер баз данных ячейки AFS 3.0.
5Responsible Person — ответственное лицо.
6Public Switched Data Network — коммутируемая сеть общего пользования для передачи данных.
7Data Network Identification Code — цифровой код идентификации сети.
8Integrated Service Digital Network — интегрированная цифровая сеть обслуживания.
9Plain Old Telephone Service – старая «плоская» телефонная сеть (букв). Телефонная сеть общего пользования.
10Direct Dial In — прямой номер для входящих вызовов.
11Public Switched Telephone Network — телефонная сеть общего пользования.
12North American Integrated Numbering Area — нумерация в Северной Америке.
13Route Through — маршрут через.
