RFC 1035 | Доменные имена — реализация и спецификация

1. Статус этой заметки

Этот RFC описывает детали системы и протокола домена и предполагает, что читатель знаком с концепциями, обсуждаемыми в сопутствующем RFC, «Доменные имена — понятия и возможности» [RFC-1034].

Скачать оригинальный документ на английском языке RFC 1035 PDF

Система доменов представляет собой смесь функций и типов данных, которые являются официальным протоколом, и функций и типов данных, которые все еще являются экспериментальными. Поскольку система доменов является преднамеренно расширяемой, всегда следует ожидать появления новых типов данных и экспериментального поведения в частях системы, выходящих за пределы официального протокола. Части официального протокола включают в себя стандартные запросы, ответы и форматы данных RR интернет-класса (например, адреса хоста). Со времени предыдущего набора RFC несколько определений изменились, поэтому некоторые предыдущие определения устарели.

Экспериментальные или устаревшие функции четко обозначены в этих RFC, и такую ​​информацию следует использовать с осторожностью.

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

Оглавление

1. Статус этой заметки
2. Введение
2.1. Обзор
2.2. Общие конфигурации
2.3. Условные обозначения
2.3.1. Предпочитаемый синтаксис имени
2.3.2. Порядок передачи данных
2.3.3. Случай символа
2.3.4. Пределы размера
3. Пространство доменных имен и определения RR
3.1. Определения пространства имен
3.2. Определения RR
3.2.1. Формат
3.2.2. Значения TYPE
3.2.3. Значения QTYPE
3.2.4. Значение CLASS
3.2.5. Значения QCLASS
3.3. Стандартные RR
3.3.1. Формат CNAME RDATA
3.3.2. Формат HINFO RDATA
3.3.3. Формат MB RDATA (ЭКСПЕРИМЕНТАЛЬНО)
3.3.4. Формат MD RDATA (устарел)
3.3.5. Формат MF RDATA (устарел)
3.3.6. Формат MG RDATA (ЭКСПЕРИМЕНТАЛЬНО)
3.3.7. Формат MINFO RDATA (ЭКСПЕРИМЕНТАЛЬНО)
3.3.8. Формат MR RDATA (ЭКСПЕРИМЕНТАЛЬНО)
3.3.9. Формат MX RDATA
3.3.10. Формат NULL RDATA (ЭКСПЕРИМЕНТАЛЬНО)
3.3.11. Формат NS RDATA
3.3.12. Формат PTR RDATA
3.3.13. Формат SOA RDATA
3.3.14. Формат TXT RDATA
3.4. ARPA Интернет-специфичные RR
3.4.1. Формат A RDATA
3.4.2. Формат WKS RDATA
3.5. Домен IN-ADDR.ARPA
3.6. Определение новых типов, классов и специальных пространств имен
4. Сообщения
4.1. Формат
4.1.1. Формат раздела заголовка
4.1.2. Формат раздела вопросов
4.1.3. Формат записи ресурса
4.1.4. Сжатие сообщений
4.2. Транспорт
4.2.1. Использование UDP
4.2.2. Использование TCP
5. Основные файлы
5.1. Формат
5.2. Использование мастер-файлов для определения зон
5.3. Пример главного файла
6. Реализация сервера имен
6.1. Архитектура
6.1.1. Контроль
6.1.2. База данных
6.1.3. Время
6.2. Стандартная обработка запросов
6.3. Обновление зоны и перезагрузка обработки
6.4. Обратные запросы (необязательно)
6.4.1. Содержание обратных запросов и ответов
6.4.2. Пример обратного запроса и ответа
6.4.3. Обратная обработка запросов
6.5. Завершение запросов и ответов
7. Реализация решателя (резольвера)
7.1. Преобразование пользовательского запроса в запрос
7.2. Отправка запросов
7.3. Обработка ответов
7.4. Использование кеша
8. Поддержка по почте
8.1. Обязательный обмен почтой
8.2. Привязка почтового ящика (экспериментальная)
9. Ссылки и библиография
Индекс

 

2. Введение

2.1. Обзор

Цель доменных имен — предоставить механизм для именования ресурсов таким образом, чтобы имена могли использоваться на разных хостах, в сетях, семействах протоколов, интернет-сетях и административных организациях.

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

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

Серверы имен управляют двумя видами данных. Данные первого типа хранятся в наборах, называемых зонами; каждая зона является полной базой данных для определенного «сокращенного» поддерева доменного пространства. Эти данные называются достоверными. Сервер имен периодически проверяет актуальность своих зон и, если нет, получает новую копию обновленных зон из основных файлов, хранящихся локально или на другом сервере имен. Второй тип данных — это кэшированные данные, которые были получены локальным распознавателем. Эти данные могут быть неполными, но повышают производительность процесса поиска при неоднократном доступе к нелокальным данным. Кэшированные данные в конечном итоге отбрасываются механизмом тайм-аута.

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

 

2.2. Общие конфигурации

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

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

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

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

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

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

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

Информационный поток в хосте, который поддерживает все аспекты системы доменных имен, показан ниже:

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

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

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

 

2.3. Условные обозначения

Система доменов имеет несколько соглашений, касающихся низкоуровневых, но фундаментальных вопросов. Хотя разработчик может свободно нарушать эти соглашения В СВОЕЙ СОБСТВЕННОЙ СИСТЕМЕ, он должен соблюдать эти соглашения во ВСЕМ поведении, наблюдаемом от других хостов.

2.3.1. Предпочитаемый синтаксис имени

Спецификации DNS пытаются быть максимально общими в правилах построения доменных имен. Идея состоит в том, что имя любого существующего объекта может быть выражено как доменное имя с минимальными изменениями.

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

Например, при именовании почтового домена пользователь должен удовлетворять как правилам этой памятки, так и правилам в RFC-822. При создании нового имени хоста должны соблюдаться старые правила для HOSTS.TXT. Это позволяет избежать проблем при конвертации старого программного обеспечения в доменные имена.

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

<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 символов.

Например, следующие строки идентифицируют хосты в Интернете:

A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA

 

2.3.2. Порядок передачи данных

Порядок передачи заголовка и данных, описанных в этом документе, разрешен до уровня октетов. Всякий раз, когда на диаграмме показана группа октетов, порядок передачи этих октетов является нормальным порядком, в котором они читаются на английском языке. Например, на следующей диаграмме октеты передаются в порядке их нумерации.

Всякий раз, когда октет представляет числовое значение, самый левый бит на диаграмме является старшим или старшим битом. То есть бит с меткой 0 является наиболее значимым битом. Например, следующая диаграмма представляет значение 170 (десятичное).

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

2.3.3. Случай символа

Для всех частей DNS, которые являются частью официального протокола, все сравнения между символьными строками (например, метки, доменные имена и т. Д.) Выполняются без учета регистра. В настоящее время это правило действует во всей системе доменов без исключения. Тем не менее, в будущих дополнениях, выходящих за рамки текущего использования, возможно, потребуется использовать возможности полного двоичного октета в именах, поэтому следует избегать попыток сохранять доменные имена в 7-битном ASCII или использовать специальные байты для завершения меток и т. д.

Когда данные поступают в доменную систему, их первоначальный регистр должен быть сохранен при любой возможности. При определенных обстоятельствах это не может быть сделано. Например, если в базе данных хранятся два RR, один в x.y, а другой в X.Y, они фактически хранятся в одном и том же месте в базе данных, и, следовательно, будет сохранен только один регистр. Основное правило заключается в том, что регистр можно отбросить только тогда, когда данные используются для определения структуры в базе данных, и два имени идентичны при сравнении без учета регистра.

Потеря чувствительных к регистру данных должна быть сведена к минимуму. Таким образом, хотя данные для x.y и X.Y могут храниться в одном месте x.y или X.Y, данные для a.x и B.X никогда не будут храниться в A.x, A.X, b.x или b.X. В целом, это сохраняет случай первой метки доменного имени, но вызывает стандартизацию меток внутренних узлов.

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

2.3.4. Пределы размера

Различные объекты и параметры в DNS имеют ограничения по размеру. Они перечислены ниже. Некоторые могут быть легко изменены, другие являются более фундаментальными.

labels (метки) — 63 октета или меньше

names (имена) — 255 октетов или меньше

TTL — положительные значения 32-разрядного числа со знаком.

UDP-сообщения — 512 октетов или меньше

 

3. Пространство доменных имен и определения RR

3.1. Определения пространства имен

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

Для упрощения реализации общая длина доменного имени (то есть октетов меток и октетов длины меток) ограничена 255 октетами или менее.

Хотя метки могут содержать любые 8-битные значения в октетах, составляющих метку, настоятельно рекомендуется, чтобы метки следовали предпочтительному синтаксису, описанному в другом месте этого меморандума, который совместим с существующими соглашениями об именах хостов. Серверы имен и распознаватели должны сравнивать метки без учета регистра (т. е. A = a), предполагая, что ASCII имеет нулевую четность. Не алфавитные коды должны точно совпадать.

3.2. Определения RR

3.2.1. Формат

Все RR имеют одинаковый формат верхнего уровня, показанный ниже:

где:

NAME — имя владельца, то есть имя узла, к которому относится эта запись ресурса.

TYPE — два октета, содержащий один из кодов RR TYPE.

CLASS — два октета, содержащие один из кодов RR CLASS.

TTL — 32-разрядное целое число со знаком, указывающее интервал времени, в течение которого запись ресурса может быть кэширована до повторного обращения к источнику информации. Нулевые значения интерпретируются как означающие, что RR может использоваться только для выполняемой транзакции и не должен кэшироваться. Например, записи SOA всегда распространяются с нулевым TTL, чтобы запретить кэширование. Нулевые значения также могут быть использованы для чрезвычайно изменчивых данных.

RDLENGTH — 16-разрядное целое число без знака, указывающее длину в октетах поля RDATA.

RDATA — строка октетов переменной длины, которая описывает ресурс. Формат этой информации варьируется в зависимости от ТИПА и КЛАССА записи ресурса.

3.2.2. Значения TYPE

Поля TYPE используются в записях ресурсов. Обратите внимание, что эти типы являются подмножеством QTYPE.

TYPE — ценность и значение
А — (1) адрес хоста
NS — 2 авторитетный сервер имен
MD — 3 почтовый адрес (устарел — используйте MX)
MF — 4 почтовый экспедитор (устарел — используйте MX)
CNAME — 5 каноническое имя для псевдонима
SOA — 6 знаменует собой начало зоны власти
MB — 7 имя домена почтового ящика (ЭКСПЕРИМЕНТАЛЬНО)
MG — 8 член почтовой группы (ЭКСПЕРИМЕНТАЛЬНО)
MR — 9 почтовое переименование доменного имени (ЭКСПЕРИМЕНТАЛЬНО)
NULL — 10 ноль RR (ЭКСПЕРИМЕНТАЛЬНО)
WKS — 11 хорошо известное описание сервиса
PTR — 12 указатель доменного имени
HINFO — 13 Информация о хосте
MINFO — 14 информация о почтовом ящике или списке рассылки
MX — 15 почтовый обмен
TXT — 16 Текстовые строки

3.2.3. Значения QTYPE

Поля QTYPE появляются в вопросительной части запроса. QTYPES — это расширенный набор TYPE, поэтому все TYPE являются действительными QTYPE. Кроме того, определены следующие QTYPE:

AXFR —   (252) Запрос на передачу всей зоны
MAILB — 253 Запрос на записи, связанные с почтовым ящиком (MB, MG или MR)
MAILA — 254 Запрос RR почтового агента (устарел — см. MX)
*                (255) — Запрос на все записи

3.2.4. Значение CLASS

Поля CLASS появляются в записях ресурса. Определены следующие мнемоника и значения CLASS:

В — 1 интернет
CS — 2 — класс CSNET (устаревший — используется только для примеров в некоторых устаревших RFC)
CH — 3 класс CHAOS
HS — 4 Гесиод [Dyer 87]

3.2.5. Значения QCLASS

Поля QCLASS появляются в разделе вопросов запроса. Значения QCLASS — это расширенный набор значений CLASS; каждый CLASS является действительным QCLASS. В дополнение к значениям CLASS определены следующие QCLASS:

* — (255) любой класс

3.3. Стандартные RR

Ожидается, что следующие определения RR будут встречаться, по крайней мере, потенциально, во всех классах. В частности, NS, SOA, CNAME и PTR будут использоваться во всех классах и иметь одинаковый формат во всех классах. Поскольку их формат RDATA известен, все доменные имена в разделе RDATA этих RR могут быть сжаты.

<domain-name> — это доменное имя, представленное в виде серии меток и оканчивающееся меткой нулевой длины.

<character-string> (символьная строка) — это октет одинарной длины, за которым следует такое количество символов. <символьная строка> обрабатывается как двоичная информация и может иметь длину до 256 символов (включая октет длины).

3.3.1. Формат CNAME RDATA

где:

CNAME — <имя-домена>, которое указывает каноническое или основное имя владельца. Имя владельца является псевдонимом.

CNAME RR не вызывают дополнительной обработки раздела, но серверы имен могут в некоторых случаях перезапустить запрос по каноническому имени. Подробнее см. Описание логики сервера имен в [RFC-1034].

3.3.2. Формат HINFO RDATA

где:

CPU — <символьная строка>, которая указывает тип процессора.

OS — <символьная строка>, которая указывает тип операционной системы.

Стандартные значения для CPU и OS можно найти в [RFC-1010].

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

3.3.3. Формат MB RDATA (ЭКСПЕРИМЕНТАЛЬНО)

где:

MADNAME — <имя-домена>, которое указывает хост с указанным почтовым ящиком.

Записи MB вызывают дополнительную обработку раздела, которая ищет RR типа A, соответствующие MADNAME.

3.3.4. Формат MD RDATA (устарел)

где:

MADNAME — <имя-домена>, которое указывает хост, у которого есть почтовый агент для домена, который должен иметь возможность доставлять почту для домена.

Записи MD вызывают дополнительную обработку раздела, которая ищет запись типа A, соответствующую MADNAME.

MD устарела. См. Определение MX и [RFC-974] для получения подробной информации о новой схеме. Рекомендуемая политика для работы с MD RR, найденными в главном файле, состоит в том, чтобы отклонить их или преобразовать их в MX RR с предпочтением 0.

3.3.5. Формат MF RDATA (устарел)

где:

MADNAME — <имя-домена>, которое указывает хост, у которого есть почтовый агент для домена, который будет принимать почту для пересылки в домен.

Записи MF вызывают дополнительную обработку раздела, которая ищет запись типа A, соответствующую MADNAME.

MF устарел. См. Определение MX и [RFC-974] для получения подробной информации о новой схеме. Рекомендуемая политика для работы с MD RR, найденными в главном файле, состоит в том, чтобы отклонить их или преобразовать их в MX RR с предпочтением 10.

3.3.6. Формат MG RDATA (ЭКСПЕРИМЕНТАЛЬНО)

где:

MGMNAME — <имя домена>, которое указывает почтовый ящик, который является членом почтовой группы, указанной именем домена.

Записи MG не вызывают дополнительной обработки раздела.

3.3.7. Формат MINFO RDATA (ЭКСПЕРИМЕНТАЛЬНО)

где:

RMAILBX — <имя-домена>, которое указывает почтовый ящик, который отвечает за список рассылки или почтовый ящик. Если это доменное имя называет корнем, владелец MINFO RR несет ответственность за себя. Обратите внимание, что многие существующие списки рассылки используют X-запрос почтового ящика для поля RMAILBX списка X, например, Msgroup-запрос для Msgroup. Это поле предоставляет более общий механизм.

EMAILBX — <domain-name>, который указывает почтовый ящик, который должен получать сообщения об ошибках, относящиеся к списку рассылки или почтовому ящику, указанному владельцем MINFO RR (аналогично предложенному полю ERRORS-TO:). Если это доменное имя называет корнем, ошибки должны быть возвращены отправителю сообщения.

Записи MINFO не вызывают никакой дополнительной обработки раздела. Хотя эти записи могут быть связаны с простым почтовым ящиком, они обычно используются со списком рассылки.

 

3.3.8. Формат MR RDATA (ЭКСПЕРИМЕНТАЛЬНО)

где:

NEWNAME — <имя домена>, которое указывает почтовый ящик, который является правильным переименованием указанного почтового ящика.

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

3.3.9. Формат MX RDATA

где:

PREFERENCE — 16-разрядное целое число, которое указывает предпочтение, данное этому RR среди других у того же владельца. Более низкие значения являются предпочтительными.

EXCHANGE — <domain-name>, которое указывает хост, желающий действовать в качестве почтового обмена для имени владельца.

MX-записи вызывают тип A, дополнительный раздел обработки для хоста, указанного в EXCHANGE. Использование MX RR подробно объясняется в [RFC-974].

3.3.10. Формат NULL RDATA (ЭКСПЕРИМЕНТАЛЬНО)

В поле RDATA может быть что-либо вообще, если оно составляет 65535 октетов или меньше.

NULL-записи не вызывают дополнительной обработки раздела. NULL RR не допускаются в основных файлах.

NULL используются в качестве заполнителей в некоторых экспериментальных расширениях DNS.

3.3.11. Формат NS RDATA

где:

NSDNAME — <имя-домена>, которое указывает хост, который должен быть полномочным для указанного класса и домена.

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

NS RR заявляет, что у указанного хоста должна быть зона, начинающаяся с имени владельца указанного класса. Обратите внимание, что класс может не указывать семейство протоколов, которое следует использовать для связи с хостом, хотя обычно это сильный совет. Например, хосты, которые являются серверами имен для информации класса Internet (IN) или Hesiod (HS), обычно запрашиваются с использованием протоколов класса IN.

 

3.3.12. Формат PTR RDATA

где:

PTRDNAME — <имя-домена>, которое указывает на какое-то место в пространстве имен домена.

Записи PTR не вызывают дополнительной обработки раздела. Эти RR используются в специальных доменах, чтобы указывать на другое место в доменном пространстве. Эти записи являются простыми данными и не предполагают какой-либо специальной обработки, подобной той, что выполняется CNAME, которая идентифицирует псевдонимы. См. Описание домена IN-ADDR.ARPA для примера.

3.3.13. Формат SOA RDATA

где:

MNAME — <имя-домена> сервера имен, который был исходным или основным источником данных для этой зоны.

RNAME — <имя домена>, которое указывает почтовый ящик лица, ответственного за эту зону.

SERIAL — 32-разрядный номер версии без знака оригинальной копии зоны. Зональные передачи сохраняют это значение. Это значение переносится и должно сравниваться с использованием арифметики пространства последовательностей.

REFRESH — 32-битный интервал времени перед обновлением зоны.

RETRY — 32-разрядный интервал времени, который должен пройти до неудачного обновления, следует повторить.

EXPIRE — 32-битное значение времени, которое задает верхний предел временного интервала, который может пройти до того, как зона больше не будет авторизованной.

MINIMUM — 32-битное поле минимального TTL без знака, которое должно быть экспортировано с любым RR из этой зоны.

Записи SOA не вызывают дополнительной обработки раздела.

Время указывается в секундах.

Большинство из этих полей имеют отношение только к операциям обслуживания сервера имен. Однако MINIMUM используется во всех операциях запроса, которые извлекают RR из зоны. Всякий раз, когда RR отправляется в ответ на запрос, поле TTL устанавливается равным максимуму поля TTL из RR и поля MINIMUM в соответствующем SOA. Таким образом, MINIMUM является нижней границей поля TTL для всех RR в зоне. Обратите внимание, что это использование MINIMUM должно происходить, когда RR копируются в ответ, а не когда зона загружается из мастер-файла или посредством передачи зоны. Причина этого условия заключается в том, чтобы позволить будущим средствам динамического обновления изменять SOA RR с известной семантикой.

3.3.14. Формат TXT RDATA

где:

TXT-DATA Один или несколько <символьных> строк.

TXT RR используются для хранения описательного текста. Семантика текста зависит от домена, в котором он находится.

3.4. ARPA Интернет-специфичные RR

3.4.1. Формат A RDATA

где:

ADDRESS — 32-битный интернет-адрес.

Хосты с несколькими интернет-адресами будут иметь несколько записей А.

Записи не вызывают дополнительной обработки раздела. Раздел RDATA строки A в главном файле представляет собой Интернет-адрес, выраженный в виде четырех десятичных чисел, разделенных точками без каких-либо встроенных пробелов (например, «10.2.0.52» или «192.0.5.6»).

3.4.2. Формат WKS RDATA

где:

ADDRESS — 32-битный интернет-адрес

PROTOCOL — 8-битный номер протокола IP

<BIT MAP> — Битовая карта переменной длины. Битовая карта должна быть кратна 8 битам.

Запись WKS используется для описания хорошо известных сервисов, поддерживаемых конкретным протоколом на конкретном интернет-адресе. Поле PROTOCOL указывает номер протокола IP, а битовая карта имеет один бит на порт указанного протокола. Первый бит соответствует порту 0, второй — порту 1 и т. Д. Если битовая карта не включает бит для интересующего протокола, этот бит считается равным нулю. Соответствующие значения и мнемоника для портов и протоколов указаны в [RFC-1010].

Например, если PROTOCOL = TCP (6), 26-й бит соответствует TCP-порту 25 (SMTP). Если этот бит установлен, SMTP-сервер должен прослушивать TCP-порт 25; если ноль, SMTP сервис не поддерживается по указанному адресу.

Цель WKS RR — предоставить информацию о доступности для серверов для TCP и UDP. Если сервер поддерживает как TCP, так и UDP или имеет несколько интернет-адресов, используется несколько WKS RR.

WKS RR не вызывают дополнительной обработки раздела.

В основных файлах порты и протоколы выражаются с помощью мнемоник или десятичных чисел.

3.5. Домен IN-ADDR.ARPA

Интернет использует специальный домен для поддержки местоположения шлюза и Интернет-адреса для сопоставления хоста. Другие классы могут использовать аналогичную стратегию в других областях. Цель этого домена — предоставить гарантированный метод для выполнения сопоставления имени хоста с именем хоста и упростить запросы для определения местоположения всех шлюзов в конкретной сети в Интернете.

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

Домен начинается с IN-ADDR.ARPA и имеет подструктуру, которая соответствует структуре интернет-адресации.

Доменные имена в домене IN-ADDR.ARPA должны иметь до четырех меток в дополнение к суффиксу IN-ADDR.ARPA. Каждая метка представляет один октет интернет-адреса и выражается в виде строки символов для десятичного значения в диапазоне 0-255 (с опущенными начальными нулями, за исключением случая нулевого октета, который представлен одним нулем).

Адреса хостов представлены доменными именами, в которых указаны все четыре метки. Таким образом, данные для интернет-адреса 10.2.0.52 находятся по доменному имени 52.0.2.10.IN-ADDR.ARPA. Изменение, хотя и неудобное для чтения, позволяет делегировать зоны, которые являются точно одной сетью адресного пространства. Например, 10.IN-ADDR.ARPA может быть зоной, содержащей данные для ARPANET, а 26.IN-ADDR.ARPA может быть отдельной зоной для MILNET. Адресные узлы используются для хранения указателей на основные имена хостов в обычном доменном пространстве.

Номера сети соответствуют некоторым нетерминальным узлам на разной глубине в домене IN-ADDR.ARPA, поскольку номера сети Интернет составляют 1, 2 или 3 октета. Сетевые узлы используются для хранения указателей на имена основных узлов шлюзов, подключенных к этой сети. Поскольку шлюз по определению находится в более чем одной сети, он обычно имеет два или более сетевых узлов, которые указывают на него. Шлюзы также будут иметь указатели уровня хоста по своим полностью определенным адресам.

Как указатели шлюза на узлах сети, так и обычные указатели узлов на узлах с полным адресом используют PTR RR, чтобы указывать назад на имена первичных доменов соответствующих узлов.

Например, домен IN-ADDR.ARPA будет содержать информацию о шлюзе ISI между сетями 10 и 26, шлюзе MIT от сети 10 до сети MIT 18 и хостах A.ISI.EDU и MULTICS.MIT.EDU. Предполагая, что шлюз ISI имеет адреса 10.2.0.22 и 26.0.0.103 и имя MILNETGW. ISI.EDU, а шлюз MIT имеет адреса 10.0.0.77 и 18.10.0.4 и имя GW.LCS.MIT.EDU, база данных домена будет содержать:

10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
22.0.2.10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
103.0.0.26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
77.0.0.10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
4.0.10.18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.
6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.

Таким образом, программа, которая хотела бы найти шлюзы в сети 10, создала бы запрос в форме QTYPE = PTR, QCLASS = IN, QNAME = 10.IN-ADDR.ARPA. Он получил бы два RR в ответ:

10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.

Затем программа может инициировать запросы QTYPE = A, QCLASS = IN для MILNETGW. ISI.EDU. и GW.LCS.MIT.EDU. узнать интернет-адреса этих шлюзов.

Средство распознавания, которое хочет найти имя хоста, соответствующее адресу хоста в Интернете 10.0.0.6, выполнит запрос в форме QTYPE = PTR, QCLASS = IN, QNAME = 6.0.0.10.IN-ADDR.ARPA и получит:

6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.

Несколько предостережений относятся к использованию этих услуг:

• Поскольку специальный домен IN-ADDR.ARPA и обычный домен или конкретный хост или шлюз будут находиться в разных зонах, существует вероятность того, что данные могут быть противоречивыми.
• Шлюзы часто имеют два имени в отдельных доменах, только одно из которых может быть основным.
• Системы, которые используют базу данных домена для инициализации своих таблиц маршрутизации, должны начинаться с достаточного количества информации шлюза, чтобы гарантировать, что они могут получить доступ к соответствующему серверу имен.
• Данные шлюза отражают существование шлюза только способом, эквивалентным текущему файлу HOSTS.TXT. Он не заменяет информацию о динамической доступности из GGP или EGP.

3.6. Определение новых типов, классов и специальных пространств имен

Ранее определенные типы и классы используются на момент написания этой заметки. Следует ожидать новых определений. В этом разделе приводятся некоторые рекомендации для дизайнеров, рассматривающих дополнения к существующим объектам. Список рассылки NAMEDROPPERS@SRI-NIC.ARPA — это форум, на котором происходит общее обсуждение вопросов дизайна.

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

Новые типы и классы нуждаются в мнемонике для основных файлов; Формат мастер-файлов требует, чтобы мнемоника для типа и класса была непересекающейся.

Значения TYPE и CLASS должны быть надлежащим подмножеством QTYPE и QCLASS, соответственно.

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

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

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

Например, исходная форма привязки почтового обмена использовала два типа RR: один для представления «более близкого» обмена (MD) и один для представления «менее близкого» обмена (MF). Сложность состоит в том, что наличие одного типа RR в кеше не передает никакой информации о другом, потому что запрос, который получил кэшированную информацию, мог использовать QTYPE MF, MD или MAILA (который соответствовал обоим). Переработанный сервис использовал один тип (MX) со значением «preference» в разделе RDATA, который может заказывать разные RR. Однако, если в кэше найдены какие-либо записи MX, то все должно быть там.

4. Сообщения

4.1. Формат

Все коммуникации внутри протокола домена передаются в едином формате, который называется сообщением. Формат верхнего уровня сообщения состоит из 5 разделов (некоторые из которых в некоторых случаях пусты), показанных ниже:

Header
Question — вопрос к серверу имен
Answer — RR, отвечающие на вопрос
Authority — RR, указывающие на авторитет
Additional — RR, содержащие дополнительную информацию

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

Названия разделов после заголовка получены из их использования в стандартных запросах. Раздел вопросов содержит поля, которые описывают вопрос к серверу имен. Этими полями являются тип запроса (QTYPE), класс запроса (QCLASS) и имя домена запроса (QNAME). Последние три раздела имеют одинаковый формат: возможно, пустой список объединенных записей ресурсов (RR). Раздел ответов содержит RR, которые отвечают на вопрос; раздел полномочий содержит RR, которые указывают на авторитетный сервер имен; раздел дополнительных записей содержит RR, которые относятся к запросу, но не являются строго ответами на вопрос.

4.1.1. Формат раздела Header (заголовка)

Заголовок содержит следующие поля:

где:

ID — 16-битный идентификатор, назначаемый программой, которая генерирует любой вид запроса. Этот идентификатор копируется в соответствующий ответ и может использоваться запрашивающей стороной для сопоставления ответов на невыполненные запросы.

QR — однобитное поле, которое указывает, является ли это сообщение запросом (0) или ответом (1).

OPCODE — четырехбитное поле, которое определяет тип запроса в этом сообщении. Это значение задается отправителем запроса и копируется в ответ. Значения:

• 0 стандартный запрос (QUERY)
• 1 обратный запрос (IQUERY)
• 2 запрос состояния сервера (STATUS)
• 3-15 зарезервировано для будущего использования

AA — (Authoritative Answer — Официальный ответ) — этот бит действителен в ответах и ​​указывает, что отвечающий сервер имен является полномочием для доменного имени в разделе вопросов.

Обратите внимание, что содержимое раздела ответа может иметь несколько имен владельцев из-за псевдонимов. Бит AA соответствует имени, соответствующему имени запроса, или имени первого владельца в разделе ответов.

TC — (TrunCation) — указывает, что это сообщение было усечено из-за длины, превышающей длину, разрешенную для канала передачи.

RD — (Recursion Desired — требуемая рекурсия) — этот бит может быть установлен в запросе и скопирован в ответ. Если установлен RD, он указывает серверу имен рекурсивно выполнять запрос. Поддержка рекурсивных запросов не является обязательной.

RA — (Доступна рекурсия) — эта опция устанавливается или сбрасывается в ответе и обозначает, доступна ли поддержка рекурсивных запросов на сервере имен.

Z — Зарезервировано для будущего использования. Должен быть равен нулю во всех запросах и ответах.

RCODE — (код ответа) — это 4-битное поле устанавливается как часть ответов. Значения имеют следующую интерпретацию:

• 0 Нет ошибок
• 1 Ошибка формата — сервер имен не смог интерпретировать запрос.
• 2 Ошибка сервера — серверу имен не удалось обработать этот запрос из-за проблемы с сервером имен.
• 3 Ошибка имени. Имеет смысл только для ответов от авторитетного сервера имен. Этот код означает, что доменное имя, указанное в запросе, не существует.
• 4 Не реализовано — сервер имен не поддерживает запрошенный тип запроса.
• 5 Отклонено — сервер имен отказывается выполнять указанную операцию по соображениям политики. Например, сервер имен может не захотеть предоставлять информацию конкретному запрашивающему, или сервер имен может не захотеть выполнять конкретную операцию (например, перенос зоны) для определенных данных.
• 6-15 Зарезервировано для будущего использования.

QDCOUNT — 16-разрядное целое число без знака, указывающее количество записей в разделе вопросов.

ANCOUNT — 16-разрядное целое число без знака, указывающее количество записей ресурсов в разделе ответов.

NSCOUNT — 16-разрядное целое число без знака, указывающее количество записей ресурсов сервера имен в разделе авторитетных записей.

ARCOUNT — 16-разрядное целое число без знака, указывающее количество записей ресурсов в разделе дополнительных записей.

4.1.2. Формат раздела Question (вопросов)

Раздел вопросов используется для переноса «вопроса» в большинстве запросов, то есть параметров, которые определяют, что задают. Раздел содержит записи QDCOUNT (обычно 1), каждый из которых имеет следующий формат:

где:

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

QTYPE — код из двух октетов, который определяет тип запроса. Значения для этого поля включают все коды, действительные для поля TYPE, а также некоторые более общие коды, которые могут соответствовать более чем одному типу RR.

QCLASS — двухоктетный код, который определяет класс запроса. Например, поле QCLASS является IN для Интернета.

4.1.3. Формат записи ресурса

Ответ, полномочия и дополнительные разделы имеют одинаковый формат: переменное количество записей ресурсов, где количество записей указано в соответствующем поле счетчика в заголовке. Каждая запись ресурса имеет следующий формат:

где:

NAME — доменное имя, к которому относится эта запись ресурса.

TYPE — два октета, содержащий один из кодов типа RR. В этом поле указывается значение данных в поле RDATA.

CLASS — два октета, которые определяют класс данных в поле RDATA.

TTL — 32-разрядное целое число без знака, которое указывает временной интервал (в секундах), в течение которого запись ресурса может быть кэширована до ее удаления. Нулевые значения интерпретируются как означающие, что RR может использоваться только для выполняемой транзакции и не должен кэшироваться.

RDLENGTH — 16-разрядное целое число без знака, указывающее длину в октетах поля RDATA.

RDATA — строка октетов переменной длины, которая описывает ресурс. Формат этой информации варьируется в зависимости от ТИПА и КЛАССА записи ресурса. Например, если TYPE — A, а CLASS — IN, поле RDATA — это 4-октетный интернет-адрес ARPA.

 

4.1.4. Сжатие сообщений

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

Указатель принимает форму последовательности из двух октетов:

Первые два бита едины. Это позволяет отличить указатель от метки, поскольку метка должна начинаться с двух нулевых битов, поскольку метки ограничены 63 октетами или менее. (Комбинации 10 и 01 зарезервированы для будущего использования.) Поле OFFSET указывает смещение от начала сообщения (то есть первый октет поля ID в заголовке домена). Смещение нуля определяет первый байт поля идентификатора и т. д.

Схема сжатия позволяет представить доменное имя в сообщении в виде:

• последовательность меток, заканчивающаяся нулевым октетом
• указатель
• последовательность меток, заканчивающаяся указателем

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

Если доменное имя содержится в части сообщения, подчиненной полю длины (например, в разделе RDATA RR), и используется сжатие, длина сжатого имени используется в расчете длины, а не длины расширенного имени.

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

Например, дейтаграмме может потребоваться использовать доменные имена F.ISI.ARPA, FOO.F.ISI.ARPA, ARPA и корень. Игнорируя другие поля сообщения, эти доменные имена могут быть представлены как:

Доменное имя для F.ISI.ARPA показано со смещением 20. Доменное имя FOO.F.ISI.ARPA показано со смещением 40; это определение использует указатель для объединения метки для FOO к ранее определенному F.ISI.ARPA. ARPA доменного имени определяется по смещению 64 с использованием указателя на компонент ARPA имени F.ISI.ARPA в 20; обратите внимание, что этот указатель полагается на ARPA, являющуюся последней меткой в строке в 20. Имя корневого домена определяется одним октетом из нулей в 92; имя корневого домена не имеет меток.

4.2. Транспорт

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

Интернет поддерживает доступ к серверу имен с использованием TCP [RFC-793] через порт 53 сервера (десятичный), а также доступ к дейтаграмме с использованием UDP [RFC-768] через порт UDP 53 (десятичный).

4.2.1. Использование UDP

Сообщения, отправленные с использованием UDP-порта сервера пользователя 53 (десятичное число).

Сообщения, передаваемые по протоколу UDP, ограничены 512 байтами (не считая заголовков IP или UDP). Более длинные сообщения усекаются, и бит TC устанавливается в заголовке.

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

Оптимальная политика ретрансляции UDP будет варьироваться в зависимости от производительности Интернета и потребностей клиента, но рекомендуется следующее:

• Клиент должен попробовать другие серверы и адреса серверов, прежде чем повторять запрос к определенному адресу сервера.
• Интервал повторной передачи должен быть основан на предварительной статистике, если это возможно. Слишком агрессивная ретрансляция может легко замедлить реакцию сообщества в целом. В зависимости от того, насколько хорошо клиент подключен к ожидаемым серверам, минимальный интервал повторной передачи должен составлять 2-5 секунд.

Дополнительные предложения по выбору сервера и политике повторной передачи можно найти в разделе разрешения этой заметки.

4.2.2. Использование TCP

Сообщения, отправляемые по TCP-соединениям, используют порт сервера 53 (десятичный). Сообщение имеет префикс с двухбайтовым полем длины, которое дает длину сообщения, исключая двухбайтовое поле длины. Это поле длины позволяет низкоуровневой обработке собрать полное сообщение перед тем, как начать его анализ.

Рекомендуется несколько политик управления соединениями:

• Сервер не должен блокировать другие действия, ожидающие данные TCP.
• Сервер должен поддерживать несколько соединений.
• Сервер должен предполагать, что клиент инициирует закрытие соединения, и должен откладывать закрытие своего конца соединения до тех пор, пока не будут выполнены все невыполненные клиентские запросы.
• Если серверу необходимо закрыть неактивное соединение, чтобы восстановить ресурсы, ему следует подождать, пока соединение не будет работать в течение периода порядка двух минут. В частности, сервер должен разрешить выполнение последовательности запросов SOA и AXFR (которая начинает операцию обновления) для одного соединения. Поскольку сервер все равно не сможет отвечать на запросы, вместо грациозного закрытия можно использовать одностороннее закрытие или сбро

5. Основные файлы

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

5.1. Формат

Формат этих файлов представляет собой последовательность записей. Записи преимущественно ориентированы на строки, хотя скобки можно использовать для продолжения списка элементов через границу строки, а текстовые литералы могут содержать CRLF в тексте. Любая комбинация вкладок и пробелов действует как разделитель между отдельными элементами, составляющими запись. Конец любой строки в главном файле может заканчиваться комментарием. Комментарий начинается с «;» (точка с запятой).

Следующие записи определены:

<blank>[<comment>]
$ORIGIN <domain-name> [<comment>]
$INCLUDE <file-name> [<domain-name>] [<comment>]
<domain-name><rr> [<comment>]
<blank><rr> [<comment>]

Пустые строки с комментариями или без них разрешены в любом месте файла.

Определены две управляющие записи: $ORIGIN и $INCLUDE. За $ORIGIN следует доменное имя, и текущее происхождение относительных доменных имен сбрасывается до указанного имени. $INCLUDE вставляет именованный файл в текущий файл и может при желании указать доменное имя, которое устанавливает источник относительного доменного имени для включаемого файла. $INCLUDE также может иметь комментарий. Обратите внимание, что запись $INCLUDE никогда не изменяет относительное происхождение родительского файла, независимо от изменений относительного происхождения, сделанных во включенном файле.

Последние две формы представляют RR. Если запись для RR начинается с пробела, то предполагается, что RR принадлежит последнему указанному владельцу. Если запись RR начинается с <domain-name>, то имя владельца сбрасывается.

<rr> содержимое принимает одну из следующих форм:

[<TTL>] [<class>] <type> <RDATA>
[<class>] [<TTL>] <type> <RDATA>

RR начинается с необязательных полей TTL и класса, за которыми следуют поле типа и RDATA, соответствующее типу и классу. Класс и тип используют стандартную мнемонику, TTL — десятичное целое число. Пропущенные значения класса и TTL по умолчанию являются последними явно указанными значениями. Так как мнемоника типа и класса не пересекаются, синтаксический анализ является уникальным. (Обратите внимание, что этот порядок отличается от порядка, используемого в примерах, и порядка, используемого в фактических RR; данный порядок упрощает анализ и дефолт.)

<domain-name> составляют большую долю данных в главном файле. Метки в доменном имени представлены в виде символьных строк и разделены точками. Соглашения о цитировании позволяют хранить произвольные символы в доменных именах. Доменные имена, оканчивающиеся на точку, называются абсолютными и считаются полными. Доменные имена, которые не заканчиваются точкой, называются относительными; Фактическое имя домена — это конкатенация относительной части с источником, указанным в $ ORIGIN, $ INCLUDE или в качестве аргумента для процедуры загрузки мастер-файла. Относительное имя — это ошибка, когда источник недоступен.

<символьная строка> выражается одним или двумя способами: в виде непрерывного набора символов без внутренних пробелов или в виде строки, начинающейся с «и заканчивающейся на». Внутри строки с разделителями может встречаться любой символ, кроме самого себя, который должен быть заключен в кавычки с помощью \ (обратная косая черта).

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

• из под корня
• @ — Свободно стоящий @ используется для обозначения текущего источника.
• \X — где X — любой символ, отличный от цифры (0-9), используется для цитирования этого символа, так что его специальное значение не применяется. Например, «\.» может использоваться для размещения точечного символа в метке.
• \DDD — где каждый D — это цифра, это октет, соответствующий десятичному числу, описанному DDD. Полученный октет считается текстовым и не проверяется на наличие специального значения.
• () — Скобки используются для группировки данных, которые пересекают границу линии. По сути, окончания строк не распознаются в скобках.
• ; — Точка с запятой используется для начала комментария; остальная часть строки игнорируется.

5.2. Использование мастер-файлов для определения зон

Когда мастер-файл используется для загрузки зоны, операция должна быть отменена, если в мастер-файле обнаружены какие-либо ошибки. Основанием для этого является то, что одна ошибка может иметь серьезные последствия. Например, предположим, что RR, определяющие делегирование, имеют синтаксические ошибки; тогда сервер вернет достоверные ошибки имен для всех имен в подзоне (кроме случая, когда подзона также присутствует на сервере).
Несколько других проверок достоверности, которые должны быть выполнены в дополнение к проверке синтаксически правильности файла:

1. Все RR в файле должны иметь один и тот же класс.
2. Ровно один SOA RR должен присутствовать в верхней части зоны.
3. Если присутствуют делегации и требуется клейкая информация, она должна присутствовать.
4. Информация, представленная за пределами авторитетных узлов в зоне, должна быть связующей информацией, а не результатом возникновения или аналогичной ошибки.

5.3. Пример главного файла

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

Где файл <SUBSYS> ISI-MAILBOXES.TXT:

MOE MB A.ISI.EDU.
LARRY MB A.ISI.EDU.
CURLEY MB A.ISI.EDU.
STOOGES MG MOE
MG LARRY
MG CURLEY

Обратите внимание на использование символа \ в SOA RR для указания почтового ящика ответственного лица «Action.domains@E.ISI.EDU».

6. Реализация сервера имен

6.1. Архитектура

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

6.1.1. Контроль

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

6.1.2. База данных

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

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

Все эти структуры данных могут быть реализованы в идентичном формате древовидной структуры, с различными данными, связанными между узлами в разных частях: в каталоге данные являются указателями на зоны, в то время как в структурах данных зоны и кэша данные будут RR. При разработке структуры дерева разработчик должен понимать, что обработка запросов должна будет проходить по дереву с использованием сравнения меток без учета регистра; и что в реальных данных несколько узлов имеют очень высокий коэффициент ветвления (100-1000 или более), но подавляющее большинство имеют очень низкий коэффициент ветвления (0-1).

Один из способов решения проблемы регистра состоит в том, чтобы хранить метки для каждого узла в двух частях: стандартизированное представление регистра для метки, где все символы ASCII находятся в одном регистре, вместе с битовой маской, которая обозначает, какие символы на самом деле являются другой случай. Разнесение факторов ветвления может быть обработано с использованием простого связанного списка для узла, пока коэффициент ветвления не превысит некоторый порог, и перехода к хеш-структуре после того, как порог будет превышен. В любом случае хеш-структуры, используемые для хранения секций дерева, должны гарантировать, что хеш-функции и процедуры сохраняют соглашения об использовании DNS.

Использование отдельных структур для разных частей базы данных мотивируется несколькими факторами:

• Структура каталога может быть почти статической, и ее нужно менять только тогда, когда системный администратор меняет зоны, поддерживаемые сервером. Эта структура также может использоваться для хранения параметров, используемых для управления операциями обновления.
• Отдельные структуры данных для зон позволяют заменить зону простым изменением указателя в каталоге. Операции обновления зоны могут создать новую структуру и, когда она будет завершена, объединить ее с базой данных с помощью простой замены указателя. Очень важно, чтобы при обновлении зоны запросы не использовали старые и новые данные одновременно.
• При правильных процедурах поиска авторитетные данные в зонах всегда будут «скрываться» и, следовательно, иметь приоритет над кэшированными данными.
• Ошибки в определениях зон, которые вызывают наложение зон и т. Д., Могут привести к ошибочным ответам на запросы, но определение проблемы упрощается, и содержимое одной «плохой» зоны не может повредить другую.
• Поскольку кэш чаще всего обновляется, он наиболее уязвим для повреждения при перезапуске системы. Это может также быть заполнено просроченными данными RR. В любом случае его можно легко отбросить, не нарушая данные зоны.

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

6.1.3. Время

Как данные TTL для RR, так и данные синхронизации для операций обновления зависят от 32-битных таймеров в единицах секунд. Внутри базы данных таймеры обновления и TTL для кэшированных данных концептуально «отсчитывают», в то время как данные в зоне остаются с постоянными TTL.

Рекомендуемая стратегия реализации — хранить время двумя способами: как относительное приращение и как абсолютное время. Один из способов сделать это — использовать положительные 32-разрядные числа для одного типа и отрицательные числа для другого. ОР в зонах используют относительное время; таймеры обновления и данные кэша используют абсолютное время. Абсолютные числа берутся по отношению к некоторому известному источнику и преобразуются в относительные значения при помещении в ответ на запрос. Если абсолютный TTL является отрицательным после преобразования в относительный, то срок действия данных истекает и их следует игнорировать.

6.2. Стандартная обработка запросов

Основной алгоритм стандартной обработки запросов представлен в [RFC-1034].

При обработке запросов с QCLASS = * или каким-либо другим QCLASS, который соответствует нескольким классам, ответ никогда не должен быть достоверным, если только сервер не может гарантировать, что ответ охватывает все классы.

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

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

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

6.3. Обновление зоны и перезагрузка обработки

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

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

6.4. Обратные запросы (необязательно)

Обратные запросы являются необязательной частью DNS. Серверы имен не обязаны поддерживать любые формы обратных запросов. Если сервер имен получает обратный запрос, который он не поддерживает, он возвращает ответ об ошибке с ошибкой «Не реализовано», установленной в заголовке. Хотя поддержка обратных запросов является необязательной, все серверы имен должны по крайней мере возвращать ответ об ошибке.

6.4.1. Содержание обратных запросов и ответов

Обратные запросы обращают обращения, выполняемые стандартными операциями запроса; в то время как стандартный запрос отображает доменное имя на ресурс, обратный запрос отображает ресурс на доменное имя. Например, стандартный запрос может связать имя домена с адресом хоста; соответствующий обратный запрос связывает адрес хоста с доменным именем.

Обратные запросы принимают форму одного RR в разделе ответа сообщения с пустым разделом вопроса. Имя владельца запроса RR и его TTL не имеют значения. Ответ содержит вопросы в разделе вопросов, которые идентифицируют все имена, имеющие запрос RR, КОТОРЫЙ ЗНАЕТ СЕРВЕР ИМЕНИ. Поскольку ни один сервер имен не знает обо всем пространстве доменных имен, ответ никогда не может считаться завершенным. Таким образом, обратные запросы в первую очередь полезны для управления базами данных и отладки. Обратные запросы НЕ являются приемлемым методом сопоставления адресов хостов с именами хостов; используйте вместо этого домен INADDR.ARPA.

Где это возможно, серверы имен должны обеспечивать сравнение без учета регистра для обратных запросов. Таким образом, обратный запрос с запросом MX RR «Venera.isi.edu» должен получить тот же ответ, что и запрос «VENERA.ISI.EDU»; обратный запрос для HINFO RR «IBM-PC UNIX» должен давать тот же результат, что и обратный запрос для «IBM-pc unix». Однако это не может быть гарантировано, поскольку серверы имен могут иметь RR, которые содержат символьные строки, но сервер имен не знает, что данные являются символьными.

Когда сервер имен обрабатывает обратный запрос, он либо возвращает:

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

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

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

6.4.2. Пример обратного запроса и ответа

Общая структура обратного запроса для получения доменного имени, которое соответствует интернет-адресу 10.1.0.52, показана ниже:

Этот запрос запрашивает вопрос, ответом которого является адрес в стиле Интернет 10.1.0.52. Поскольку имя владельца неизвестно, любое доменное имя может использоваться в качестве заполнителя (и игнорируется). Обычно используется единственный октет нуля, обозначающий корень, поскольку он минимизирует длину сообщения. TTL RR не является значимым. Ответ на этот запрос может быть:

Обратите внимание, что QTYPE в ответе на обратный запрос совпадает с полем TYPE в разделе ответа обратного запроса. Ответы на обратные запросы могут содержать несколько вопросов, когда обратные не уникальны. Если раздел вопроса в ответе не является пустым, то RR в разделе ответов изменяется, чтобы соответствовать точной копии RR в первом QNAME.

6.4.3. Обратная обработка запросов

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

Для серверов имен, которые поддерживают несколько зон и большой объем данных, рекомендуемый подход — это отдельная инверсия для каждой зоны. Когда конкретная зона изменяется во время обновления, необходимо переделать только ее инверсии.

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

6.5. Завершение запросов и ответов

Дополнительные услуги завершения, описанные в RFC-882 и RFC-883, были удалены. Переработанные услуги могут стать доступными в будущем.

7. Реализация решателя (резольвера)

Верхние уровни рекомендуемого алгоритма резолвера обсуждаются в [RFC-1034]. В этом разделе обсуждаются детали реализации, исходя из предположения о структуре базы данных, предложенной в разделе реализации сервера имен в этом документе.

7.1. Преобразование пользовательского запроса в запрос

Первый шаг, который предпринимает преобразователь, заключается в преобразовании запроса клиента, заданного в формате, подходящем для локальной ОС, в спецификацию поиска для RR с определенным именем, которые соответствуют определенному QTYPE и QCLASS. Где это возможно, QTYPE и QCLASS должны соответствовать одному типу и одному классу, потому что это значительно упрощает использование кэшированных данных. Причина этого заключается в том, что наличие данных одного типа в кэше не подтверждает существование или отсутствие данных других типов, поэтому единственный способ убедиться в этом — обратиться к авторитетному источнику. Если используется QCLASS = *, то достоверные ответы не будут доступны.

Поскольку распознаватель должен иметь возможность мультиплексировать несколько запросов, если он должен эффективно выполнять свою функцию, каждый ожидающий запрос обычно представлен в некотором блоке информации о состоянии. Этот блок состояния обычно содержит:

— Отметка времени, указывающая время начала запроса. Временная метка используется для определения того, могут ли RR в базе данных использоваться или устарели. Эта временная метка использует формат абсолютного времени, ранее обсуждавшийся для хранения RR в зонах и кэшах. Обратите внимание, что когда TTL RR указывает относительное время, RR должен быть своевременным, поскольку он является частью зоны. Когда RR имеет абсолютное время, оно является частью кеша, и TTL RR сравнивается с отметкой времени для начала запроса.

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

— Какие-то параметры для ограничения объема работ, которые будут выполняться по этому запросу.

Объем работы, которую распознаватель будет выполнять в ответ на запрос клиента, должен быть ограничен для защиты от ошибок в базе данных, таких как циклические ссылки на CNAME, и операционных проблем, таких как сетевой раздел, который не позволяет распознавателю получить доступ к серверам имен, которые он необходимо. В то время как локальные ограничения на количество раз, когда распознаватель будет ретранслировать конкретный запрос на конкретный адрес сервера имен, являются существенными, разрешитель должен иметь глобальный счетчик для каждого запроса, чтобы ограничить работу по одному запросу. Счетчик должен быть установлен на некоторое начальное значение и уменьшаться всякий раз, когда распознаватель выполняет какое-либо действие (тайм-аут повторной передачи, повторная передача и т. Д.). Если счетчик проходит ноль, запрос завершается с временной ошибкой.

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

— Структура данных SLIST обсуждается в [RFC-1034].

Эта структура отслеживает состояние запроса, если он должен ждать ответов от внешних серверов имен.

7.2. Отправка запросов

Как описано в [RFC-1034], основная задача решателя состоит в том, чтобы сформулировать запрос, который будет отвечать на запрос клиента, и направить этот запрос на серверы имен, которые могут предоставить информацию. Как правило, распознаватель будет иметь только очень четкие подсказки о том, какие серверы запрашивать, в форме NS RR, и, возможно, придется пересмотреть запрос в ответ на CNAME или пересмотреть набор серверов имен, запрашиваемых распознавателем в ответ на запрос. ответы делегирования, указывающие распознавателю на серверы имен ближе к нужной информации. В дополнение к информации, запрошенной клиентом, распознаватель, возможно, должен будет обратиться к своим собственным службам, чтобы определить адрес серверов имен, с которыми он хочет связаться.

В любом случае, модель, используемая в этом меморандуме, предполагает, что распознаватель мультиплексирует внимание между несколькими запросами, некоторые из которых клиентские, а некоторые внутренне сгенерированы. Каждый запрос представлен некоторой информацией о состоянии, и требуемое поведение состоит в том, что распознаватель передает запросы на серверы имен таким образом, чтобы максимально увеличить вероятность ответа на запрос, минимизировать время, необходимое для запроса, и избежать чрезмерных передач. Алгоритм ключа использует информацию о состоянии запроса для выбора следующего адреса сервера имен для запроса, а также вычисляет время ожидания, которое вызовет следующее действие, если ответ не поступит. Следующим действием обычно будет передача на какой-либо другой сервер, но это может быть временной ошибкой для клиента.

Средство распознавания всегда начинается со списка имен серверов для запроса (SLIST). В этом списке будут все NS RR, которые соответствуют ближайшей зоне предка, о которой распознаватель знает. Чтобы избежать проблем с запуском, распознаватель должен иметь набор серверов по умолчанию, которые он будет запрашивать, если у него нет текущих NS RR, которые являются подходящими. Затем распознаватель добавляет в SLIST все известные адреса для серверов имен и может запускать параллельные запросы для получения адресов серверов, когда у преобразователя есть имя, но нет адресов для серверов имен.

Чтобы завершить инициализацию SLIST, распознаватель присоединяет любую информацию истории, которую он имеет, к каждому адресу в SLIST. Это обычно будет состоять из некоторого рода взвешенных средних для времени ответа адреса и среднего значения адреса (то есть, как часто адрес вообще отвечал на запрос). Обратите внимание, что эта информация должна храниться для каждого адреса, а не для сервера имен, потому что время отклика и среднее значение для конкретного сервера могут значительно отличаться от адреса к адресу. Также обратите внимание, что эта информация на самом деле относится к паре адрес распознавателя / адрес сервера, поэтому распознаватель с несколькими адресами может захотеть хранить отдельную историю для каждого из своих адресов. Часть этого шага должна касаться адресов, которые не имеют такой истории; в этом случае ожидаемое время приема-передачи 5-10 секунд должно быть наихудшим, с более низкими оценками для той же локальной сети и т. д.

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

Информация устанавливает частичное ранжирование доступных адресов серверов имен. Каждый раз, когда выбирается адрес и состояние должно быть изменено, чтобы предотвратить его выбор снова, пока все другие адреса не будут опробованы. Время ожидания для каждой передачи должно быть на 50-100% больше, чем среднее прогнозируемое значение, чтобы учесть отклонение в ответе.

Некоторые тонкости:

• Средство распознавания может столкнуться с ситуацией, когда адреса для любого из серверов имен, указанных в SLIST, отсутствуют, и где серверы в списке — это именно те серверы, которые обычно используются для поиска своих собственных адресов. Эта ситуация обычно возникает, когда RR связующего адреса имеют меньший TTL, чем делегирование маркировки NS RR, или когда распознаватель кэширует результат поиска NS. Средство распознавания должно обнаружить это условие и возобновить поиск в следующей зоне предка или, альтернативно, в корне.
• Если распознаватель получает ошибку сервера или другой странный ответ от сервера имен, он должен удалить его из SLIST и может пожелать запланировать немедленную передачу на следующий адрес сервера-кандидата.

7.3. Обработка ответов

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

• Проверьте заголовок на разумность. Откажитесь от дейтаграмм, которые являются запросами, когда ожидаются ответы.
• Проанализируйте разделы сообщения и убедитесь, что все RR правильно отформатированы.
• В качестве необязательного шага, проверьте TTL прибывающих данных, ища RR с чрезмерно длинными TTL. Если RR имеет слишком длинный TTL, скажем, больше 1 недели, либо отбросьте весь ответ, либо ограничьте все TTL в ответе 1 неделей.

Следующим шагом является сопоставление ответа с текущим запросом распознавателя. Рекомендуемая стратегия состоит в том, чтобы выполнить предварительное сопоставление, используя поле идентификатора в заголовке домена, а затем проверить, соответствует ли раздел вопроса информации, требуемой в настоящее время. Это требует, чтобы алгоритм передачи выделил несколько битов поля идентификатора домена какому-либо идентификатору запроса. Этот шаг имеет несколько тонкостей:

• Некоторые серверы имен отправляют свои ответы с адресов, отличных от того, который использовался для получения запроса. То есть распознаватель не может полагаться на то, что ответ будет приходить с того же адреса, на который он отправил соответствующий запрос. Эта ошибка сервера имен обычно встречается в системах UNIX.
• Если распознаватель повторно передает конкретный запрос на сервер имен, он должен иметь возможность использовать ответ от любой из передач. Однако, если он использует ответ для выборки времени прохождения сигнала в оба конца для доступа к серверу имен, он должен иметь возможность определить, какая передача соответствует ответу (и сохранить время передачи для каждого исходящего сообщения), или рассчитать только время прохождения в оба конца на основе начальные передачи.
• На сервере имен иногда не будет текущей копии зоны, которую он должен иметь в соответствии с некоторыми NS RR. Средство распознавания должно просто удалить сервер имен из текущего SLIST и продолжить.

7.4. Использование кеша

В общем, мы ожидаем, что распознаватель будет кэшировать все данные, которые он получает в ответах, поскольку он может быть полезен при ответах на будущие запросы клиентов.

Однако существует несколько типов данных, которые не должны кэшироваться:

• — Если для определенного имени владельца доступно несколько записей одного типа, распознаватель должен либо кэшировать их все, либо вообще не кэшировать. Когда ответ усекается, и распознаватель не знает, имеет ли он полный набор, он не должен кэшировать, возможно, частичный набор RR.
• — Кэшированные данные никогда не следует использовать вместо авторитетных данных, поэтому, если это приведет к кешированию, данные не должны кэшироваться.
  — результаты обратного запроса не должны кэшироваться.
• — Результаты стандартных запросов, где QNAME содержит метки «*», если данные могут использоваться для создания подстановочных знаков. Причина заключается в том, что кэш не обязательно содержит существующие RR или информацию о границе зоны, которая необходима для ограничения применения RR с подстановочными знаками.
• — RR данные в ответах сомнительной достоверности. Когда распознаватель получает незапрошенные ответы или данные RR, отличные от запрошенных, он должен отбросить их без кэширования. Основное следствие заключается в том, что все проверки работоспособности пакета должны выполняться перед кэшированием любого из них.

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

8. Поддержка по почте

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

Стандарт кодировки почтовых ящиков предполагает имя почтового ящика в форме «<local-part> @ <mail-domain>». Хотя синтаксис, разрешенный в каждом из этих разделов, существенно различается в разных почтовых сетях, предпочтительный синтаксис для ARPA Internet приведен в [RFC-822].

DNS кодирует <local-part> как одну метку и кодирует <mail-domain> как имя домена. Одна метка из <local-part> предваряется именем домена из <mail-domain>, чтобы сформировать имя домена, соответствующее почтовому ящику. Таким образом почтовый ящик HOSTMASTER @ SRINIC. ARPA отображается в доменное имя HOSTMASTER.SRI-NIC.ARPA. Если <local-part> содержит точки или другие специальные символы, его представление в основном файле потребует использования кавычек с обратной косой чертой, чтобы обеспечить правильное кодирование имени домена. Например, почтовый ящик Action.domains@ISI.EDU будет представлен как Action \ .domains.ISI.EDU.

8.1. Обязательный обмен почтой

Привязка обмена почтой использует часть <mail-domain> спецификации почтового ящика, чтобы определить, куда следует отправлять почту. С <local-part> даже не консультируются. [RFC-974] подробно описывает этот метод, и с ним следует ознакомиться, прежде чем пытаться использовать поддержку обмена почтой.

Одним из преимуществ этого метода является то, что он отделяет именование назначения почты от хостов, используемых для поддержки почтовой службы, за счет другого уровня косвенности в функции поиска. Однако слой добавления должен исключить необходимость в сложных кодировках «%», «!» И т. д. В <local-part>.

Суть метода заключается в том, что <mail-domain> используется в качестве имени домена для поиска записей типа MX, в которых перечислены хосты, желающие принимать почту для <mail-domain>, вместе со значениями предпочтений, которые ранжируют хосты в соответствии с порядком указано администраторами для <mail-domain>.

В этом примечании в качестве примера используется <mail-domain> ISI.EDU вместе с хостами VENERA.ISI.EDU и VAXA.ISI.EDU в качестве почтовых обменов для ISI.EDU. Если бы у почтовика было сообщение для Mockapetris@ISI.EDU, он бы направил его, посмотрев записи MX RR для ISI.EDU. MX RR в ISI.EDU с именами VENERA.ISI.EDU и VAXA.ISI.EDU и запросами типа A могут найти адреса хоста.

8.2. Привязка почтового ящика (экспериментальная)

При привязке к почтовому ящику почтовая программа использует всю спецификацию адресата почты для создания доменного имени. Закодированное имя домена для почтового ящика используется в качестве поля QNAME в запросе QTYPE = MAILB.

Для этого запроса возможны несколько результатов:

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

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

2. Запрос может вернуть RR Mail Rename (MR).

MR RR несет новую спецификацию почтового ящика в поле RDATA. Почтовик должен заменить старый почтовый ящик новым и повторить операцию.

3. Запрос может вернуть MB RR.

RR MB содержит имя домена для хоста в поле RDATA. Почтовик должен доставить сообщение этому хосту по любому применимому протоколу, например, b, SMTP.

4. Запрос может вернуть один или несколько RR почтовой группы (MG).

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

5. Запрос может возвращать RR MB, а также один или несколько RR MG.

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

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

Новые поля могут быть добавлены к этому RR в будущем.

9. Ссылки и библиография

[Dyer 87] S. Dyer, F. Hsu, «Hesiod», Project Athena Technical Plan — Name Service, April 1987, version 1.9. Describes the fundamentals of the Hesiod name service.

[IEN-116] J. Postel, «Internet Name Server», IEN-116, USC/Information Sciences Institute, August 1979. A name service obsoleted by the Domain Name System, but still in use.
[Quarterman 86] J. Quarterman, and J. Hoskins, «Notable Computer Networks», Communications of the ACM, October 1986, volume 29, number 10.

[RFC-742] K. Harrenstien, «NAME/FINGER», RFC 742, Network Information Center, SRI International, December 1977.

[RFC-768] J. Postel, «User Datagram Protocol», RFC 768, USC/Information Sciences Institute, August 1980.

[RFC-793] J. Postel, «Transmission Control Protocol», RFC 793, USC/Information Sciences Institute, September 1981.

[RFC-799] D. Mills, «Internet Name Domains», RFC 799, COMSAT, September 1981. Suggests introduction of a hierarchy in place of a flat name space for the Internet.

[RFC-805] J. Postel, «Computer Mail Meeting Notes», RFC 805, USC/Information Sciences Institute, February 1982.

[RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, «DOD Internet Host Table Specification», RFC 810, Network Information Center, SRI International, March 1982.
Obsolete. See RFC-952.

[RFC-811] K. Harrenstien, V. White, and E. Feinler, «Hostnames Server», RFC 811, Network Information Center, SRI International, March 1982. Obsolete. See RFC-953.

[RFC-812] K. Harrenstien, and V. White, «NICNAME/WHOIS», RFC 812, Network Information Center, SRI International, March 1982.

[RFC-819] Z. Su, and J. Postel, «The Domain Naming Convention for Internet User Applications», RFC 819, Network Information Center, SRI International, August 1982. Early thoughts on the design of the domain system. Current implementation is completely different.

[RFC-821] J. Postel, «Simple Mail Transfer Protocol», RFC 821, USC/Information Sciences Institute, August 1980.

[RFC-830] Z. Su, «A Distributed System for Internet Name Service», RFC 830, Network Information Center, SRI International, October 1982. Early thoughts on the design of the domain system. Current implementation is completely different.

[RFC-882] P. Mockapetris, «Domain names — Concepts and Facilities,» RFC 882, USC/Information Sciences Institute, November 1983. Superceeded by this memo.

[RFC-883] P. Mockapetris, «Domain names — Implementation and Specification,» RFC 883, USC/Information Sciences Institute, November 1983. Superceeded by this memo.

[RFC-920] J. Postel and J. Reynolds, «Domain Requirements», RFC 920, USC/Information Sciences Institute, October 1984. Explains the naming scheme for top level domains.

[RFC-952] K. Harrenstien, M. Stahl, E. Feinler, «DoD Internet Host Table Specification», RFC 952, SRI, October 1985. Specifies the format of HOSTS.TXT, the host/address table replaced by the DNS.

[RFC-953] K. Harrenstien, M. Stahl, E. Feinler, «HOSTNAME Server», RFC 953, SRI, October 1985. This RFC contains the official specification of the hostname server protocol, which is obsoleted by the DNS. This TCP based protocol accesses information stored in the RFC-952 format, and is used to obtain copies of the host table.

[RFC-973] P. Mockapetris, «Domain System Changes and Observations», RFC 973, USC/Information Sciences Institute, January 1986. Describes changes to RFC-882 and RFC-883 and reasons for them.

[RFC-974] C. Partridge, «Mail routing and the domain system», RFC 974, CSNET CIC BBN Labs, January 1986. Describes the transition from HOSTS.TXT based mail addressing to the more powerful MX system used with the domain system.

[RFC-1001] NetBIOS Working Group, «Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and Methods», RFC 1001, March 1987. This RFC and RFC-1002 are a preliminary design for NETBIOS on top of TCP/IP which proposes to base NetBIOS name service on top of the DNS.

[RFC-1002] NetBIOS Working Group, «Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed Specifications», RFC 1002, March 1987.

[RFC-1010] J. Reynolds, and J. Postel, «Assigned Numbers», RFC 1010, USC/Information Sciences Institute, May 1987. Contains socket numbers and mnemonics for host names, operating systems, etc.

[RFC-1031] W. Lazear, «MILNET Name Domain Transition», RFC 1031, November 1987. Describes a plan for converting the MILNET to the DNS.

[RFC-1032] M. Stahl, «Establishing a Domain — Guidelines for Administrators», RFC 1032, November 1987. Describes the registration policies used by the NIC to administer the top level domains and delegate subzones.

[RFC-1033] M. Lottor, «Domain Administrators Operations Guide», RFC 1033, November 1987. A cookbook for domain administrators.

[Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, «The CSNET Name Server», Computer Networks, vol 6, nr 3, July 1982. Describes a name service for CSNET which is independent from the DNS and DNS use in the CSNET.

Индекс

* 13
; 33, 35
<character-string> 35
<domain-name> 34
@ 35
\ 35
A 12
Byte order 8
CH 13
Character case 9
CLASS 11
CNAME 12
Completion 42
CS 13
Hesiod 13
HINFO 12
HS 13
IN 13
IN-ADDR.ARPA domain 22
Inverse queries 40
Mailbox names 47
MB 12
MD 12
MF 12
MG 12
MINFO 12
MINIMUM 20
MR 12
MX 12
NS 12
NULL 12
Port numbers 32
Primary server 5
PTR 12, 18

QCLASS 13
QTYPE 12
RDATA 12
RDLENGTH 11
Secondary server 5
SOA 12
Stub resolvers 7
TCP 32
TXT 12
TYPE 11
UDP 32
WKS 12