RFC 1101 DNS Encoding of Network Names and Other Types

Опубликовано 21.04.1989 автором Nikolai Malykh 
Network Working Group                                 P. Mockapetris
Request for Comments: 1101                                       ISI
Updates: RFCs 1034, 1035                                  April 1989

Представление имен сетей и других типов в DNS

DNS Encoding of Network Names and Other Types

PDF

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

В этом RFC предложены два расширения для системы доменных имен DNS1:

  • метод ввода и поиска RR, обеспечивающих отображения сетевых имен на числовые значения и обратно;

  • идея общего метода описания отображений между произвольными идентификаторами и числовыми значениями.

Метод отображения между именами и адресами предлагается в качестве стандарта, а идея общего метода отображения в качестве экспериментальной.

Данный RFC предполагает знакомство читателя с системой DNS [RFC 1034, RFC 1035] и ее применением. Данные в документе приводятся с обучающими целями и не обязательно отражают реальную картину в сети Internet.

Документ можно распространять без ограничений.

2. Введение

Система DNS является расширяемой и может применяться для практически не ограниченного числа типов данных, пространств имен и т. п. Иногда требуется определять новые типы, а также пересматривать и удалять имеющиеся (например, MX взамен MD и MF [RFC 974]), меняя описания, приведенные в [RFC 973]. Данный RFC описывает изменения, обусловленные общей необходимостью отображения между именами и значениями, а также конкретной потребностью поддержки сетевых имен.

Пользователям хотят применять DNS для преобразования сетевых имен в адреса и обратно. Это единственное из свойств файлов-отображения HOSTS.TXT, которое не было перенесено в DNS. При разработке методов таких преобразований требуется решить два важных вопроса:

  • необходимость поиска компромиссов в части контроля за сетевыми именами, синтаксиса этих имен, совместимости с имеющимися системами и т. п.;

  • желание разработать метод, который окажется достаточно хорош для использования в будущих расширениях (например, отображение между именами и номерами портов TCP, именами и номерами автономных систем, именами X.500 RDN2 и серверами).

Эти требования было непросто «примирить» в части сетевых имен по причине желательности унифицировать поддержку номеров сетей с имеющимися адресами для поддержки имен хостов. Поддержка преобразования адресов в имена реализована в форме раздела IN-ADDR.ARPA в пространстве имен DNS. По этой причине данный RFC описывает структуру для доменных имен, которая обеспечивает поддержку имен хостов, а также семейство структур для будущих функций YP3 (типа отображения между именами и номерами портов TCP).

Эти структуры описаны в последующих параграфах. Каждая структура обсуждается независимо в части ее организации и конкретных требований.

Мы хотим избежать определения структур и методов, которые могут работать, но не делают этого по причине безразличия или ошибок системных администраторов, поддерживающих базу данных. Примером таких структур могут служить записи WKS RR. Таким образом, предпочитая распространение общего метода, мы тем не менее признаем, что таблицы с централизованным управлением (такие, как HOSTS.TXT) обычно более согласованы, хотя и более трудоемки в поддержке. По этой причине мы рекомендуем специфические методы для отображения имен сетей, адресов и подсетей, а также экземпляры общего метода для отображений между номерами и именами сетей (выделяются централизованно SRI Network Information Center – NIC).

3. Имена сетей

При разработке решения принимались во внимание синтаксис сетевых имен, предоставляемые отображения, а также возможность поддержки аналогичных функций на уровне подсетей.

3.1. Синтаксис сетевых имен

Сетевые имена в соответствии с [RFC 952] представляют собой строки букв и цифр размером до 24 символов, начинающиеся с буквы. Во всех позициях строк имен, за исключением крайних, допускается также использование символов точки (.) и дефиса (-). Такой же формат имен хостов использовался до создания DNS. Совместимость с существующими именами может служить целью любой новой схемы.

Однако текущий синтаксис используется для определения «плоского» пространства имен и, следовательно, может препятствовать использованию некоторых имен хостов в системе с распределенным именованием. Существует мнение о целесообразности централизованного (NIC) выделения имен и управления ими, наряду с распределением номеров, однако большинство склоняется к необходимости локального управления сетевыми именами. Сохранение плоского пространства имен в принципе возможно путем использования старых имен в качестве последней метки (компоненты) сетевого имени, однако такое решение сильно усложняет задачу и требует разработки множества правил именования хостов и сетей.

Поэтому мы предполагаем, что синтаксис сетевых имен будет совпадать с расширенным синтаксисом имен хостов, предложенным в [HR]. В новом синтаксисе имена могут начинаться с цифр, если получаемое в результате представление имени не порождает конфликтов с адресами IP в десятичном представлении с разделением точками. Например, имена 3Com.COM или 3M.COM допустимы, но имя 26.0.0.73.COM использовать нельзя. Дополнительную информацию об именовании можно найти в работе [HR].

Имена сетей могут образовываться так же, как имена хостов. Администратор получит возможность выбора сетевых имен во всех управляемых им доменах, а также задавать номера сетей для имен в своих доменах IN-ADDR.ARPA. Таким образом, для сети ARPANET могут использоваться имена NET.ARPA, ARPANET.ARPA или Arpa-network.MIL в зависимости от предпочтений владельца.

3.2. Отображения

Желаемые отображения в порядке снижения уровня их важности перечислены ниже.

  • Отображение адресов IP или номеров сетей на имена сетей.

    Это отображение предназначено для отладки и отображения различных состояний. Преобразование адресов IP в номера сетей хорошо известно для IP-адресов классов A, B, C и основано на простой операции маскирования. Потребности для других классов адресов еще не определены и в данном RFC не обсуждаются.

  • Отображение имен сетей на адреса сетей.

    Эта потребность не столь очевидна, но отображение, обратное предыдущему, весьма желательно.

  • Отображение организаций на имена и номера их сетей.

    Такая возможность будет полезна, поскольку пользователи не всегда способны угадать локальные имена компьютеров, а названия организаций обычно известны.

  • Аналогичные приведенным выше отображения на уровне подсетей (включая вложенные).

    Основным применением является возможность идентифицировать все подсети для заданной сети IP. Другим применением является определение масок подсетей.

3.3. Раздел адресов сетей в пространстве имен

Рассмотренный выше синтаксис сетевых имен позволяет организовать доменные имена, включающие отображение сетевых имен на различные количественные значения, но нужен также раздел пространства имен, организованный по номерам сетей и подсетей для выполнения обратных отображений.

Имеется несколько вариантов, перечисленных ниже.

  • Номеров сетей, которые уже выделены и делегированы в разделе IN-ADDR.ARPA пространства имен.

    Например, 10.IN-ADDR.ARPA для сети класса A 10, 2.128.IN-ADDR.ARPA для сети класса B 128.2 и т.п.

  • Адреса с нулями п поле номера хоста (Host-zero address) в дереве IN-ADDR.ARPA (использование таких адресов для реальных хостов запрещено по причине возникновения конфликта)

    Например, 0.0.0.10.IN-ADDR.ARPA для сети класса A 10, 0.0.2.128.IN-ADDR.ARPA для сети класса B 128.2 и т. п. Подобно первому варианту эта схема используется вместе с делегированием пространства имен для распределенного управления.

    Основным преимуществом этой схемы является удобство именования как сетей, так и подсетей. Другим преимуществом является использование свободных имен, что избавляет организации от необходимости проверки баз данных имен в домене.

  • Новый раздел в пространстве имен.

    Этот вариант обеспечивает большую свободу выбора, но он вызывает необходимость делегирования нового пространства имен. Поскольку пространство адресов IP тесно связано с пространством номеров сетей, многие считают, что связанные с созданием нового пространства издержки приведут к возникновению синдрома WKS (на февраль 1989 было делегировано около 400 разделов дерева IN-ADDR.ARPA, используемых в основном на границах сетей).

4. Специфика отображения имен сетей

Предлагаемое решение использует информацию, хранящуюся в нескольких местах.

  • Имена в дереве IN-ADDR.ARPA с нулями в относящейся к хосту части адреса IP. Такой же метод может применяться для подсетей, включая вложенные. Например, 0.0.0.10.IN-ADDR.ARPA. Для сети 10.

    Здесь хранятся два типа информации: записи PTR RR, которые указывают на имя сети в разделе данных, и записи A RR, присутствующие при наличии подсетей. Если присутствует тип A RR, в его данных указывается маска. Общая форма имеет вид

    <reversed-host-zero-number>.IN-ADDR.ARPA. PTR <network-name>
<reversed-host-zero-number>.IN-ADDR.ARPA. A <subnet-mask>

    Например,

0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA.

или

0.0.2.128.IN-ADDR.ARPA. PTR cmu-net.cmu.edu.
                        A   255.255.255.0

В общем случае эта информация будет добавляться в первичный файл некого домена IN-ADDR.ARPA для каждой вовлеченной в процесс сети. Похожие записи RR могут использоваться и для подсетей host-zero.

  • Имена сетей.

    Данные сохраняются в записях PTR RR, указывающих на элементы host-zero, в форме:

<network-name> ptr <reversed-host-zero-number>.IN-ADDR.ARPA

Например,

ARPANET.ARPA. PTR 0.0.0.10.IN-ADDR.ARPA.

или

isi-net.isi.edu. PTR 0.0.9.128.IN-ADDR.ARPA.

В общем случае эта информация будет включаться в первичный файл для доменного имени организации. Имеется также другой файл, в котором информация хранится под IN-ADDR.ARPA. Похожие записи PTR RR могут применяться и для имен подсетей.

  • Имена, соответствующие организациям.

    Данные в этом случае содержат одну или множество записей PTR RR, указывающих в IN-ADDR.ARPA имена, соответствующие элементам host-zero для сетей.

    Например,

        ISI.EDU.        PTR     0.0.9.128.IN-ADDR.ARPA.

        MCC.COM.        PTR     0.167.5.192.IN-ADDR.ARPA.
                        PTR     0.168.5.192.IN-ADDR.ARPA.
                        PTR     0.169.5.192.IN-ADDR.ARPA.
                        PTR     0.0.62.128.IN-ADDR.ARPA.

4.1. Простой пример

ARPANET представляет собой сеть класса A без подсетей. В добавляемых записях RR предполагается, что в качестве имени сети выбрано ARPANET.ARPA.

   ARPA.                   PTR     0.0.0.10.IN-ADDR.ARPA.

   ARPANET.ARPA.           PTR     0.0.0.10.IN-ADDR.ARPA.

   0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.

Первая запись говорит, что организация с именем ARPA владеет сетью 10 (она может владеть также другими сетями, которые будут представляться дополнительными записями RR). Вторая запись говорит о том, что сетевое имя ARPANET.ARPA. Отображается на сеть 10. Последняя запись показывает, что сеть 10 называется ARPANET.ARPA.

Отметим, что все обычные записи для хостов и соответствующие им записи IN-ADDR.ARPA должны сохраняться в файле.

4.2. Усложненный пример с подсетями

Сеть ISI имеет номер 128.9 (класс B). Предположим, что в сети ISI используется два уровня подсетей — первый уровень использует 8 битов адреса, второй – 4 (маски FFFFFF00 и FFFFFFF0).

Ниже приведены записи RR, которые будут добавлены в первичный файл ISI для домена ISI.EDU.

   ; Define network entry — задание сети
   isi-net.isi.edu.                PTR  0.0.9.128.IN-ADDR.ARPA.

   ; Define first level subnets — задание подсети 1-го уровня
   div1-subnet.isi.edu.            PTR  0.1.9.128.IN-ADDR.ARPA.
   div2-subnet.isi.edu.            PTR  0.2.9.128.IN-ADDR.ARPA.

   ; Define second level subnets — задание подсети 2-го уровня
   inc-subsubnet.isi.edu.          PTR  16.2.9.128.IN-ADDR.ARPA.

   in the 9.128.IN-ADDR.ARPA zone:

   ; Define network number and address mask — задание номера сети и маски адресов
   0.0.9.128.IN-ADDR.ARPA.         PTR  isi-net.isi.edu.
                                   A    255.255.255.0  ;aka X'FFFFFF00'

   ; Define one of the first level subnet numbers and masks  
   ; — задание номера и маски подсети 1-го уровня 
   0.1.9.128.IN-ADDR.ARPA.         PTR  div1-subnet.isi.edu.
                                   A    255.255.255.240 ;aka X'FFFFFFF0'

   ; Define another first level subnet number and mask
   ; — задание номера и маски другой подсети 1-го уровня
   0.2.9.128.IN-ADDR.ARPA.         PTR  div2-subnet.isi.edu.
                                   A    255.255.255.240 ;aka X'FFFFFFF0'

   ; Define second level subnet number — задание номера подсети 2-го уровня 
   16.2.9.128.IN-ADDR.ARPA.        PTR  inc-subsubnet.isi.edu.

Предполагается, что сеть ISI имеет имя isi-net.isi.edu., подсети первого уровня именуются div1-subnet.isi.edu. и div2-subnet.isi.edu., а подсеть второго уровня называется inc-subsubnet.isi.edu. (в реальности число подсетей первого и второго уровня существенно больше, но для иллюстрации вполне достаточно 3 подсетей).

4.3. Процедура определения имени по адресу IP

В зависимости от класса адреса IP (A, B или C) маскируется 1, 2 или 3 старших байта, соответственно. Порядок октетов меняется на обратный, добавляется суффикс IN-ADDR.ARPA и выполняется запрос PTR.

Для примера предположим IP-адрес 10.0.0.51.

  1. Поскольку сеть относится к классу A, используем маску FF000000 и получаем 10.0.0.0.

  2. Создаем имя 0.0.0.10.IN-ADDR.ARPA.

  3. Выполняем запрос PTR и получаем отклик

    0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA.

  4. Из отклика видно, что сеть использует имя ARPANET.ARPA.

Выберем для второго примера IP-адрес 128.9.2.17.

  1. Поскольку сеть относится к классу B, используется маска FFFF0000, дающая в результате 128.9.0.0.

  2. Создаем имя 0.0.9.128.IN-ADDR.ARPA.

  3. Делаем запрос PTR и получаем ответ

    0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu

  4. Из отклика видно, что сеть называется isi-net.isi.edu.

4.4. Процедура поиска всех подсетей блока IP

Этот поиск выполняется на основе простого расширения метода определения имени по адресу IP. При обнаружении сети выполняется поиск в отклике записи A RR. Если такая запись присутствует, выполняется поиск подсети следующего уровня с использованием исходного адреса IP и маски из записи A RR. Процедура повторяется до тех пор, пока в откликах на запрос будет присутствовать запись A RR.

Ниже приведен пример повторения метода для адреса 128.9.2.17.

  1. Сначала инициируется запрос для 0.0.9.128.IN-ADDR.ARPA., который возвращает

    0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu.
                        A   255.255.255.0

  2. Поскольку в отклике присутствует запись A RR, процедура повторяется с использованием маски из RR (255.255.255.0), путем отправки запроса для 0.2.9.128.IN-ADDR.ARPA. В результате получается отклик

    0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu.
                        A   255.255.255.240

  3. В этом отклике также присутствует запись A RR, процедура повторяется с использованием маски 255.255.255.240 (FFFFFFF0). Запрос для 16.2.9.128.IN-ADDR.ARPA. возвращает

    16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu.

  4. Отсутствие записи A RR в отклике для 16.2.9.128.IN-ADDR.ARPA. Говорит о том, что дальнейшего разделения на подсети не используется.

5. Вопросы YP (Желтые страницы)

Термин «Желтые страницы» (Yellow Pages) используется почти столь же широко, как термин «домен», поэтому целесообразно определить толкование YP. Одной из значимых проблем является создание метода отображения одного типа идентификаторов на другой с поддержкой обратного отображения. Традиционные методы решения включают поиск и применение того или иного заранее созданного индекса.

Поиск неприемлем для больших объемов информации, применение индекса возможно лишь в тех случаях, когда заранее известны критерии поиска. Кроме того, создание индекса требует определенных издержек. Например, непрактично просматривать (поиск) все дерево доменов для нахождения конкретной адресной RR, поэтому создан индекс IN-ADDR.ARPA YP. Однако не представляется реальным создание в масштабах Internet индекса «хостов со средней загрузкой меньше 2», поскольку загрузка постоянно изменяется и индексирование не решит проблемы».

Такие подготовленные заранее индексы и рассматриваются, как YP и домен IN-ADDR.ARPA является первым примером YP в системе DNS. Желательны YP с централизованным управлением для таких значений, как номера портов TCP с возможностью создания в организациях локальных YP с номерами портов TCP местного значения и возможностью совместного использования разных YP для поиска номеров.

При просмотре документов Internet Numbers [RFC 997] и Assigned Numbers [RFC 1010] становится ясно, что имеет смысл организация нескольких отображений. Например,

   <assigned-network-name> <==> <IP-address>
   <autonomous-system-id>  <==> <number>
   <protocol-id>           <==> <number>
   <port-id>               <==> <number>
   <ethernet-type>         <==> <number>
   <public-data-net>       <==> <IP-address>

Вслед за IN-ADDR желтые страницы YP принимают форму доменного дерева, организованного для оптимизации поиска по ключам с использованием обычных правил DNS. К именам, служащим ключами, предъявляется ряд требований:

  1. общее использование; например, IN-ADDR.ARPA служит для отображения между именами хостов и адресами IP;

  2. тип «входных» данных для отображения; это важно по той причине, могут потребоваться множественные отображения «анонимов» на разные мнемонические имена и т. п.»

  3. тип «выходных» данных для отображения; поскольку предполагается симметрия отображения mnemonic <==> number, «выходные» данные также должны быть определены.

Этот порядок отражает естественную область контроля и, следовательно, порядок компонент доменного имени. Это имя будет формировать строку вида

<from-value>.<to-data-type>.<from-data-type>.<YP-origin>

Для того, чтобы это работало, нужно определить общепринятые строки для каждого из мета-авриантов, а также правила представления для преобразования <from-value> в доменное имя. Мы можем определить

<YP-origin> :=YP
<from-data-type>:=TCP-port | IN-ADDR | Number | Assigned-network-number | Name
<to-data-type> :=<from-data-type>

Отметим, что YP не является допустимым кодом государства [ISO 3166] (хотя может стать таковым в будущем) и наличие синтаксически корректных пар <to-data-type>.<from-data-type> вовсе не означает существования и даже возможности отображения.

Правила представления приведены ниже.

TCP-port 6 символов (буквы и цифры);

IN-ADDR обращенная строка из четырех октетов в десятичном представлении;

Number десятичное целое число;

Assigned-network-number обращенная строка из четырех октетов в десятичном представлении;

Name доменное имя.

6. Специфика отображений YP

6.1. TCP-PORT

   $origin Number.TCP-port.YP.

   23              PTR     TELNET.TCP-port.Number.YP.
   25              PTR     SMTP.TCP-port.Number.YP.

   $origin TCP-port.Number.YP.

   TELNET          PTR     23.Number.TCP-port.YP.
   SMTP            PTR     25.Number.TCP-port.YP.

Таким образом, отображение между номером 23 и именем TELNET представляется парой PTR RR, каждая из которых служит для отображения в одном из направлений.

6.2. Выделенные сети

Номера сетей распределяются NIC и включаются в Internet Numbers RFC. Для организации YP, агентству NIC следует организовать два домена – Name.Assigned-network-number.YP и Assigned-network-number.YP

Первый домен будет содержать записи вида

   $origin Name.Assigned-network-number.YP.

   0.0.0.4         PTR     SATNET.Assigned-network-number.Name.YP.
   0.0.0.10        PTR     ARPANET.Assigned-network-number.Name.YP.

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

   $origin Assigned-network-number.Name.YP.

   SATNET.         PTR     0.0.0.4.Name.Assigned-network-number.YP.
   ARPANET.        PTR     0.0.0.10.Name.Assigned-network-number.YP.

Эти YP не вступают в противоречие с поддержкой сетевых имен, описанной в первой половине данного RFC, поскольку там отображаются выделенные имена сетей на их номера и обратно, а здесь рассматриваются имена и номера, распределяемые организациями самостоятельно.

С практической точки зрения можно открыть оба эти домена, чтобы позволить пользователям Internet экспериментировать как с централизованной, так и с распределенной поддержкой. Можно также реализовать отображения только для выделенных значений и потребовать от организаций преобразовать выделенные им имена в соответствии с именованием для распределенной модели.

6.3. Повышение уровня операционной эффективности

Можно представить, что всем процедурам, использующим эти YP, можно рекомендовать применение YP.<local-domain> в качестве списков поиска. Таким образом, организация ISI.EDU, желающая локально задавать TCP-PORT, будет определять домены

<TCP-port.Number.YP.ISI.EDU> и <Number.TCP-port.YP.ISI.EDU>.

Можно добавить в поиск по YP другой уровень абстракии, определив узлы <to-data-type>.<from-data-type>.<YP-origin> для ссылок на дерево YP взамен непосредственной работы с деревом YP. Это позволит записи вида

IN-ADDR.Netname.YP. PTR IN-ADDR.ARPA.

для «сращивания» в YP данных из разных источников (пространств имен).

Другой возможностью могло бы быть сокращение раздела RDATA в записях RR, который используется для прямого и обратного отображения, за счет удаления источника. Этого можно добиться за счет разрешения в RDATA имен, которые не идентифицируют реальное доменное имя, или путем определения новой RR, которая использует простую текстовую строку взамен доменного имени.

Таким образом, можно заменить

   $origin Assigned-network-number.Name.YP.

   SATNET.         PTR     0.0.0.4.Name.Assigned-network-number.YP.
   ARPANET.        PTR     0.0.0.10.Name.Assigned-network-number.YP.

на

   $origin Assigned-network-number.Name.YP.

   SATNET.         PTR     0.0.0.4.
   ARPANET.        PTR     0.0.0.10.

или

   $origin Assigned-network-number.Name.YP.

   SATNET.         PTT     "0.0.0.4"
   ARPANET.        PTT     "0.0.0.10"

где PTT представляет собой новый тип, раздел RDATA в котором является текстовой строкой.

7. Благодарности

Drew Perkins, Mark Lottor и Rob Austein привнесли несколько идей в этот RFC. Множество комментариев, замечаний и предложений было получено от рабочей группы IETF Domain и участников почтовой конференции NAMEDROPPERS.

8. Литература

[HR] Braden, B., editor, “Requirements for Internet Hosts”, RFC в процессе подготовки4.

[ISO 3166] ISO, “Codes for the Representation of Names of Countries”, 1981.

[RFC 882] Mockapetris, P., “Domain names – Concepts and Facilities”, RFC 882, USC/Information Sciences Institute, November 1983.

Заменен RFC 1034.

[RFC 883] Mockapetris, P.,”Domain names – Implementation and Specification”, RFC 883, USC/Information Sciences Institute, November 1983.

Заменен RFC 1035.

[RFC 920] Postel, J. and J. Reynolds, “Domain Requirements”, RFC 920, October 1984.

Разъяснение схемы именования для доменов верхнего уровня.

[RFC 952] Harrenstien, K., M. Stahl, and E. Feinler, “DoD Internet Host Table Specification”, RFC 952, SRI, October 1985.

Задает формат файлов HOSTS.TXT — таблицы соответствия имен и адресов, замененной DNS.

[RFC 973] Mockapetris, P., “Domain System Changes and Observations”, RFC 973, USC/Information Sciences Institute, January 1986.

Описывает изменения, внесенные в RFC 882 и RFC 883, а также причины этих изменений.

[RFC 974] Partridge, C., “Mail routing and the domain system”, RFC 974, CSNET CIC BBN Labs, January 1986.

Описывает переход от адресации почты на базе файлов HOSTS.TXT к более мощной системе MX, используемой в DNS.

[RFC 997] Reynolds, J., and J. Postel, “Internet Numbers”, RFC 997, USC/Information Sciences Institute, March 1987

Списки номеров и имен сетей и т.п.

[RFC 1010] Reynolds, J., and J. Postel, “Assigned Numbers”, RFC 1010, USC/Information Sciences Institute, May 1987

Номера сокетов и мнемоника имен хостов, операционных систем и т. п.

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

Введение и обзор системы DNS.

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

Рекомендации по реализации DNS.

Адрес автора

Paul Mockapetris

USC/Information Sciences Institute

4676 Admiralty Way

Marina del Rey, CA 90292

Phone: (213) 822-1511

Email: PVM@ISI.EDU

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

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

nmalykh@protokols.ru

1Domain Name System.

2Relative Distinguished Name.

3Yellow pages — желтые страницы.

4Документ был опубликован в RFC 1122 и RFC 1123. Прим. перев.

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