rd_45.134-2000 (524304), страница 14

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

Текст из файла (страница 14)

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

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

Для проверки наличия изменений вторичные серверы проверяют поле SERIAL записи SOA данной зоны. Если в зоне производятся какие-либо изменения, значение поля SERIAL всегда увеличивается. Механизм изменения может быть либо простым увеличением значения, либо может использовать текущую дату.

Параметры периодической переклички вторичных серверов устанавливаются в SOA RR данной зоны. Этими параметрами являются: REFRESH, RETRY и EXPIRE. Когда вторичный сервер загружает новую зону, он ждет REFRESH секунд перед новой проверкой поля SERIAL. Если не обнаружено изменений (значение поля SERIAL - прежнее), вторичный сервер опять ждет REFRESH секунд. В случае, если проверка не может быть произведена, сервер ждет RETRY секунд до повторной проверки. Если вторичному серверу не удалось провести проверку в течение EXPIRE секунд, он должен считать копию зоны устаревшей и уничтожить ее.

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

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

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

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

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

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

Субдомен начинается с метки IN-ADDR.ARPA и имеет подструктуру, соответствующую структуре адресации Internet. Доменные имена могут иметь до 4-х меток в дополнение к IN-ADDR.ARPA. Каждая метка представляет собой один октет адреса IP в формате десятичного целого от 0 до 255 ( с опущенными лидирующими нулями). Адрес узла соответствует имени, в котором присутствуют все 4 метки. Например, узел с адресом 10.2.0.52 будет иметь имя 52.0.2.10.IN-ADDR.ARPA.

Имена с количеством меток менее 4-х соответствуют зоне, выделенной для отдельной сети.

Сетевые номера соответствуют некоторым неконечным узлам, располагающимся на различной глубине домена IN-ADDR.ARPA. Сетевые узлы используются для хранения указателей на первичные узловые имена шлюзов, присоединенных к данной сети. Так как шлюз находится более чем в одной сети, имеются два или более сетевых узлов, указывающих на него. Шлюзы также имеют указатели уровня узла на их полные адреса.

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

Пример:

Домен IN-ADDR.ARPA содержит информацию:

о шлюзе MILNET-GW.ISI.EDU между сетями 10 и 26 с адресами 10.2.0.22 и 26.0.0.103

о шлюзе GW.LCS.MIT.EDU между сетями 10 и 18 с адресами 10.0.0.77 и 18.10.0.4

об узле A.ISI.EDU

об узле MULTICS.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.

Разрешающая система, желающая найти имя узла с адресом 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.

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

5.3. Записи ресурсов

Имя домена идентифицирует узел доменного дерева. В каждом узле имеется набор связанной информации о ресурсе. Этот набор может быть пустым. Набор информации о ресурсе, связанный с отдельным доменным именем содержится в одной или нескольких записях ресурса (RR). Порядок RR в наборе, относящемуся к одному доменному имени, является несущественным.

5.3.1. Общая структура записи ресурса RR

В отдельную запись ресурса RR входят разделы, приведенные в табл. 2.

Таблица 2

Разделы отдельной записи ресурса RR

Поле TTL интерпретируется как предел времени хранения RR в кэше. TTL не применяется для авторитетных данных внутри зоны. Для авторитетных данных внутри зоны применяется специальная временная организация. TTL назначается администратором для зоны, из которой поступают данные. TTL=0 запрещает кэширование данных. Так, записи SOA всегда имеют TTL=0. Если ожидается изменение RR, перед проведением изменения ее TTL может быть уменьшено для сокращения периода несоответствия во время замены. После проведения замены TTL увеличивается обратно до прежнего значения.

Данные в разделе RDATA хранятся как комбинация бинарных строк и имен домена. Имена домена часто используются как указатели на другие данные системы имен.

5.3.2. Формат представления RR в сообщении DNS

5.3.2.1. Формат RR приведен на рис. 3.

0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
NAME
TYPE
CLASS
TTL
RDLENGTH
RDATA

Рисунок. 3. Формат представления RR

Описание значений полей формата RR приведено в табл. 3.

Таблица 3

Описание значений полей формата RR

5.3.2.2. Значения поля TYPE должны соответствовать табл. 4.

Таблица 4

Значения поля TYPE

5.3.2.3. Значения поля CLASS

Значения поля CLASS приведены в табл. 5.

Таблица 5

Характеристики

Список файлов стандарта