Аннотация
Этот RFC представляет имена стилей доменов, их использование для поддержки интернет-почты ARPA и адресов хостов, а также протоколы и серверы, используемые для реализации возможностей доменных имен.
В этой заметке описывается концептуальная основа доменной системы и некоторых ее применений, но в ней не указаны многие области применения, поля и детали реализации. Полная спецификация форматов, тайм-аутов и т. д. Представлена в RFC 883, «Доменные имена — реализация и спецификация». Этот RFC предполагает, что читатель знаком с концепциями, обсуждаемыми в этой записке.
Скачать оригинальный документ на английском языке RFC 882 PDF
Оглавление
1. Введение
1.1. Необходимость доменных имен
1.2. Элементы решения
1.3. Модель базы данных
2. Доменное пространство имен
2.1. Спецификации и терминология пространства имен
2.2. Информация о наборе ресурсов
2.3. Запросы
2.4. Пример пространства
3. Серверы имен
3.1. Введение в серверы имён
3.2. Полномочия и административный контроль доменов
3.3. Логика сервера имен
3.4. Дополнительная информация
3.5. Псевдонимы и канонические имена
3.6. Подстановочные знаки
3.7. Сценарий A
3.8. B.ISI.ARPA Сервер имен для » «
3.9. F.ISI.ARPA Сервер имен для ARPA и ISI.ARPA
3.10. UDEL.ARPA и сервер имен UDEL.CSNET
3.11. Сводка требований к серверам имен
3.12. Обратные запросы
3.13. Завершение услуг
4. Резольверы
4.1. Введение в резольверы
4.2. Простые резольверы
4.3. Резольверы с управлением кешем
Приложение 1. Спецификация синтаксиса доменного имени
Ссылки и библиография
1. Введение
1.1. Необходимость доменных имен
Поскольку приложения расширяются до нескольких хостов, затем сетей и, наконец, интернет-сетей, эти приложения также должны охватывать несколько административных границ и связанных с ними методов работы (протоколы, форматы данных и т. Д.). Количество ресурсов (например, почтовых ящиков), количество мест для ресурсов и разнообразие такой среды создают огромные проблемы, когда мы хотим создать согласованные методы для ссылки на конкретные ресурсы, которые похожи, но разбросаны по всей среде.
Интернет ARPA иллюстрирует проблемы, связанные с размером; это большая система, которая, вероятно, станет намного больше. Необходимость сопоставления имен хостов (например, USC-ISIF) и интернет-адресов ARPA (например, 10.2.0.52) начинает подчеркивать существующие механизмы. В настоящее время хосты в Интернете ARPA зарегистрированы в Сетевом информационном центре (NIC) и перечислены в глобальной таблице (доступной как файл <NETINFO> HOSTS.TXT на хосте SRI-NIC) [1]. Размер этой таблицы, и особенно частота обновления таблицы, близки к пределу управляемости. Необходима распределенная база данных, которая выполняет ту же функцию и, следовательно, позволяет избежать проблем, вызванных централизованной базой данных.
Проблема для компьютерной почты является более серьезной. Хотя разработчики почтовых систем давно признали невозможность централизации имен почтовых ящиков, они также создали все более и более нерегулярный набор методов для определения местоположения почтового ящика. Некоторые из этих методов включают использование маршрутов и узлов пересылки как части адреса назначения почты и, следовательно, вынуждают пользователя почты знать несколько форматов адресов, возможности различных серверов пересылки и специальные приемы для передачи спецификаций адресов через посредников.
Эти проблемы имеют общие характеристики, которые указывают на природу любого решения:
Основная потребность в согласованном пространстве имен, которое будет использоваться для ссылки на ресурсы. Во избежание проблем, вызванных специальными кодировками, имена не должны содержать адреса, маршруты или аналогичную информацию как часть имени.
Огромный размер базы данных и частота обновлений позволяют предположить, что она должна поддерживаться распределенным образом с локальным кэшированием для повышения производительности. Подходы, которые пытаются собрать непротиворечивую копию всей базы данных, станут все более и более дорогостоящими и трудными, и поэтому их следует избегать. Тот же принцип применим к структуре пространства имен и, в частности, к механизмам создания и удаления имен; они также должны быть распространены.
Затраты на реализацию такого средства требуют, чтобы он был в целом полезным, а не ограничивался одним приложением. Мы должны иметь возможность использовать имена для извлечения адресов хостов, данных почтовых ящиков и другой пока еще неопределенной информации.
Поскольку мы хотим, чтобы пространство имен было полезным в разнородных сетях, маловероятно, что все пользователи доменных имен смогут договориться о наборе ресурсов или информации о ресурсах, которые имена будут использоваться для извлечения. Следовательно, имена относятся к набору ресурсов, а запросы содержат идентификаторы ресурсов. Единственным стандартным типом информации, которую мы ожидаем увидеть по всему пространству имен, является структурирование информации для самого пространства имен и ресурсов, которые описываются с использованием доменных имен и без нестандартных данных.
Мы также хотим, чтобы транзакции сервера имен были независимыми от системы связи, которая их переносит. Некоторые системы могут захотеть использовать дейтаграммы для простых запросов и ответов и устанавливать виртуальные каналы только для транзакций, которые нуждаются в надежности (например, обновления базы данных, длинные транзакции); другие системы будут использовать исключительно виртуальные каналы.
1.2. Элементы решения
Предлагаемое решение состоит из трех основных компонентов:
DOMAIN NAME SPACE, который является спецификацией для пространства имен с древовидной структурой. Концептуально, каждый узел и лист дерева пространства имен доменов называют набор информации, а операции запроса — это попытки извлечь определенные типы информации из определенного набора. Запрос именует интересующее доменное имя и описывает тип требуемой информации о ресурсе. Например, Интернет ARPA использует некоторые из своих доменных имен для идентификации хостов; запросы на адресные ресурсы возвращают адреса интернет-хостов ARPA. Однако, чтобы сохранить общность механизма домена, доменные имена не обязательно должны иметь взаимно-однозначное соответствие с именами хостов, адресами хостов или любым другим типом информации.
NAME SERVERS — это серверные программы, которые хранят информацию о структуре дерева доменов и устанавливают информацию. Сервер имен может кэшировать структуру или устанавливать информацию о любой части дерева доменов, но в целом конкретный сервер имен имеет полную информацию о подмножестве пространства домена и указатели на другие серверы имен, которые можно использовать для получения информации от любая часть дерева доменов. Серверы имен знают части дерева доменов, для которых они имеют полную информацию; эти части называются зонами; Сервер имен — это ВЛАСТЬ для этих частей пространства имен.
RESOLVERS — это программы, которые извлекают информацию с серверов имен в ответ на запросы пользователей. Резолверы должны иметь доступ к как минимум одному серверу имен и использовать информацию этого сервера имен для прямого ответа на запрос или выполнять запрос с использованием ссылок на другие серверы имен. Решающее устройство обычно представляет собой системную подпрограмму, которая непосредственно доступна для пользовательских программ; следовательно, не требуется протокол между распознавателем и пользовательской программой.
Эти три компонента примерно соответствуют трем уровням или представлениям доменной системы:
- С точки зрения пользователя, доступ к доменной системе осуществляется через простые процедуры или вызовы ОС для распознавателей. Доменное пространство состоит из одного дерева, и пользователь может запрашивать информацию из любого раздела дерева.
- С точки зрения резольвера, доменная система состоит из неизвестного количества серверов имен. Каждый сервер имен имеет одну или несколько частей данных всего дерева доменов, но распознаватель рассматривает каждую из этих баз данных как по существу статическую.
- С точки зрения сервера имен, доменная система состоит из отдельных наборов локальной информации, называемой зонами. Сервер имен имеет локальные копии некоторых зон. Сервер имен должен периодически обновлять свои зоны из главных копий в локальных файлах или на сторонних серверах имен. Сервер имен должен одновременно обрабатывать запросы, поступающие от распознавателей с использованием локальных зон.
В интересах производительности эти слои немного размываются. Например, распознаватели на том же компьютере, что и сервер имен, могут совместно использовать базу данных, а также могут вводить чужую информацию для использования в последующих запросах. Эта кэшированная информация обрабатывается иначе, чем достоверные данные в зонах.
1.3. Модель базы данных
Организация доменной системы основана на некоторых предположениях о потребностях и моделях использования ее сообщества пользователей и призвана избежать многих сложных проблем, обнаруживаемых в системах баз данных общего назначения.
Предположения:
- Размер всей базы данных первоначально будет пропорционален количеству хостов, использующих систему, но со временем будет увеличиваться пропорционально количеству пользователей на этих хостах по мере добавления почтовых ящиков и другой информации в систему домена.
- Большая часть данных в системе будет меняться очень медленно (например, привязки почтовых ящиков, адреса хостов), но система должна иметь возможность обрабатывать подмножества, которые изменяются быстрее (порядка минут).
- Административные границы, используемые для распределения ответственности за базу данных, обычно соответствуют организациям, имеющим один или несколько хостов. Каждая организация, которая несет ответственность за определенный набор доменов, будет предоставлять избыточные серверы имен либо на собственных хостах организации, либо на других хостах, которые организация организует для использования.
- Клиенты доменной системы должны иметь возможность идентифицировать доверенные серверы имен, которые они предпочитают использовать, прежде чем принимать ссылки на серверы имен за пределами этого «доверенного» набора.
- Доступ к информации более важен, чем мгновенные обновления или гарантии согласованности. Следовательно, процесс обновления позволяет обновлениям распространяться через пользователей системы домена, а не гарантирует, что все копии обновляются одновременно. Когда обновления недоступны из-за сбоя в сети или хосте, обычно нужно верить старой информации, продолжая прилагать усилия для ее обновления. Общая модель состоит в том, что копии распространяются с таймаутами для обновления. Распределитель устанавливает значение тайм-аута, а получатель рассылки отвечает за выполнение обновления. В особых ситуациях могут быть указаны очень короткие интервалы, или владелец может запретить копирование.
- Некоторые пользователи захотят получить доступ к базе данных через дейтаграммы; другие предпочтут виртуальные каналы. Система доменов разработана таким образом, что простые запросы и ответы могут использовать любой стиль, хотя операции обновления требуют надежности виртуальных каналов. Один и тот же общий формат сообщения используется для всех сообщений. Доменная система не предполагает каких-либо особых свойств системы связи и, следовательно, может использоваться с любой дейтаграммой или протоколом виртуальной цепи.
- В любой системе, которая имеет распределенную базу данных, конкретному серверу имен может быть представлен запрос, на который может ответить только какой-либо другой сервер. Два основных подхода к решению этой проблемы: «рекурсивный», при котором первый сервер выполняет запрос клиента на другом сервере, и «итеративный», при котором сервер направляет клиента на другой сервер и позволяет клиенту выполнять запрос. Оба подхода имеют свои преимущества и недостатки, но для доступа к датаграмме предпочтительным является итеративный подход. Система доменов требует реализации итеративного подхода, но в качестве опции позволяет рекурсивный подход. Необязательный рекурсивный стиль обсуждается в [14] и не рассматривается в дальнейшем обсуждении.
Доменная система предполагает, что все данные происходят из основных файлов, разбросанных по хостам, которые используют доменную систему. Эти главные файлы обновляются локальными системными администраторами. Основные файлы — это текстовые файлы, которые считываются локальным сервером имен и, следовательно, становятся доступными пользователям системы домена. Стандартный формат для этих файлов приведен в [14].
Стандартный формат позволяет обмениваться этими файлами между хостами (через FTP, почту или какой-либо другой механизм); эта возможность полезна, когда организация хочет домен, но не хочет поддерживать сервер имен. Организация может поддерживать основные файлы локально с помощью текстового редактора, передавать их на внешний хост, на котором работает сервер имен, а затем договариваться с системным администратором сервера имен о загрузке файлов.
Серверы имен и распознаватели каждого хоста настраиваются локальным системным администратором. Для сервера имен эти данные конфигурации включают в себя идентификационные данные локальных мастер-файлов и инструкции, по которым следует загружать нелокальные мастер-файлы с внешних серверов. Сервер имен использует главные файлы или копии для загрузки своих зон. Для распознавателей данные конфигурации идентифицируют серверы имен, которые должны быть основными источниками информации.
Система доменов определяет процедуры доступа к данным и передачи ссылок на другие серверы имен. Доменная система также определяет процедуры для кэширования извлеченных данных и для периодического обновления данных, определенных системным администратором.
Системные администраторы предоставляют:
- Определение границ зоны
- Основные файлы данных
- Обновления в мастер-файлы
- Заявления о желаемых политиках обновления
Доменная система обеспечивает:
- Стандартные форматы для данных ресурса
- Стандартные методы для запросов к базе данных
- Стандартные методы для серверов имен для обновления локальных данных с внешних серверов имен
2. Доменное пространство имен
2.1. Спецификации и терминология пространства имен
Пространство доменных имен представляет собой древовидную структуру. Каждый узел и лист дерева соответствуют набору ресурсов (который может быть пустым). С каждым узлом и листом связана метка. Метки НЕ гарантированно являются уникальными, за исключением корневого узла, который имеет нулевую метку. Доменное имя узла или листа — это путь от корня дерева до узла или листа. По соглашению, метки, составляющие доменное имя, читаются слева направо, от самого конкретного (самый низкий) до наименее определенного (самый высокий).
Внутри программы, которые манипулируют доменными именами, представляют их как последовательности меток, где каждая метка представляет собой октет длины, за которым следует строка октета. Поскольку все доменные имена заканчиваются в корне, который имеет пустую строку для метки, эти внутренние представления могут использовать нулевой байт длины для завершения доменного имени. Когда доменные имена печатаются, метки в пути разделяются точками («.»). Корневая метка и связанная с ней точка не указываются в печатных доменных именах, но корень может быть назван пустым доменным именем («» в этом примечании).
Для упрощения реализации общее количество октетов, представляющих октеты меток и длины меток, ограничено 255. Таким образом, напечатанное доменное имя может содержать до 254 символов.
Определена специальная метка, которая соответствует любой другой метке. Эта метка является звездочкой или «*». Звездочка соответствует одному ярлыку. Таким образом, * .ARPA соответствует FOO.ARPA, но не соответствует FOO.BAR.ARPA. Звездочка в основном используется для создания записей ресурсов по умолчанию на границе между семействами протоколов и требует осторожности при ее использовании.
Домен идентифицируется по имени домена и состоит из той части пространства имен домена, которая находится на или ниже доменного имени, которое определяет домен. Домен — это поддомен другого домена, если он содержится в этом домене. Это отношение можно проверить, посмотрев, содержит ли имя субдомена имя содержащего домена в качестве правой части его имени. Например, A.B.C.D является поддоменом B.C.D, C.D, D и «».
Эта древовидная структура предназначена для параллельной административной организации и делегирования полномочий. Потенциально каждый узел или лист дерева может создавать новые субдомены до бесконечности. На практике это делегирование может быть ограничено администратором серверов имен, которые управляют пространством домена и данными ресурса.
На следующем рисунке показан пример пространства доменных имен.
В этом примере корневой домен имеет три непосредственных субдомена:
ЦВЕТЫ, АРОМАТЫ И ПРАВДА. Домен FLAVORS имеет один непосредственный поддомен с именем NATURAL.FLAVORS. Все листья тоже домены. Это доменное дерево имеет имена «» (корень), COLORS, RED.COLORS, BLUE.COLORS, GREEN.COLORS, FLAVOUR, NATURAL.FLAVORS, CHOCOLATE.NATURAL.FLAVORS, VANILLA.NATURAL.FLAVORS, STRAWBERRY.NATURAL.FLORS И ПРАВДА. Если мы хотим добавить новый домен ARTIFICIAL в поле FLAVOURS, обычно FLAVOURS будет административным органом, который будет принимать решение; если мы хотим создать имена CHIP и MOCHA в CHOCOLATE, CHOCOLATE.NATURAL.FLAVORS обычно является подходящей административной единицей.
2.2. Информация о наборе ресурсов
Доменное имя идентифицирует набор информации о ресурсах. Набор информации о ресурсах, связанной с конкретным именем, состоит из отдельных записей ресурсов (RR).
Каждая запись ресурса имеет следующие основные компоненты:
- Доменное имя, которое идентифицирует набор ресурсов, который содержит эту запись, и, следовательно, «владелец» информации. Например, RR, который указывает адрес хоста, имеет имя домена, которое указывает хост, имеющий этот адрес. Таким образом, F.ISI.ARPA может быть владельцем RR, в котором указано поле адреса 10.2.0.52.
- Поскольку серверы имен обычно хранят информацию о своих ресурсах в древовидных структурах, параллельных организации пространства домена, эта информация обычно может храниться неявно в базе данных; однако он всегда включается в каждую запись ресурса, содержащуюся в сообщении.
- Другая информация, используемая для управления RR, такая как поля длины, тайм-ауты и т. Д. Эта информация опущена в большей части этой заметки, но обсуждается в [14].
Поле типа ресурса, которое указывает тип ресурса в этой записи ресурса. Типы относятся к абстрактным ресурсам, таким как адреса узлов или агенты доставки почты. Поле типа имеет длину в два октета и использует стандартную для всей системы доменных имен кодировку. - Поле класса идентифицирует формат данных ресурса, такой как Интернет-формат ARPA (IN) или формат Computer Science Network (CSNET), для определенных типов RR (таких как адресные данные). Обратите внимание, что хотя класс может разделять разные семейства протоколов, сети и т. Д., Он делает это не во всех случаях. Например, класс IN использует исключительно 32-битные IP-адреса, а класс CSNET использует 32-битные IP-адреса, адреса X.25 и телефонные номера. Таким образом, поле класса должно использоваться в качестве руководства для интерпретации данных ресурса. Поле класса имеет длину в два октета и использует стандартную кодировку для всей системы доменных имен.
- Данные ресурса, которые описывают ресурс. Формат этих данных может быть определен с учетом полей типа и класса, но всегда начинается с поля длиной в два октета, которое позволяет серверу имен или распознавателю определять границы данных ресурса в любой транзакции, даже если он не может «понять» сами данные ресурса. Таким образом, серверы имен и распознаватели могут хранить и передавать записи, которые они не могут интерпретировать. Формат внутренних данных ограничен только максимальной длиной 65535 октетов; например, запись адреса хоста может указывать фиксированное 32-битное число для одного класса и список адресов переменной длины в другом классе.
В то время как поле класса фактически разделяет данные ресурсов в системе имен доменов на отдельные параллельные секции в соответствии с классом, службы могут выходить за границы класса, если они используют совместимые форматы данных ресурсов. Например, система доменных имен использует совместимые форматы для информации о структуре, а почтовые данные отделяют идентификацию почтового агента от деталей того, как связаться с агентом (например, адреса хоста).
Эта памятка использует следующие типы в своих примерах:
A — адрес хоста, связанный с доменным именем
MF — идентифицирует почтового экспедитора для домена
MD — определяет почтовое назначение для домена
NS — авторитетный сервер имен для домена
SOA — определяет начало зоны полномочий
CNAME — определяет каноническое имя псевдонима
Эта памятка использует следующие классы в своих примерах:
IN — интернет-система ARPA
CS — система CSNET
Первый тип записи ресурса содержит привязку имени хоста к адресу хоста. Его поля:
Содержание конкретной информации о классе варьируется в зависимости от значения в поле CLASS; для ARPA-интернета это 32-битный ARPA-адрес Интернета хоста, для CSNET это может быть номер телефона хоста. Например, F.ISI.ARPA может иметь две записи A вида:
Обратите внимание, что форматы данных для типа A зависят от класса, а форматы интернет-адресов и номеров телефонов, показанные выше, приведены только в качестве иллюстрации. Фактические форматы данных указаны в [14]. Например, данные класса CS для записей типа A могут фактически представлять собой список интернет-адресов, телефонных номеров и адресов TELENET.
Записи пересылки почты (MF) и доставки почты (MD) имеют следующий формат:
Поле <domain name> является доменным именем хоста, который будет обрабатывать почту; обратите внимание, что это доменное имя может полностью отличаться от имени домена, в котором указана запись ресурса.
Например, F.ISI.ARPA может иметь две записи вида:
Эти записи означают, что почта для F.ISI.ARPA может быть либо доставлена на хост F.ISI.ARPA, либо переслана в B.ISI.ARPA, которая примет на себя ответственность за ее возможную доставку. В принципе, для сопоставления доменного имени хоста с соответствующим адресом требуется дополнительный поиск имени, на практике эта информация обычно возвращается в ответе на почтовый запрос.
Типы записей ресурсов SOA и NS используются для определения пределов полномочий. Доменное имя, указанное в поле владельца записи SOA, является началом зоны; имя домена, заданное полем владельца записи NS, идентифицирует точку в пространстве имен, где полномочия были делегированы, и, следовательно, отмечает границу зоны. За исключением случая, когда сервер имен делегирует полномочия самому себе, SOA определяет верхний предел полномочий, а записи NS определяют имя вне зоны. Эти записи ресурсов имеют стандартный формат для всего пространства имен:
Запись SOA отмечает начало зоны, когда она присутствует в базе данных; запись NS как отмечает конец зоны, начатой SOA (если присутствует более высокий SOA), так и указывает на сервер имен, который имеет копию зоны, указанной <владельцем. поле записи NS.
<Имя домена и т. Д.> В записи SOA указывает исходный источник информации в зоне и другую информацию, используемую серверами имен для организации своей деятельности. Записи SOA никогда не кэшируются (в противном случае они создали бы ложные зоны); они могут быть созданы только в специальных операциях обслуживания сервера имен.
Запись NS говорит, что сервер имен, который является полномочным для записей данного КЛАССА, может быть найден в <имя домена>.
2.3. Запросы
Запросы к серверу имен должны включать имя домена, которое идентифицирует целевой набор ресурсов (QNAME), а также тип и класс требуемых записей ресурсов. Поля типа и класса в запросе могут включать в себя любые из соответствующих полей типа и класса, определенных для записей ресурсов; кроме того, поля типа запроса (QTYPE) и класса запроса (QCLASS) могут содержать специальные значения, которые соответствуют более чем одному из соответствующих полей в RR.
Например, поле QTYPE может содержать:
MAILA — соответствует всем RR почтового агента (например, MD и MF).
* — соответствует любому типу RR.
Поле QCLASS может содержать:
* — соответствует любому классу RR.
Используя имя домена запроса, QTYPE и QCLASS, сервер имен ищет совпадающие RR. В дополнение к соответствующим записям сервер имен может возвращать RR, которые указывают на сервер имен, который имеет желаемую информацию, или RR, которые, как ожидается, будут полезны при интерпретации соответствующих RR. Например, сервер имен, который не имеет запрошенной информации, может знать сервер имен, который имеет; сервер имен, который возвращает доменное имя в соответствующем RR, может также вернуть RR, который связывает это доменное имя с адресом.
Обратите внимание, что конструкция QCLASS = * требует специальной интерпретации относительно полномочий. Поскольку сервер имен может не знать все классы, доступные в доменной системе, он никогда не узнает, является ли он авторитетным для всех классов. Следовательно, ответы на запросы QCLASS = * никогда не могут быть официальными.
2.4. Пример пространства
В целях изложения следующее пространство имен используется для оставшейся части этой заметки:
3. Серверы имен
3.1. Введение в серверы имён
Серверы имен хранят распределенную базу данных, состоящую из структуры пространства имен доменов, наборов ресурсов, связанных с именами доменов, и другой информации, используемой для координации действий между серверами имен.
В общем, сервер имен будет полномочием для всего или части конкретного домена. Регион, охватываемый этим органом, называется зоной. Серверы имен могут не отвечать за достоверные данные и, следовательно, не иметь зон, или могут иметь несколько зон. Когда сервер имен имеет несколько зон, зоны могут не иметь общих границ или зоны могут быть смежными.
Хотя администраторы не должны создавать перекрывающиеся зоны, а серверы имен должны защищать от перекрывающихся зон, перекрытие рассматривается как нефатальный недостаток в базе данных. Следовательно, меры, принятые для защиты от него, опущены до конца этого меморандума. Подробное обсуждение можно найти в [14].
При представлении запроса на доменное имя, на которое у него есть полномочия, сервер имен возвращает информацию о желаемом ресурсе или указание на то, что запрос ссылается на несуществующее доменное имя или ресурс. Если серверу имен предоставляется запрос на доменное имя, которое не входит в его полномочия, он может иметь требуемую информацию, но он также возвратит ответ, который указывает на авторитетный сервер имен. Если сервер имен не является полномочным для запроса, он никогда не сможет вернуть отрицательный ответ.
Не требуется, чтобы сервер имен для домена находился на хосте, имя которого находится в том же домене, хотя обычно это так. Также нет ограничений на количество серверов имен, которые могут иметь полномочия над конкретным доменом; большинство доменов будут иметь избыточные авторитетные серверы имен. Предполагается, что разные достоверные копии идентичны, хотя возможны несоответствия при внесении обновлений.
Функции сервера имен разработаны с учетом очень простых реализаций серверов имен. Простейший сервер имен имеет статический набор информации и использует дейтаграммы для получения запросов и возврата ответов.
Более сложные реализации серверов имен могут повысить производительность их клиентов за счет кэширования информации из других доменов. Хотя эту информацию можно получить несколькими способами, обычным способом является сохранение информации, полученной распознавателем, когда распознаватель обращается к другим серверам имен. На сложном хосте распознаватель и сервер имен будут координировать свои действия и использовать общую базу данных. Это сотрудничество требует включения поля времени жизни (TTL) во все записи кэшированных ресурсов. Кеширование обсуждается в разделе разрешения этой заметки; Этот раздел посвящен действиям серверов имен, которые не кэшируются.
Чтобы освободить простые серверы имен от необходимости управлять этими таймаутами, простые серверы имен должны содержать только записи ресурсов, которые, как ожидается, будут оставаться постоянными в течение очень длительных периодов, или записи ресурсов, для которых сервер имен является полномочным. В последующем обсуждении предполагается, что поле TTL хранится в записи ресурса, но опущено в описании баз данных и ответов в целях ясности.
3.2. Полномочия и административный контроль доменов
Хотя мы хотим иметь возможность делегировать привилегии управления пространством имен на каждом узле, мы не хотим, чтобы такое делегирование требовалось.
Поэтому мы вводим понятие власти. Полномочия принадлежат серверам имен. Сервер имен имеет полномочия на весь свой домен, пока не делегирует полномочия для поддоменов другому серверу имен.
Любой административный объект, который желает установить свой собственный домен, должен предоставить сервер имен, и этот сервер должен быть принят родительским сервером имен (то есть сервером имен, который имеет полномочия над местом в пространстве имен домена, которое будет содержать новый домен). В то время как принципы полномочий допускают принятие по усмотрению родительских серверов имен, корень использует следующие критерии и рекомендуется всем серверам имен, поскольку они несут ответственность за действия своих детей:
- Необходимо зарегистрироваться у родительского администратора доменов.
- Должно быть установлено ответственное лицо.
- В должны предоставить избыточные серверы имен.
Имя домена должно быть зарегистрировано администратором, чтобы избежать конфликтов имен и сделать информацию о домене доступной для других доменов. У центрального администратора могут быть дополнительные требования, и домен не будет зарегистрирован, пока центральный администратор не согласится с тем, что все требования соблюдены.
Должно быть ответственное лицо, связанное с каждым доменом, которое будет контактным лицом для вопросов о домене, для проверки и обновления информации, связанной с доменом, и для решения любых проблем (например, нарушений протокола) с хостами в домене.
Домен должен предоставлять избыточные (т. Е. Два или более) серверы имен для предоставления службы разрешения имен. Эти серверы имен должны быть доступны как за пределами домена (так и изнутри) и должны разрешать имена как минимум для всех хостов в домене.
Как только центральный администратор будет удовлетворен, он сообщит о существовании соответствующим администраторам других доменов, чтобы они могли включить записи NS для нового сервера имен в свои базы данных.
3.3. Логика сервера имен
Шаги обработки, которые сервер имен выполняет при ответе на запрос, концептуально просты, хотя реализации могут иметь довольно сложные внутренние базы данных.
В целях объяснения мы предполагаем, что запрос состоит из типа QTYPE, класса QCLASS и доменного имени QNAME; мы предполагаем, что сервер имен хранит свои RR в наборах, где каждый набор имеет все RR для определенного домена. Обратите внимание, что эта структура базы данных и следующие алгоритмы предназначены для иллюстрации одной возможной реализации, а не спецификации того, как должны быть реализованы все серверы.
Используются следующие обозначения:
ord (DOMAIN-NAME) возвращает количество меток в DOMAIN-NAME.
findset (DOMAIN-NAME) возвращает указатель на набор сохраненных RR для DOMAIN-NAME или NULL, если такой информации нет.
set (POINTER) относится к набору, расположенному ранее findset, где POINTER — значение, возвращаемое findset.
related (QTYPE, TYPE) возвращает true, если RR указанного TYPE относится к указанному QTYPE. Например, релевантный (MAILA, MF) является истинным, а релевантный (MAILA, NS) ложным.
right (NAME, NUMBER) возвращает доменное имя, являющееся крайней правой меткой NUMBER в строке NAME.
set (POINTER) относится к набору, расположенному ранее findset, где POINTER — значение, возвращаемое findset.
copy (RR) копирует запись ресурса, указанную RR, в ответ.
Код сервера имен может быть представлен в виде следующей последовательности шагов:
{выяснить, делает ли база данных этот сервер доверенным для имени домена, указанного в QNAME}
for i:=0 to ord(QNAME) { sequence through all nodes in QNAME }
do begin
ptr:=findset(right(QNAME,i));
if ptr<>NULL
then { there is domain data for this domain name }
begin
for all RRs in set(ptr)
do if type(RR)=NS and class(RR)=QCLASS
then begin
auth=false;
NSptr:=ptr
end;
for all RRs in set(ptr)
do if type(RR)=SOA and class(RR)=QCLASS
then auth:=true
end
end;
end;
{скопировать результаты поиска авторитетных}
if auth
then { if authority check for domain found }
if ptr=null
then return(Name error)
else
else { if not authority, copy NS RRs }
for all RRs in set(nsptr)
do if (type(RR)=NS and class(RR)=QCLASS)
or
(QCLASS=*)
then copy(RR);
{Скопируйте все RR, которые отвечают на вопрос}
for all RRs in set(ptr)
do if class(RR)=QCLASS and relevant(QTYPE,type(RR))
then copy(RR);
Первый раздел кода (ограниченный циклом for для всех подузлов QNAME) обнаруживает, является ли сервер имен полномочным для домена, указанного в QNAME. Он проходит через все содержащие домены QNAME, начиная с корня. Если он сталкивается с SOA, он знает, что сервер имен является авторитетным, если только он не найдет более низкий NS RR, который делегирует полномочия. Если сервер имен является полномочным, он устанавливает auth = true; если сервер имен не является полномочным, он устанавливает NSptr для указания на набор, который содержит NS RR, ближайший к домену, указанному в QNAME.
Второй раздел кода отражает результат поиска полномочий в ответе. Если сервер имен является полномочным, код проверяет, существует ли домен, указанный в QNAME; если нет, возвращается ошибка имени. Если сервер имен не является полномочным, код копирует RR для более близкого сервера имен в ответ.
Последний раздел кода копирует все соответствующие RR в ответ.
Обратите внимание, что этот код не предназначен для фактической реализации и является неполным в нескольких аспектах. Например, он не касается предоставления дополнительной информации, подстановочных знаков, QCLASS = * или перекрывающихся зон. Первые два из этих вопросов рассматриваются в следующих обсуждениях, остальные вопросы обсуждаются в [14].
3.4. Дополнительная информация
Когда распознаватель возвращает информацию в пользовательскую программу, возвращаемая информация часто приводит ко второму запросу. Например, если почтовый клиент запрашивает распознаватель для соответствующего почтового агента для конкретного доменного имени, сервер имен, запрошенный распознавателем, возвращает доменное имя, идентифицирующее агента. В общем, мы ожидаем, что почтовый сервер затем запросит имя домена для привязки адреса для почтового агента, и в результате получится новый запрос к серверу имен.
Чтобы избежать такого дублирования усилий, серверы имен возвращают дополнительную информацию с ответом, который удовлетворяет ожидаемому запросу. Эта информация хранится в отдельном разделе ответа. Серверы имен обязаны заполнять соответствующую дополнительную информацию, если такая информация доступна, но запрашивающая сторона не должна зависеть от наличия информации, поскольку сервер имен может ее не иметь. Если распознаватель кэширует дополнительную информацию, он может ответить на второй запрос без дополнительной сетевой транзакции.
Соответствующая информация определена в [14], но обычно состоит из привязок хоста к адресу для доменных имен в возвращенных RR.
3.5. Псевдонимы и канонические имена
В существующих системах узлы и другие ресурсы часто имеют несколько имен, которые идентифицируют один и тот же ресурс. Например, при текущей поддержке ARPA-именования в Интернете USC-ISIF и ISIF идентифицируют один и тот же хост. Аналогичным образом, в случае почтовых ящиков многие организации предоставляют много имен, которые фактически отправляются в один и тот же почтовый ящик; например, Mockapetris @ ISIF, Mockapetris @ ISIB и т. д., все идут в один и тот же почтовый ящик (хотя механизм, стоящий за этим, несколько сложен).
В большинстве этих систем существует понятие, что одним из эквивалентных наборов имен является каноническое имя, а все остальные являются псевдонимами.
Доменная система предоставляет аналогичную функцию, используя каноническое имя (CNAME) RR. Когда серверу имен не удается найти нужный RR в наборе, связанном с каким-либо доменным именем, он проверяет, содержит ли набор ресурсов запись CNAME с соответствующим классом. Если это так, сервер имен включает в ответ запись CNAME и продолжает запрос в доменном имени, указанном в поле данных записи CNAME.
Предположим, что сервер имен обрабатывал запрос с QNAME = ISIF.ARPA, QTYPE = A и QCLASS = IN и имел следующие записи ресурсов:
ISIF.ARPA CNAME IN F.ISI.ARPA
F.ISI.ARPA A IN 10.2.0.52
Оба эти RR будут возвращены в ответе.
В приведенном выше примере, поскольку ISIF.ARPA не имеет RR, отличных от CNAME RR, ресурсы, ассоциированные с ISIF.ARPA, будут точно такими же, что связаны с F.ISI.ARPA для IN CLASS. Поскольку CNAME эффективен только при сбое поиска, CNAME также можно использовать для создания значений по умолчанию. Например, предположим, что сервер имен имеет следующий набор RR:
F.ISI.ARPA A IN 10.2.0.52
F.ISI.ARPA MD IN F.ISI.ARPA
XXXX.ARPA CNAME IN F.ISI.ARPA
XXXX.ARPA MF IN A.ISI.ARPA
Используя эту базу данных, запросы типа A для XXXX.ARPA будут возвращать XXXX.ARPA CNAME RR и F.ISI.ARPA A RR, но запросы MAILA или MF к XXXX.ARPA будут возвращать XXXX.ARPA MF RR без какой-либо информации от F.ISI.ARPA. Эту структуру можно использовать для отправки почты, адресованной XXXX.ARPA, в A.ISI.ARPA и для направления TELNET для XXXX.ARPA в F.ISI.ARPA.
3.6. Подстановочные знаки
В некоторых случаях администратор может захотеть связать информацию о ресурсах по умолчанию для всего или части домена. Например, администратор домена CSNET может пожелать установить пересылку почты класса IN для всех хостов в домене CSNET без возможности IN. В таком случае доменная система предоставляет специальную метку «*», которая соответствует любой другой метке. Обратите внимание, что «*» соответствует только одной метке, а не нулю или нескольким меткам. Также обратите внимание, что «*» отличается от «*» значений для QCLASS и QTYPE.
Семантика «*» зависит от того, присутствует ли оно в имени домена запроса (QNAME) или в RR в базе данных.
- Когда в QNAME используется «*», он может соответствовать только «*» в записи ресурса.
- Когда «*» появляется в RR в базе данных, оно никогда не может переопределить существующее точное совпадение. Например, если сервер имен получил запрос для домена UDEL.CSNET и имел соответствующие RR для UDEL.CSNET и * .CSNET, то будут использоваться RD UDEL.CSNET, а RR * .CSNET будут игнорироваться. Если запрос к той же базе данных указывает FOO.CSNET, будет использоваться * .CSNET RR, но соответствующие метки из QNAME заменят «*». Таким образом, запрос FOO.CSNET будет соответствовать * .CSNET RR и будет возвращать RR для FOO.CSNET, а не * .CSNET.
- RR, содержащие метки «*», копируются именно тогда, когда зоны передаются через операции обслуживания сервера имен.
Эта семантика легко реализуется благодаря тому, что сервер имен сначала выполняет поиск точного соответствия для запроса, а затем заменяет крайнюю левую метку на «*» и повторяет попытку, пока все метки не станут «*» или поиск не будет успешным.
TYPE=* в RR запрещен. Если бы это было разрешено, у запрашивающего не было бы никакого способа интерпретировать данные в RR, потому что эти данные зависят от типа.
CLASS=* также запрещен. Подобные эффекты могут быть достигнуты с использованием QCLASS = *, а разрешение как QCLASS = *, так и CLASS = * приводит к сложностям без очевидной выгоды.
3.7. Сценарий A
Предположим, что в нашем примере доменного пространства нам нужен отдельный административный контроль для корневых доменов, доменов DDN, ARPA, CSNET, MIT и ISI. Мы могли бы выделить серверы имен следующим образом:
В этом примере авторитетный сервер имен показан в скобках в той точке дерева доменов, где предполагается управление.
Таким образом, корневые серверы имен находятся на B.ISI.ARPA и UDEL.CSNET, сервер имен DDN находится на JCS.DDN, сервер домена CSNET находится на UDEL.ARPA и т. д.
В реальной системе все домены должны иметь избыточные серверы имен, но в этом примере только домен ARPA имеет избыточные серверы A.ISI.ARPA и F.ISI.ARPA. (Серверы имен B.ISI.ARPA и UDEL.CSNET не являются избыточными, поскольку они обрабатывают разные классы.) Сервер имен F.ISI.ARPA обладает полномочиями над доменом ARPA, но делегирует полномочия над доменом MIT.ARPA сервер имен на AI.MIT.ARPA. Сервер имен A.ISI.ARPA также имеет полномочия над доменом ARPA, но делегирует домены ISI.ARPA и MIT.ARPA другим серверам имен.
3.8. B.ISI.ARPA Сервер имен для » «
B.ISI.ARPA имеет корневой сервер имен для класса IN. Его база данных может содержать:
Domain Resource Record
» » SOA IN A.ISI.ARPA
DDN NS IN JCS.DDN
ARPA NS IN F.ISI.ARPA
CSNET NS IN UDEL.ARPA
» » NS IN B.ISI.ARPA
» » NS CS UDEL.CSNET
JCS.DDN A IN 9.0.0.1
F.ISI.ARPA A IN 10.2.0.52
UDEL.CSNET A CS 302-555-0000
UDEL.ARPA A IN 10.0.0.96
Запись SOA для корня необходима для того, чтобы сервер имен знал, что он является полномочным для корневого домена для класса IN. Содержимое записи ресурса SOA указывает на A.ISI.ARPA и обозначает, что основные данные для зоны полномочий исходят от этого хоста. Первые три записи NS означают делегирование полномочий. Корневая запись NS для сервера имен B.ISI.ARPA необходима для того, чтобы этот сервер имен знал о себе и мог правильно ответить на запрос информации NS о корне (для которого он является полномочным). Корневая запись для класса CS обозначает, что UDEL.CSNET является официальным сервером имен для корневого класса CS. UDEL.CSNET и UDEL.ARPA могут ссылаться или не ссылаться на один и тот же сервер имен; Из этой информации невозможно сказать.
Если этому серверу имен был отправлен запрос с указанием QTYPE = MAILA, QCLASS = IN, QNAME = F.ISI.ARPA, он начал бы обработку (используя предыдущий алгоритм), определив, что он не является полномочием для F.ISI.ARPA. В тесте будет отмечено, что у него есть полномочия на «», но также будет отмечено, что полномочия были делегированы в ARPA и никогда не восстанавливались через другую SOA. Таким образом, ответ будет возвращать запись NS для домена ARPA.
Любые запросы, представленные этому серверу с QCLASS = CS, приведут к тому, что в ответе будет возвращена запись NS UDEL.CSNET.
3.9. F.ISI.ARPA Сервер имен для ARPA и ISI.ARPA
В том же доменном пространстве база данных F.ISI.ARPA для доменов ARPA и ISI.ARPA может быть:
Для класса IN SOA RR для ARPA обозначает, что этот сервер имен является полномочным для домена ARPA и что главный файл для этого полномочия хранится в B.ISI.ARPA. Эта зона распространяется на ISI.ARPA, где база данных делегирует полномочия этому серверу имен в другой зоне и не включает домен MIT.ARPA, который обслуживается сервером имен в AI.MIT.ARPA.
Этот сервер имен не является полномочным для каких-либо данных в классе CS. Он имеет указатель на корневой сервер для данных CS, который можно использовать для разрешения запросов класса CS.
Предположим, что этот сервер имен получил запрос в форме QNAME = A.ISI.ARPA, QTYPE = A и QCLASS = IN. При поиске полномочий будет замечена запись NS для «», его SOA в ARPA, делегирование в ISI.ARPA и возобновление полномочий в ISI.ARPA. Следовательно, он знал бы, что это был авторитет для этого запроса. Затем он найдет запись A для A.ISI.ARPA и вернет дейтаграмму, содержащую эту запись.
Другой запрос может быть QNAME=B.ISI.ARPA, QTYPE=MAILA, QCLASS=*. В этом случае сервер имен будет знать, что он не может быть авторизованным из-за значения «*» QCLASS, и будет искать записи для домена B.ISI.ARPA, которые совпадают. Предполагая, что сервер имен выполняет включение дополнительных записей, упомянутых в алгоритме сервера имен, возвращаемая датаграмма будет включать:
Если бы запрос был QNAME = DMS.MIT.ARPA, QTYPE = MAILA, QCLASS = IN, сервер имен обнаружил бы, что AI.MIT.ARPA был уполномоченным сервером имен, и вернул бы следующее:
MIT.ARPA NS IN AI.MIT.ARPA
AI.MIT.ARPA A IN 10.2.0.6
В этом случае запрашивающая сторона получает запрос на получение информации от сервера доменных имен MIT.ARPA, находящегося на AI.MIT.ARPA.
3.10. UDEL.ARPA и сервер имен UDEL.CSNET
В предыдущем обсуждении примера домена мы указали, что UDEL.CSNET и UDEL.ARPA могут быть одним и тем же сервером имен. В этом примере мы предполагаем, что это так. Таким образом, сервер имен является полномочием для корня для класса CS и полномочием для домена CSNET для класса IN.
Этот сервер имен работает с пересылкой почты между системами ARPA Internet и CSNET. Его RRs иллюстрируют один подход к решению этой проблемы. Сервер имен имеет следующие записи ресурсов:
Предположим, что этот сервер имен получил запрос в форме QNAME = UCI.CSNET, QTYPE = MAILA и QCLASS = IN. Сервер имен обнаружит, что он является полномочным для домена CSNET класса IN, но не найдет явных почтовых данных для UCI.CSNET.
Однако, используя запись * .CSNET, она создаст ответ:
UCI.CSNET MF IN UDEL.ARPA
UDEL.ARPA A IN 10.0.0.96
Если этот сервер имен получил запрос в форме QNAME = UCI.CSNET, QTYPE = MAILA и QCLASS = CS, сервер имен вернет:
UCI.CSNET MD CS UCI.CSNET
UCI.CSNET A CS 714-555-0000
Обратите внимание, что хотя эта схема позволяет пересылать всю почту, адресованную как <что-нибудь> .CSNET, она не помогает с именами, которые имеют более двух компонентов, например A.B.CSNET. Хотя эту проблему можно было бы «исправить» с помощью ряда записей MF для *. *. CSNET, *. *. *. CSNET и т. Д., Более изящным решением было бы ввести более умный алгоритм сопоставления с образцом на сервере имен CSNET.
3.11. Сводка требований к серверам имен
Требования к серверу имен следующие:
1. Он должен быть признан его родителем.
2. Он должен иметь полную информацию о ресурсах для всех доменных имен, для которых он является полномочным.
3. Он должен периодически обновлять авторитетную информацию из мастер-файла или сервера имен, который содержит мастер.
4. Если он кэширует информацию, он также должен обрабатывать управление TTL для этой информации.
5. Он должен отвечать на простые запросы.
3.12. Обратные запросы
Серверы имен также могут поддерживать обратные запросы, которые отображают конкретный ресурс на доменное имя или доменные имена, которые имеют этот ресурс. Например, хотя запрос может сопоставить имя домена с адресом хоста, соответствующий обратный запрос может сопоставить адрес обратно с именем домена.
Реализация этой службы является необязательной на сервере имен, но все серверы имен должны, по крайней мере, понимать сообщение обратного запроса и возвращать ответ об ошибке.
Доменная система не может гарантировать полноту или уникальность обратных запросов, поскольку доменная система организована по имени домена, а не по адресу хоста или любому другому типу ресурса. Как правило, распознаватель или другая программа, которая хочет гарантировать, что обратный запрос будет работать, должна использовать сервер имен, который, как известно, имеет соответствующие данные, или запрашивать все серверы имен в интересующем домене.
Например, если распознаватель хочет выполнить обратный запрос для произвольного хоста в Интернете ARPA, он должен обратиться к набору серверов имен, достаточных для того, чтобы знать, что все данные IN были учтены. На практике один обратный запрос к серверу имен, который имеет довольно обширную базу данных, должен удовлетворять подавляющему большинству обратных запросов.
Подробное обсуждение обратных запросов содержится в [14].
3.13. Завершение услуг
Некоторые существующие системы предоставляют возможность завершать частичные спецификации аргументов. Общий принцип заключается в том, что пользователь вводит первые несколько символов аргумента, а затем нажимает escape-символ, чтобы система предложила завершить остальные. Некоторые системы завершения требуют, чтобы пользователь набирал достаточно аргумента, чтобы быть уникальным; другие нет.
Другие системы позволяют пользователю указать один аргумент и попросить систему ввести другие аргументы. Например, многие почтовые системы позволяют пользователю указывать имя пользователя без хоста для локальной доставки почты.
Доменная система определяет транзакции завершения сервера имен, которые выполняют аналогичную услугу для доменной системы. Реализация этой службы является необязательной на сервере имен, но все серверы имен должны, по крайней мере, понимать запрос на завершение и возвращать ответ об ошибке.
Когда распознаватель желает запросить завершение, он отправляет серверу имен сообщение, которое устанавливает QNAME в частичную строку, QTYPE в тип требуемого ресурса и QCLASS в желаемый класс. Запрос на завершение также включает в себя RR для целевого домена. Целевой домен RR идентифицирует предпочтительное местоположение ресурса. В запросах на завершение QNAME по-прежнему должен иметь нулевую метку для завершения имени, но его присутствие игнорируется. Обратите внимание, что запрос на завершение не является запросом, но использует одни и те же форматы полей.
Например, запрос завершения может содержать QTYPE = A, QNAME = B, QCLASS = IN и RR для ISI.ARPA. Этот запрос требует завершения для ресурса, имя которого начинается с «B» и «близко» к ISI.ARPA. Это может быть типичным сокращением, используемым в сообществе ISI, которое использует «B» для обозначения B.ISI.ARPA.
Первым шагом в обработке запроса на завершение является поиск совпадения с «целой меткой». Когда сервер имен получает запрос, упомянутый выше, он просматривает все записи типа A, класса IN и чье доменное имя начинается (слева) с метками QNAME, в данном случае «B». Если несколько записей совпадают, сервер имен выбирает те, чьи доменные имена соответствуют (справа) большинству меток предпочтительного доменного имени. Если кандидатов по-прежнему несколько, сервер имен выбирает записи, которые имеют самое короткое (с точки зрения октетов в имени) доменное имя. Если осталось несколько записей, сервер имен возвращает их все.
Если в предыдущем алгоритме записи не найдены, сервер имен предполагает, что крайняя правая метка в QNAME не завершена, и ищет записи, которые соответствуют, но требуют добавления символов в крайнюю правую метку QNAME. Например, предыдущий поиск не соответствовал BB.ARPA B, но этот поиск соответствовал бы. Если найдено несколько попаданий, применяется та же стратегия удаления.
Подробное обсуждение завершения можно найти в [14].
4. Резольверы
4.1. Введение в резольверы
Resolvers — это программы, которые связывают пользовательские программы с серверами доменных имен. В простейшем случае распознаватель получает запрос от пользовательской программы (например, почтовых программ, TELNET, FTP) в виде вызова подпрограммы, системного вызова и т. Д. И возвращает требуемую информацию в форме, совместимой с данными локального хоста. форматы.
Поскольку для распознавателя может потребоваться обращение к нескольким серверам имен, количество времени, которое потребуется обработчику, может варьироваться. Эта разница является частью обоснования разделения между серверами имен и распознавателями; серверы имен могут использовать дейтаграммы и иметь время отклика, по существу равное задержке в сети плюс короткое время обслуживания, в то время как распознаватели могут занимать по существу неопределенное количество времени.
Мы ожидаем увидеть два типа распознавателей: простые распознаватели, которые при необходимости могут соединяться между несколькими серверами имен, и более сложные распознаватели, которые кэшируют записи ресурсов для использования в будущих запросах.
4.2. Простые резольверы
Для простого распознавателя требуются следующие возможности:
1. Он должен знать, как получить доступ к серверу имен, и должен знать полномочный сервер имен для хоста, который он обслуживает.
2. Он должен знать возможности протокола для своих клиентов, чтобы он мог задавать поля класса запросов, которые он отправляет, для возврата информации, полезной для его клиентов. Если распознаватель обслуживает клиента, который имеет несколько протокольных возможностей, он должен иметь возможность поддерживать предпочтения клиента.
Средство распознавания для многопротокольного клиента может либо собирать информацию для всех классов, используя значение * class, либо выполнять итерации для классов, поддерживаемых клиентом. Обратите внимание, что в любом случае распознаватель должен понимать настройки хоста. Например, хост, поддерживающий интернет-протоколы CSNET и ARPA, может предпочесть доставку почты (MD) пересылке почты (MF), независимо от протокола, или может предпочесть один протокол, независимо от того, требуется ли MD или MF. Необходимо соблюдать осторожность, чтобы предотвратить петли.
3. Средство распознавания должно быть способно соединяться через несколько серверов имен, чтобы получить доступ к официальному серверу имен для любого запроса. Резольвер должен защищаться от петель в рефералах; простая политика — отбрасывать рефералы, которые не соответствуют большему количеству имен запросов, чем ссылающийся сервер имен, а также избегать повторных запросов к одному и тому же серверу имен (этот тест должен выполняться с использованием адресов серверов имен вместо доменных имен, чтобы избежать проблемы, когда сервер имен имеет несколько доменных имен или ошибки присутствуют в псевдонимах).
4. Средство распознавания должно иметь возможность попробовать альтернативные серверы имен, когда сервер имен не отвечает.
5. Средство распознавания должно иметь возможность сообщать клиенту о различных условиях сбоя. Эти условия отказа включают неизвестное имя домена, неизвестный ресурс для известного имени домена и невозможность доступа к любому из авторитетных серверов имен для домена.
6. Если распознаватель использует дейтаграммы для запросов, он должен восстановить потерянные и дублированные дейтаграммы.
4.3. Резольверы с управлением кешем
Кэширование предоставляет инструмент для повышения производительности службы имен, но также является потенциальным источником неверных результатов. Например, база данных может кэшировать информацию, которая впоследствии изменяется на авторитетных серверах имен. Хотя эта проблема не может быть устранена без устранения кэширования, она может быть уменьшена до нечастой проблемы с помощью тайм-аутов.
Когда серверы имен возвращают записи ресурсов, каждая запись имеет соответствующее поле времени жизни (TTL). Это поле выражается в секундах и имеет значение 16 бит.
Когда распознаватель кэширует возвращенную запись ресурса, он также должен помнить поле TTL. Средство распознавания должно отбросить запись, когда пройдет эквивалентное количество времени. Если распознаватель использует базу данных совместно с сервером имен, он должен периодически уменьшать поле TTL импортируемых записей, а не просто удалять запись. Эта стратегия необходима, чтобы избежать экспорта записи ресурса, поле TTL которой не отражает количество времени, в течение которого запись ресурса была кэширована. Конечно, распознаватель не должен уменьшать поля записей TTL, для которых связанный сервер имен является полномочным.
Приложение 1. Спецификация синтаксиса доменного имени
Предпочтительный синтаксис доменных имен определяется следующими правилами BNF. Соблюдение этого синтаксиса приведет к уменьшению проблем со многими приложениями, которые используют доменные имена (например, почта, TELNET). Обратите внимание, что некоторые приложения, описанные в [14], используют доменные имена, содержащие двоичную информацию, и, следовательно, не следуют этому синтаксису.
<domain> ::= <subdomain> | » »
<subdomain> ::= <label> | <subdomain> «.» <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | «-»
<let-dig> ::= <letter> | <digit>
<letter>(<буква>) :: = любой из 52 алфавитных символов от A до Z в верхнем регистре и от a до z в нижнем регистре
<digit>(<цифра>) :: = любая из десяти цифр от 0 до 9
Обратите внимание, что хотя прописные и строчные буквы допускаются в доменных именах, к регистру не придается никакого значения. То есть два имени с одинаковым написанием, но с разным регистром должны рассматриваться как идентичные.
Метки должны соответствовать правилам для имен хостов ARPANET. Они должны начинаться с буквы, заканчиваться буквой или цифрой и содержать в качестве внутренних символов только буквы, цифры и дефис. Есть также некоторые ограничения по длине. Метки должны быть не более 63 символов.
Например, следующие строки идентифицируют хосты в ARPA Internet:
F.ISI.ARPA LINKABIT-DCN5.ARPA UCL-TAC.ARPA
Ссылки и библиография
[1] E. Feinler, K. Harrenstien, Z. Su, and V. White, «DOD Internet Host Table Specification», RFC 810, Network Information Center, SRI International, March 1982.
[2] J. Postel, «Computer Mail Meeting Notes», RFC 805, USC/Information Sciences Institute, February 1982.
[3] Z. Su, and J. Postel, «The Domain Naming Convention for Internet User Applications», RFC 819, Network Information Center, SRI International, August 1982.
[4] Z. Su, «A Distributed System for Internet Name Service», RFC 830, Network Information Center, SRI International, October 1982.
[5] K. Harrenstien, and V. White, «NICNAME/WHOIS», RFC 812, Network Information Center, SRI International, March 1982.
[6] M. Solomon, L. Landweber, and D. Neuhengen, «The CSNET Name Server», Computer Networks, vol 6, nr 3, July 1982.
[7] K. Harrenstien, «NAME/FINGER», RFC 742, Network Information Center, SRI International, December 1977.
[8] J. Postel, «Internet Name Server», IEN 116, USC/Information Sciences Institute, August 1979.
[9] K. Harrenstien, V. White, and E. Feinler, «Hostnames Server», RFC 811, Network Information Center, SRI International, March 1982.
[10] J. Postel, «Transmission Control Protocol», RFC 793, USC/Information Sciences Institute, September 1981.
[11] J. Postel, «User Datagram Protocol», RFC 768, USC/Information Sciences Institute, August 1980.
[12] J. Postel, «Simple Mail Transfer Protocol», RFC 821, USC/Information Sciences Institute, August 1980.
[13] J. Reynolds, and J. Postel, «Assigned Numbers», RFC 870, USC/Information Sciences Institute, October 1983.
[14] P. Mockapetris, «Domain Names — Implementation and Specification», RFC 883, USC/Information Sciences Institute, November 1983.
