RFC-1035. Система именования сегментов/областей. Реализация и спецификация (DNS). Ноябрь 1987 года (категория: стандарт)

Подождите немного. Документ загружается.

функции. Если DNS-сервер, который не поддерживает функцию встречных

запросов, получил встречный запрос, то тогда в ответ он посылает сообщение

об ошибке, в заголовке которого указывает “Not Implemented”. Несмотря на то,

что функция встречных запросов является дополнительной, все DNS-серверы

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

сообщение об ошибке.

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

Встречные запросы, по-существу, являются обратной функцией по

отношению к стандартным запросам, то есть если стандартный запрос

отображает DNS-имя в источник, то тогда встречный запрос отображает

источник в DNS-имя. Например, стандартный запрос может связывать DNS-

имя с сетевым адресом сервера, а соответствующий встречный запрос —

сетевой адрес сервера с DNS-именем.

Встречные запросы представляют собой одиночную запись в поле

“Answer” сообщения с пустым полем “Question”. Имя владельца записи,

указанное в запросе, и TTL записей не имеют значения. Ответное сообщение

содержит вопросы в поле “Question”, которые определяют все имена, включая

записи, указанные в запросе, которые “известны” DNS-серверу. Так как DNS-

сервер “не знает” все имена пространства имен сегмента/области, ответное

сообщение никогда не будет полным. Таким образом, встречные запросы в

первую очередь полезны для процедур управления и выявления и устранения

неисправностей. Встречные запросы это неприемлемый способ отображения

сетевых адресов в DNS-имена. Для последней процедуры приемлем только

сегмент “IN-ADDR.ARPA”.

Когда это возможно, DNS-серверы должны осуществлять процедуры

сравнения последовательностей символов на основе безрегистрового способа

проверки. Таким образом, если встречный запрос содержит вопрос

относительно записи “МХ” в сегменте “Venera.isi.edu”, то тогда ответ на него

должен быть таким же, как и при запросе относительно сегмента

“VENERA.ISI.EDU”. И наоборот, если встречный запрос содержит вопрос

относительно записи “HINFO” в “IBM-PC UNIX”, то тогда ответ на него

должен быть таким же, как и при запросе относительно “IBM-pc unix”. Однако

последнее не может быть гарантировано, так как DNS-серверы могут иметь RR-

записи, которые содержат последовательности символов, но DNS-сервер может

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

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

ответов:

 ни одного, одно или несколько DNS-имен для определенного

источника данных в форме “QNAME”, размещенных в поле “Question”;

 сообщение об ошибке, указывающее на то, что DNS-сервер не

обслуживает встречные запросы и не отображает определенный тип

источника записи в DNS-имя.

Когда ответ на встречный запрос содержит одно или несколько DNS-

имен в форме “QNAME”, то тогда имя владельца и TTL RR-записи в поле

“Answer”, которое определяет встречный запрос, изменяются в результате

точного сравнения с RR-записью, обнаруженной в первой записи “QNAME”.

RR-записи, возвращаемые во встречных запросах, не будут кэшироваться

с использованием такого же механизма, который используется при ответах на

стандартные запросы. Существует только одна причина последнего,

заключающаяся в том, что имя может иметь несколько RR-записей одного и

того же типа, но только лишь одна будет иметь место. Например, встречный

запрос относительно одиночного адреса многофункционального внутреннего

сервера может создать впечатление, что имеет место только один сетевой адрес.

5.4.2. Пример встречного запроса и ответа на него

Общий формат встречного запроса относительно DNS-имени, которое

отображается в IP-адрес Internet “10.1.0.52”, представлен на рис. 36.

ПОЛЯ СООБЩЕНИЯ С О Д Е Р Ж А Н И Е П О Л Е Й

Header (заголовок) OPCODE=IQUERY, ID=997

Question (вопрос) <empty>

Answer (ответ) <anyname> A IN 10.1.0.52

Authority (авторизация) <empty>

Additional (дополнение) <empty>

Рис.36. Формат встречного запроса

Этот запрос (рис.36) содержит вопрос с целью получения ответа

относительно IP-адреса Internet “10.1.0.52”. Так как владелец имени не

известен, то тогда может быть использовано любое DNS-имя для обозначения

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

означающий корневой узел, так как он минимизирует размер сообщения. В

данном случае TTL RR-записи значения не имеет. Формат ответа на этот

встречный запрос представлен на рис.37.

(Замечание. Запись “QTYPE” в ответе на встречный запрос будет

точно такой же, как и в субполе “TYPE” поля “Answer” встречного

запроса.)

Ответы на встречные запросы могут содержать несколько вопросов,

когда встречный запрос не является уникальным. Если поле “Question” в ответе

пустое, то тогда RR-запись в поле “Answer” изменяется в соответствии точной

копией RR-записи в первой записи “QNAME”.

ПОЛЯ СООБЩЕНИЯ С О Д Е Р Ж А Н И Е П О Л Е Й

Header (заголовок) OPCODE=RESPONSE, ID=997

Question (вопрос) QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU

Answer (ответ) VENERA.ISI.EDU A IN 10.1.0.52

Authority (авторизация) <empty>

Additional (дополнение) <empty>

Рис.37. Формат ответа на встречный запрос

5.4.3. Обработка встречных запросов

DNS-серверы, которые обслуживают встречные запросы, должны

выполнять соответствующие процедуры на основе исчерпывающего поиска в

своих БД, но такой поиск может стать не реализуемым вследствие роста БД.

Альтернативный подход заключается в инверсии БД в соответствии с

основным принципом поиска.

Для DNS-серверов, которые обслуживают несколько зон и обрабатывают

большие объемы данных, рекомендуется следующий подход: отдельные

преобразования каждой зоны. Когда какая-либо зона изменяется в период

обновления данных, то тогда необходимо проводить инверсию только этой

зоны.

DNS

КЛИЕНТЫ

6.1. Преобразование вопросов пользователей в запросы к DNS -серверам

На первом этапе преобразования вопроса пользователя DNS-клиент

определяет необходимый формат, который подходит для локальной

операционной системы, далее осуществляет формирование списка RR-записей

в соответствии с требуемым DNS-именем, определяющих тип и класс

запрашиваемых данных (“QTYPE” и “QCLASS”). Там, где это возможно,

“QTYPE” и “QCLASS” должны быть одного типа и одного класса, так как это

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

заключается в том, что наличие данных одного типа в кэш-памяти не означает

наличие или отсутствие данных других типов, следовательно, существует

только один способ, который позволяет быть уверенным, что имеет место

авторизованный источник данных. Если используется запись “QCLASS” с

символом замены (“QCLASS=*”), то тогда авторизованные ответы не

допускаются (не возможны).

Так как DNS-клиент должен иметь возможность упорядочения

нескольких вопросов пользователей и если он реализует эту функцию

эффективно, то тогда каждый ожидающий своего решения вопрос обычно

представляется в форме некоего блока данных о состоянии процесса обработки

вопроса. Такой блок данных, как правило, включает:

 метку времени, которая указывает время начала обработки запроса.

Метка времени используется для определения возможности или

невозможности (данные устарели) использования RR-записей,

находящихся в БД. Эта метка времени использует абсолютное время

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

памяти. (Замечание. Если TTL для RR-записей определено как

относительное время, то тогда записи должны обновляться

своевременно, так как они являются частью зоны. Если RR-записи

имеют абсолютное время, то тогда они являются частью записей,

хранящихся в кэш-памяти, а TTL для RR-записей сравнивается с

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

(Замечание. Применение метки времени является наиболее

приоритетной функцией текущего времени, так как она позволяет

размещать RR-записи, имеющие нулевое значение TTL, в кэш-

памяти обычным способом, но до тех пор, пока они используются

в рамках текущего запроса, то есть ровно несколько интервалов

(в секундах) пока происходит загрузка системы, после которой

запрос передается повторно в режиме тайм-аута.)

 определенный вид параметров для ограничения объема работы,

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

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

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

от ошибок данных в БД, таких как циркулярные ссылки на “CNAME”,

и с целью защиты от функциональных сбоев, таких, которые вызваны

структурным делением сети, препятствующим DNS-клиенту

обращаться к необходимым DNS-серверам. Несмотря на то, что

локальное ограничение на количество повторных передач (то есть

сколько раз DNS-клиент будет повторять соответствующий запрос на

соответствующий DNS-сервер относительно IP-адреса) является весьма

существенным параметром, DNS-клиент должен обладать глобальным

счетчиком повторных передач для ограничения объема работы для

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

передач должен быть первоначально установлен на некоторое значение

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

раз, когда DNS-клиент выполняет какое либо действие (повторная

передача с использованием режима тайм-аута, просто повторная

передачи и т.п.). Если счетчик обнулился, то тогда передача запросов

прекращается и в последнем сообщении указывается наличие

временной ошибки.

(Замечание. Если структура DNS-клиента допускает при отправке

одного запроса параллельную отправку еще нескольких запросов

(например, когда необходим доступ на DNS-сервер для отправки

одного запроса, но который “заставляет” параллельного DNS-

клиента осуществлять запросы нескольких адресов DNS-сервера),

то тогда процедура отправки “размноженного” запроса должна

начинаться при небольшом значении счетчика повторных

передач. Это предотвращает возможность начала цепной реакции

по циркулярной передаче ссылок, имеющихся в БД, при

функционировании DNS-клиента.)

 перечень DNS-серверов (данная структура представлена в RFC 1034).

Эта структура данных позволяет сохранить запись состояния

процедуры отправки запроса, если последний должен ожидать

получения ответа от внешних (находящихся за пределами зоны) DNS-

серверов.

6.2. Отправка запросов на DNS - серверы

Главной задачей DNS-клиента является формирование и отправка

запроса, который получит ответ для вопроса пользователя, на DNS-серверы,

способные предоставить необходимую информацию. Как правило, DNS-клиент

должен иметь веские причины для того, чтобы обращаться к DNS-серверам с

запросом, на который они ответят в форме RR-записей “NS”, в противном

случае ему может понадобиться скорректировать запрос, чтобы в ответе

получить записи “CNAME”, или скорректировать перечень DNS-серверов, к

которым обращается DNS-клиент, чтобы в ответе получить указатели на другие

DNS-серверы, являющиеся ближайшими к DNS-клиенту для получения

необходимой информации. Для получения дополнительной информации,

запрашиваемой пользователем, DNS-клиенту может понадобиться обратиться к

своим собственным службам с целью определения адресов DNS-серверов, к

которым DNS-клиент желает обратиться.

В любом случае, предполагается, что DNS-клиент распределяет процесс

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

форме вопросов от пользователя, а другая часть является результатом

внутренних процессов. Каждый вопрос пользователя представляет собой блок

информации о состоянии процесса, и влечет за собой необходимое действие,

которое заключается в том, что DNS-клиент передает запрос на DNS-серверы,

причем таким образом, чтобы максимизировать вероятность получения ответа

на отправленный запрос, минимизировать время обработки запроса и избежать

повторных процедур отправки запроса. Базовый алгоритм использует вопрос с

информацией о состоянии процесса для выбора следующего адреса DNS-

сервера, который будет запрашиваться, а также вычисляет время тайм-аута, по

истечении которого (то есть в случае отсутствия ответного сообщения) будут

предприняты следующие действия или процедуры. Следующим действием, как

правило, становиться очередная попытка повторной передачи запроса, но

только не другой DNS-сервер. Кроме этого, может последовать ответ

пользователю о наличии временной ошибки.

DNS-клиент всегда начинает функционировать с анализа перечня DNS-

серверов (перечень), на которые будет направляться запрос. Этот перечень

будет содержать “NS” записи о всех DNS-серверах, указывающих на

ближайшую родительскую зону, о которой знает DNS-клиент. Для исключения

каких-либо проблем в начальной стадии процесса, DNS-клиент должен иметь

список DNS-серверов в режиме “по умолчанию”, которые он будет опрашивать,

если он не имеет текущих “NS” записей, содержащих адреса необходимых

DNS-серверов. Затем DNS-клиент добавляет в перечень все известные адреса

DNS-серверов, и может начать параллельную рассылку запросов с цель

получения адресов серверов, когда DNS-клиент знает их имена, но не знает их

адресов.

Для завершения комплектования перечня, DNS-клиент добавляет к

каждому адресу в перечне какую бы то ни было известную ему историческую

информацию, связанную с этим адресом. Эта информация, как правило, будет

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

интервала времени, через который поступил ответ, причем каждый интервал

будет закреплен за конкретным адресом, а также данные о “популярности”

DNS-сервера (то есть, как часто DNS-сервер с конкретным адресом отвечал на

все вопросы, помещенные в сообщении-запросе). (Замечание. Эта

информация должна закрепляться именно за каждым адресом, а не за

DNS-сервером, так как время поступления ответа и имя

соответствующего DNS-сервера могут существенно варьироваться от

адреса к адресу. Кроме этого, такая информация, на самом деле,

определяет пару адресов DNS-клиент/DNS-сервер, и поэтому DNS-клиент

с несколькими адресами может предпочесть хранение исторических

данных отдельно для каждого своего адреса.) Часть процедуры завершения

комплектования перечня может быть связана с адресами, которые не имеют

какой-либо предыстории. В таком случае, предполагаемый кольцевой маршрут

прохождения IP-пакета будет составлять 5…10 секунд, что является

наихудшим временем для нижней границы, рассчитанным для ЛВС.

(Замечание. Всякий раз, когда следует перенаправление запроса,

алгоритм функционирования DNS-клиента переукомплектовывает

перечень.)

Наличие информации подразумевает частичную классификацию адресов

доступных DNS-серверов. Каждый раз, когда адрес выбран, состояние процесса

должно быть изменено для того, чтобы этот адрес больше не проверялся до тех

пор, пока не будут апробированы все другие адреса. Время режима тайм-аута

для каждой передачи запроса должно быть на 50…100% больше, чем среднее

прогнозируемое значение, что обеспечит прием ответов с различным временем

задержки.

Некоторые важные замечания:

 DNS-клиент может столкнуться с ситуацией, при которой вообще не

будет ни одного доступного адреса для любого DNS-сервера,

представленного в перечне, и при которой DNS-серверы в перечне

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

их собственных адресов. Такая ситуация обычно встречается тогда,

когда прикрепленные записи с адресами имеют меньшее время TTL,

чем “NS” записи, помеченные для перенаправления запроса, или когда

DNS-клиент сохраняет в кэш-памяти результат поиска “NS”. DNS-

клиент должен обнаруживать такие ситуации и после обнаружения

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

противном случае, в корневом узле;

 если DNS-клиент получает от DNS-сервера сообщение об ошибке или

иной “странный” ответ, он должен удалить этот DNS-сервер из

перечня, может начать незамедлительную передачу запроса по адресу

следующего по порядку DNS-сервера.

6.3. Обработка ответов DNS - серверов

Первым шагом в обработке поступившего ответного сообщения является

попытка синтаксического анализа ответа. Эта процедура включает:

 проверка заголовка на его допустимость. Дейтаграммы, являющиеся

запросами, когда ожидаются ответы, подлежат уничтожению;

 синтаксический анализ полей сообщения, необходимо убедиться, что

все RR-записи сформированы корректно;

 в качестве дополнительной итерации, проверяются значения TTL в

поступивших данных на предмет обнаружения RR-записей с весьма

большими значениями TTL. Если RR-запись обладает весьма большим

значением TTL, превышающим одну неделю, то тогда, либо ответное

сообщение уничтожается полностью, либо все значения TTL в

ответном сообщении ограничиваются одной неделей.

Следующей итерацией является сравнение поступившего ответа с

текущим значением запроса DNS-клиента. В данном случае рекомендуется

следующая стратегия. Вначале необходимо провести предварительное

сравнение идентификаторов в поле “ID” заголовка DNS-сообщения, и затем

сравнить соответствие поля “Question” с информацией, которая запрашивалась.

Это требует, чтобы алгоритм передачи отводил несколько бит в поле “ID”

заголовка DNS-сообщения для размещения идентификатора запроса

определенного вида. Данная итерация включает несколько важных моментов:

 некоторые DNS-серверы передают свои ответы с различными адресами

отправителя, хотя только один из этих адресов использовался для

приема запроса. То есть, DNS-клиент не может быть уверен в том, что

ответ поступит от одного и того же адресата (с одним и тем же

адресом), которому он передал соответствующий запрос. Такая

ситуация типична для UNIX-подобных систем;

 если DNS-клиент повторяет передачу соответствующего запроса на

DNS-сервер, то тогда он должен обладать способностью использовать

ответ, который был получен в результате любой повторной передачи

запрос. Однако если он использует ответ для проверки времени

прохождения кольцевого маршрута с целью доступа к DNS-серверу, то

тогда он должен, либо иметь способность сравнивать только то

сообщение, которое поступило в ответ на определенную повторную

передачу запроса (и хранить время передачи для каждого

отправленного сообщения), либо только вычислять время прохождения

кольцевого маршрута, основываясь только на первичной передаче

запроса;

 DNS-сервер иногда не будет иметь текущей копии зоны, которую он

должен иметь в соответствии с RR-записями “NS”. В такой ситуации

DNS-клиент должен просто удалить такой DNS-сервер из текущего

перечня, и потом продолжить выполнять свои функции.

6.4. Использование кэш - памяти

В общем, считается, что DNS-клиент сохраняет в кэш-памяти все данные,

которые он получил в ответах, так как они могут быть полезны для

последующих ответов на вопросы пользователей. Однако существует

несколько типов данных, которые не должны загружаться в кэш-память:

 когда существует несколько RR-записей одного и того же типа,

принадлежащих одному владельцу с соответствующим DNS-именем,

то тогда DNS-клиент должен, либо хранить в кэш-памяти все эти

записи, либо — ни одной. Когда ответное сообщение является

усеченным, а DNS-клиент не знает о том, что ответ является полным,

то тогда он не должен загружать в кэш-память только часть всех

возможных RR-записей;

 данные, хранящиеся в кэш-памяти, никогда не должны использоваться

как наиболее предпочтительные по отношению к авторизованным

данным, и поэтому, если возможна ситуация при которой кэшируемые

данные будут предпочтительнее, то тогда такие данные не должны

кэшироваться;

 результаты встречных запросов не должны загружаться в кэш-память;

 результаты стандартных запросов, в которых записи “QNAME”

содержат маркеры с символом замещения (“*”), если эти данные могут

использоваться для конструкций с символом замещения. Причина

этого состоит в том, что нет необходимости хранить в кэш-памяти

существующие RR-записи или информацию о границе зоны, которая

необходима для ограничения использования RR-записей с символом

замещения;

 данные в RR-записях ответных сообщений с сомнительной

надежностью. Когда DNS-клиент получает “непрошенные” ответы или

другие данные в RR-записях, отличные от запрашиваемых, он должен

их уничтожать без загрузки в кэш-память. Этот имеет очень большое

значение, так как все “нормальные” проверки сообщений должны

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

кэш-память.

В таком же смысле, когда DNS-клиент имеет совокупность RR-записей

для некоторого DNS-имени в ответе, и хочет загрузить эти RR-записи в кэш-

память, он должен проверить уже загруженные им RR-записи на предмет

совпадения с теми данными, которые он хочет загрузить. В зависимости от

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

либо данным, хранящимся в кэш-памяти, но никогда не должно быть

комбинации этих двух типов данных. Если данные в ответе представляют собой

авторизованные данные в поле “Answer”, то тогда им всегда отдается

предпочтение.

. ОБСЛУЖИВАНИЕ СИСТЕМЫ ЭЛЕКТРОННОЙ ПОЧТЫ

DNS-система определяет стандартное отображение почтовых адресов в

DNS-имена и два метода использования почтовой информации для получения

маршрутных данных для доставки почтовой корреспонденции. Первый метод

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

метод — “соединение между почтовыми ящиками”. Стандартная система

почтовой адресации и организация соединения для обмена почтовой

корреспонденцией являются составными частями официального DNS-

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

сообщений в Internet. “Соединение между почтовыми ящиками” является

экспериментальным методом, который находится в процессе развития и

совершенствования.

Стандартная система почтовой адресации предполагает следующую

форму почтового адреса: “<local-part>@<mail-domain>” (RFC 822).

В DNS-системе “<local-part>” кодируется как одиночный маркер, “<mail-

domain>” как DNS-имя. Одиночный маркер из “<local-part>” предваряет DNS-

имя из “<mail-domain>” и трансформируется в DNS-имя, относящееся к

конкретному почтовому адресу. Например, почтовый адрес

“HOSTMASTER@SRI-NIC.ARPA” отображается в DNS-имя

“HOSTMASTER.SRI-NIC.ARPA”. Если “<local-part>” содержит точки или

другие специальные символы, то тогда они представляются в форме, которая

предусмотрена для кодирования символов в мастер-файлах, то есть будут

использоваться обратные дроби “\” (back slash). Например, почтовый адрес

“Action.domains@ISI.EDU” будет представлен в DNS-системе как

“Action\.domains.ISI.EDU”.

7.1. Установление “ соединения для обмена почтовой корреспонденцией”

Для установления такого соединения используется только “<mail-domain>”

часть почтового адреса (RFC-974), то есть по ней определяется, где расположен

адресат, чтобы туда было направлено почтовое сообщение. К локальной части

почтового адреса (“<local-part>”) даже не обращаются.

Одним из преимуществ этого метода является то, что он отделяет

почтовое имя получателя сообщения (“<local-part>”) от имен почтовых серверов,

которые являются основой электронной почтовой службы, однако ценою

использования другого параллельного процесса, реализующего функцию

поиска. Тем не менее, дополнительный параллельный процесс должен

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

(“%”, “!” и т.п.) при кодировании локальной части почтового адреса (“<local-

part>”).

Сущность метода заключается в том, что “<mail-domain>” используется

как DNS-имя для поиска RR-записей типа “МХ”, в которых содержится

перечень проранжированных администраторами (зоны с этим “<mail-domain>”)

почтовых серверов, обслуживающих зону с этим “<mail-domain>”.

В данном стандарте, “<mail-domain>” “ISI.EDU” используется во многих

примерах совместно с именами серверов “VENERA.ISI.EDU” и

“VAXA.ISI.EDU” как почтовые адреса в форме DNS-имен для сегмента