RFC-1034. Система именовния сегментов/областей. Концепция и общая характеристика (DNS). Ноябрь 1987 года (категория: стандарт)

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

 DNS-серверы не нужны для размещения записи “SOA” в блоке

“Авторизация” (“Authority”).

Данное свойство является необязательным (дополнительным), несмотря

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

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

для размещения записей “SOA” во всех авторизованных сообщениях-ответах, а

также не существует DNS-клиентов, требующих кэш-обработки отрицательных

результатов. Тем не менее, те и другие рекомендованы. Все DNS-клиенты и

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

возможность игнорирования записей “SOA”, когда последние представлены в

сообщении-ответе.

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

применение этого свойства. Их идея заключалась в том, что если кэшируемая

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

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

“SOA” зоны, и если в поле “Serial” записи “SOA” не указаны новые данные (то

есть зональная структура не изменялась) с тех пор как эти данные прошли кэш-

обработку, то тогда TTL кэшируемой информации в зоне может быть

переустановлено в соответствии с содержанием специального поля “Minimum”

в записи “SOA”, если значение в этом поле меньше установленного ранее.

Однако такая практика пока еще не рекомендована.

3.3.5. Обслуживание зоны и изменения зональной структуры

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

обслуживание зональной БД, размещенной на всех DNS-серверах, которые

авторизованы для этой зоны. Когда проведены необходимые корректировки, то

тогда они должны быть зарегистрированы на всех DNS-серверах. Несмотря на

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

протокола или с помощью другой быстрой процедуры, наиболее

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

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

Общая модель автоматической реструктуризации (или обновления) зоны

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

старшим в зоне. Все изменения координируются мастер-сервером и обычно

осуществляются путем редактирования мастер-файла зоны. После

редактирования администратор сообщает мастер-серверу о необходимости

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

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

соответствии с установленным интервалом) и получают копии данных о новой

зоне, если какие-либо структурные изменения имели место.

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

поле “Serial” в записи “SOA” для этой зоны. К тому же, если имели место

какие-либо другие изменения, то тогда поле “Serial” в записи “SOA” для этой

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

изменений в зоне. Передача DNS-сообщения может преследовать цель простого

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

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

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

более “свежую” информацию путем сравнения последовательных номеров в

этих DNS-сообщениях. Последовательный номер представляет собой элемент

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

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

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

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

битовом диапазоне (2

≤ N < 2

) возможных значений номеров. На практике,

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

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

максимальным отрицательным 32-битовыми номерами.

Процедура периодической отправки запросов подчиненными DNS-

серверами управляется параметрами, содержащимися в записи “SOA” для этой

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

запросами. Эти параметры следующие:

 “Refresh” — интервал обновления информации;

 “Retry” — интервал для повторной отправки запроса на мастер-сервер;

 “Expire” — интервал времени, после которого уничтожается копия

данных о структуре зоны, хранящаяся в БД подчиненного DNS-

сервера.

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

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

определяемого параметром “Refresh” (в секундах), ожидают следующей

отправки запросов на мастер-сервер с целью получения ответного сообщения с

полем “Serial” в записи “SOA” для своей зоны. Если процедура обновления

данных завершилась безрезультатно, то тогда подчиненный DNS-сервер может

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

интервал времени, который определен параметром “Retry” (в секундах). И

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

сообщения с полем “Serial” в записи “SOA” для своей зоны. Если значение в

поле “Serial” в записи “SOA”, хранящейся в БД подчиненного DNS-сервера,

совпадает с тем, которое было получено в сообщении от мастер-сервера, то это

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

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

определяемый параметром “Refresh”. Если подчиненный DNS-сервер придет к

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

провести проверку поля “Serial” в записи “SOA”, в течение некоторого

интервала времени, определяемого параметром “Expire”, то тогда он должен

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

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

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

ему новых данных о зоне, используя в этом запросе значение “AXFR” для

данной зоны. Ответное сообщение со значением “AXFR” может указывать и на

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

последовательность ответных субсообщений. Первое и последнее

субсообщения должны содержать данные о старшем авторизованном узле зоны.

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

авторизованные и неавторизованные записи. Последовательность

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

данных о структуре зоны. Так как при передаче копии необходимо обеспечить

100%-точность данных, поэтому при передаче ответа со значением “AXFR”

необходимо использовать ТСР-протокол или какой-либо другой протокол

доставки данных, обеспечивающий высокое качество связи.

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

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

другими подчиненными DNS-серверами. Такая стратегия взаимодействия

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

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

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

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

DNS

-КЛИЕНТЫ

4.1. Общие положения

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

выступают в роли интерфейсов между программными комплексами

пользователей и DNS-серверами. В простейшем случае, DNS-клиент принимает

запрос от программы пользователя (например, TELNET, FTP, e-mail) в форме

вызова специальной подпрограммы или системного вызова и т.п., и возвращает

востребованную информацию в необходимой форме, которая совместима с

форматами данных, используемыми локальными IP-узлами.

DNS-клиент размещается на том IP-узле, на котором размещается

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

может (при необходимости обращения к DNS-серверам) размещаться и на

других IP-узлах. Так как DNS-клиенту может понадобиться обращаться к

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

информацией, размещенной в локальной кэш-памяти, интервал времени, в

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

весьма незначительно, от миллисекунд до нескольких секунд.

Очень важной функцией DNS-клиента является то, что он устраняет

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

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

процедуры кэширования предшествующих и наиболее важных результатов

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

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

компьютерами и т.п., являются более эффективными при их использовании,

чем те, которые не распределены.

4.2. Интерфейс между пользователем и DNS -клиентом

4.2.1. Типовые функции

Интерфейс между пользователем и DNS-клиентом (между программными

модулями пользователя и DNS-клиента) зависит от настроек локального IP-

узла, но, как правило, такой интерфейс реализует следующие три функции:

 трансляция имени IP-узла в его сетевой (IP) адрес. Эта функция очень

часто напоминает предшествующую базовую поисковую функцию,

определенную файлом “HOSTS.TXT”. В этом случае имеет место

последовательность символов (имя IP-узла), с помощью которой

запрашивающая сторона хочет получить один или несколько 32-битовых

IP-адресов. В соответствии с DNS-протоколом, такая последовательность

транслируется в запрос данных (записей RRs) типа “А”. Так как DNS-

протокол не сохраняет порядок записей (RRs), данная функция может

изменить порядок приоритетности возвращаемых IP-адресов или может

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

выбранный IP-адрес для пользователя. (Замечание. Рекомендуется

направлять ответ, содержащий несколько IP-адресов. Ответ,

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

когда реализуется базовая поисковая функция, определенная

файлом “HOSTS.TXT”.);

 трансляция сетевого (IP) адреса IP-узла в его имя. Эта функция

напоминает по форме предшествующую функцию, но только в этом

случае имеет место 32-битовый IP-адрес, с помощью которого

запрашивающая сторона хочет получить последовательность символов

(имя IP-узла). Октеты IP-адрес записываются в обратном порядке и

используются как компоненты имени, а после этого дополняются

суффиксом, например, “IN-ADDR.ARPA”. Запрос типа “PTR”

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

узла. Например, запрос основного имени IP-узла (PTR-запрос),

содержащий его IP-адрес “1.2.3.4”, после соответствующего поиска

повлечет за собой ответ, содержащий PTR-запись с DNS-именем

“4.3.2.1.IN-ADDR.ARPA”;

 функция глобального поиска. Эта функция не имела аналогов в

предшествующих вариантах DNS-системы. Она позволяет получить из

DNS-системы произвольную информацию. Запрашивающая сторона

способна направлять различные сообщения (QNAME, QTYPE и QCLASS)

и может получить все записи RRs. Данная функция, как правило,

использует DNS-формат запросов относительно всех данных,

содержащихся в RR-записях, вместо локальных данных, имеющихся в

отдельных узлах. В результате таких запросов будет возвращаться

содержание всех RR-записей (например, TTL), вместо каких-либо

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

Когда DNS-клиент выполнил одну из указанных функций, то тогда

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

результатов:

 одну или несколько записей RRs, содержащих затребованную

информацию. В этом случае DNS-клиент возвращает сообщение-ответ

необходимого формата;

 ошибочное имя (name error — NE). Такое событие может произойти в том

случае, если запрашиваемое DNS-имя не существует;

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

если запрашиваемое DNS-имя существует, но данные соответствующего

типа отсутствуют. Например, если запрашивается сетевой адрес

почтового сервера (IP-узла) с указанием его почтового адреса, то тогда в

ответ будет направлено сообщение об ошибке, так как в RR-записи для

сервера с таким почтовым адресом отсутствует сетевой (IP) адрес.

Необходимо отметить, что функции трансляции DNS-имен и сетевых

адресов IP-узлов могут варьировать ответы об ошибке, используя для этого

только один тип ошибки, но, в принципе, это делать, не рекомендуется. Для

такого варьирования ответов об ошибке существует только одна причина, а

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

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

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

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

прикладных процессов.

4.2.2. Псевдонимы

В момент поступления соответствующего запроса на обработку в

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

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

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

являющееся псевдонимом. DNS-клиент может установить это после того, когда

найдет для этого имени запись (RR) “CNAME”. Если такое событие возможно,

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

сообщение с псевдонимом.

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

запрос на новое имя, если он “натолкнется” на “CNAME”. Однако когда

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

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

именем, содержащимся в запросе. Это допускает отправку запросов, которые

содержат псевдонимы. Например, тип запроса является “CNAME” типом, то

это означает, что пользователь интересуется записью “CNAME” о самом себе, а

не другими записями с этим именем, которое было указано.

Использование псевдонимов может повлечь за собой несколько

специфических ситуаций. Многоуровневые (составные) псевдонимы должны

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

сообщение не должно быть сообщением об ошибке. Псевдонимы с петлевыми

маршрутами и псевдонимы, которые указывают на несуществующие DNS-

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

передаваться как сообщение об ошибке.

4.2.3. Временные сбои и отказы

В меньшей степени, чем окружающий мир, все программные модули

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

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

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

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

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

соответствующем сегменте/области.

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

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

наличии ошибки в системе. Такое состояние DNS-системы вызывает

“раздражение” у пользователей и может нанести ущерб в работе других

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

В период таких негативных событий, возможным решением проблемы

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

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

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

других задач.

4.3. Характеристика DNS -клиента

Прикладные программные модули DNS-клиента используют, как

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

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

рода ошибок, чем на обработку типовых сообщений.

4.3.1. Функционально-усеченные DNS - клиенты

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

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

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

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

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

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

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

организации.

Все, что нужно для такого DNS-клиента, называемого “усеченным”



(“stub resolver”), это только перечень адресов DNS-серверов для того, что

обслуживать рекурсивные запросы. Этот тип DNS-клиента (функционально-

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

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

определять свое место в БД DNS-системы. Пользователь также нуждается в

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

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

рекурсивного обслуживания каких-либо или всех пользователей. Пользователю

понадобится консультация у местного системного администратора с целью

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

Такой тип обслуживания страдает несколькими недостатками. Так как

рекурсивные запросы могут требовать на свою обработку произвольное

количество времени, усеченный DNS-клиент может иметь трудности с

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

связаны как с потерей UDP-пакетов, так и с серверами, вышедшими из строя.

DNS-сервер может просто перейти в режим перезагрузки из-за “слишком

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

повторно-переданные сообщения как новые запросы. Использование ТСР-

протокола может быть ответом на решение этой проблемы, однако, ТСР-



В данном случае, без функции кэширования информации.

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

функционирования IP-узла, подобных тем, которые протекают в реальном

DNS-клиенте.

4.3.2. Ресурсы

Кроме своих собственных ресурсов, DNS-клиент также может иметь

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

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

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

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

здесь термин “локальная информация” предназначен для определения единицы

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

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

данные, если имеют место оба типа таких данных.

Рассматриваемый ниже алгоритм функционирования программного

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

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

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

DNS-клиента:

 “SNAME” — DNS-имя, которое необходимо найти;

 “STYPE” — QTYPE, указанный в запросе для поиска;

 “SCLASS” — QCLASS, указанный в запросе для поиска;

 “SLIST” — структура данных, которая определяет DNS-серверы и зону,

которые DNS-клиент пытается обычно опросить. Эта структура сохраняет

наилучшее текущее решение DNS-клиента относительно DNS-серверов,

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

когда поступившая информация требует изменений текущего решения.

Она включает эквивалент зонального имени, известные DNS-серверы в

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

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

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

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

результат сравнения числа маркеров в корневом имени, так как “SNAME”

имеет такое же число маркеров, и это число имеет место и в имени зоны,

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

“ближайший” DNS-клиент соотносится с “SNAME”;

 “SBELT” (“safety belt” — зона безопасности) — данная структура

полностью совпадает со структурой “SLIST” и начинается с файла

конфигурации, содержащего список DNS-серверов, которые

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

локальной информации о порядке выбора DNS-сервера. Результат

сравнения будет иметь значение “-1”, которое означает, что маркеры,

необходимые для процедуры сравнения, отсутствуют;

 “CACHE” — данная структура сохраняет результаты предшествующих

ответов. Так как DNS-клиенты отвечают за уничтожение старых записей

(RRs), TTL которых истекло, большинство программных реализаций

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

записях (RRs), в абсолютное время, когда RR храниться в кэш-памяти.

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

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

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

поиска, или уничтожают их в течение периодических процедур “чистки”

памяти, занятой старыми записями.

4.3.3. Алгоритм

Высокоуровневый алгоритм обработки включает четыре основные

итерации:

 проверить, является ли ответ носителем локальной информации, и если

да, то тогда вернуть его пользователю;

 найти наилучшие DNS-серверы для запроса;

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

 проанализировать ответ, и тогда:

 если ответ содержит вопрос или сообщение об ошибке в DNS-имени,

то тогда кэшировать данные, а также вернуть их обратно пользователю;

 если ответ содержит ссылки на другие лучшие серверы, то тогда

кэшировать данные об этих ссылках и перейти на вторую итерацию;

 если в ответном сообщении представлено “CNAME” и оно не является

собственно ответом на запрос, то тогда “CNAME” кэшируется,

“SNAME” изменяется на каноническое имя в записи “CNAME” и далее

процесс обработки переходит на первую итерацию алгоритма;

 если в ответном сообщении представлены не функционирующие

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

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

переходит на третью итерацию алгоритма.

На первой итерации ведется поиск запрашиваемых данных в кэш-памяти.

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

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

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

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

обращаться с запросом на авторизованный DNS-сервер. Но такая процедура не

рекомендуется к использованию в режиме “по умолчанию”. Если DNS-клиент

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

целесообразно проверить, представлены ли запрашиваемые данные в

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

авторизованную информацию по сравнению с кэшируемыми данными.

На второй итерации ведется поиск DNS-сервера для обращения к нему

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

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

затем поиск родительского сегмента/области “SNAME”, затем поиск имени

родительского сегмента/области родительского сегмента/области “SNAME”, и

так далее до корневого узла. Таким образом, если “SNAME” было

“Mockapetris.ISI.EDU”, то тогда следующим шагом будет поиск записи о DNS-

сервере, обслуживающего “Mockapetris.ISI.EDU”, затем — “ISI.EDU”, затем —

“EDU” и так далее до корневого узла. Эти записи о DNS-серверах содержат

перечень зональных DNS-серверов, обслуживающих зону с “SNAME” или

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

“SLIST”, устанавливаются их IP-адреса (на основе локальных данных).

Возможен случай, когда IP-адреса не доступны. DNS-клиент, в данном случае,

имеет возможность выбора среди нескольких вариантов дальнейшего

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

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

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

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

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

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

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

принять следующие меры:

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

число параллельных работающих процессов) таким образом, чтобы

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

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

ответов на них с другими прикладными процессами, если даже кто-то не

корректно осуществил отдельные настройки;

 отправить ответ, если это вообще возможно;

 избегать ненужных процедур передачи сообщений;

 доставлять ответ так быстро, насколько это возможно.

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

неудачей, то тогда DNS-клиент обращается к структуре “SBELT”. Смысл

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

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