Как известно, помимо IP-адресов хосты идентифицируются доменными именами, более легкими для запоминания и отражающими логическое структурирование сети и, часто, функциональное назначение того или иного хоста. Доменное имя состоит из символьных полей, разделенных точками. Крайнее правое поле обозначает домен верхнего уровня, далее, справа налево, следуют поддомены в порядке иерархической вложенности, крайнее левое поле обозначает имя хоста. Например, crypt.iae.nsk.su - хост crypt в домене iae, который находится внутри домена nsk, который в свою очередь находится внутри домена su.
Дерево доменных имен аналогично файловой системе Unix. Корнем дерева является домен "." (точка). Полное - абсолютное или полностью определенное, fully qualified domain name - доменное имя заканчивается точкой, обозначающей корень доменного дерева, но часто эта завершающая точка опускается. Доменами верхнего уровня выступают двухбуквенные национальные домены или трехбуквенные домены com, edu, org, net, gov, int, mil (см. рис 2.1).
Рис 2.1. Дерево доменных имен
Фактически, имя узла в доменном дереве является указателем (индексом) данных, связанных с этим именем. Эти данные могут быть различных типов (IP-адрес, псевдонимы хоста и др.), они сохраняются в базе данных того или иного сервера в виде стандартных записей ресурсов (Standard Resourse Record), формат которых будет рассмотрен ниже в пункте "Файл зоны". Имя домена (например vvsu.ru на рис. 2.1) может выступать также как и имя узла, т.е. быть указателем на связанную с этим именем информацию. Например, такой информацией может быть IP-адрес - в этом случае существует как хост с именем vvsu.ru, с которым можно установить соединение, так и домен vvsu.ru, в котором находятся хосты и, возможно, поддомены.
Сетевое программное обеспечение, маршрутизаторы и другая сетевая аппаратура работают c IP-адресами. Преобразования "доменное имя в IP адрес" ("прямое") выполняются службой DNS путем поиска в доменном дереве нужного имени и извлечения связанной с этим именем информации требуемого типа (IP-адрес). Существует также обратное DNS-преобразование "IP адрес в доменное имя", которое будет рассмотрено ниже в п. "Файл обратной зоны".
Служба DNS представляет собой иерархическую структуру серверов, где каждый сервер отвечает за определенную зону - т.е. свою часть дерева доменных имен, хранит соответствующие базы данных и отвечает на запросы. При этом вышестоящие по дереву серверы имеют информацию об адресах нижестоящих серверов, что обеспечивает связность дерева (говорят, что вышестоящий сервер делегирует нижестоящему серверу полномочия по обслуживанию определенной зоны).
Важно понимать различие между доменом и зоной. Домен - это поддерево дерева доменных имен. Зона - это часть дерева, за которую отвечает тот или иной DNS-сервер. Например, в домене vvsu.ru есть поддомены cts, admin, labs. Администрация DNS-сервера домена vvsu.ru делегировала домены cts и admin серверам соотвествующих подразделений. Таким образом в домене vvsu.ru образовалось 3 зоны: две зоны, совпадающие с доменами cts.vvsu.ru и admin.vvsu.ru, и третья зона, состоящая из оставшейся части домена vvsu.ru, - это поддомен labs.vvsu.ru, хосты, находящиеся непосредственно в vvsu.ru, и сам узел vvsu.ru. Другой пример: домен com состоит из N поддоменов; администрация домена com делегировала отвественность за каждый поддомен соответствующему DNS-серверу. Таким образом в домене com образовалась N+1 зона: N зон, совпадающих с поддоменами, и одна "главная" зона com, в которой содержится только информация о делегировании полномочий для каждого поддомена.
domain vvsu.ru nameserver 212.16.195.98(Естественно, что адрес сервера указывается исключительно в числовом виде.)
Имя хоста устанавливается командой hostname имя_хоста. Иногда, в дополнение к /etc/resolv.conf, требуется также установить имя домена командой domainname имя_домена, а для автоматической установки этого параметра при загрузке системы - внести имя домена в файл /etc/defaultdomain.
Важным файлом в Unix является файл /etc/hosts. В нем в формате
IP-адрес имя_хоста [псевдоним ...] 127.0.0.1 localhost 212.16.195.98 maria mail2перечислены соответствия IP-адресов и имен, которые известны компьютеру непосредственно, без обращения к DNS. В небольших изолированных сетях преобразования "имя в адрес" и "адрес в имя" выполняются без использования DNS, только с помощью файла /etc/hosts. Однако и при использовании DNS файл /etc/hosts обычно содержит строку localhost и строку, содержащую имя и адрес самого хоста. Об использовании этого файла системой Solaris см."IP-адреса. Особенности системы Solaris".
В ОС Solaris такие указания делаются в файле /etc/nsswitch.conf в строке hosts. Формат строки:
hosts: служба [модификатор(ы)] служба ...где служба - служба распознавания имен (dns, files, nis); files означает просмотр /etc/hosts; службы используются в порядке их появления в строке, модификатор задает условие перехода от использования одной службы к другой и имеет вид
событие=действиеПримеры событий:
TRYAGAIN - сервис временно недоступен (например, произошел тайм-аут),
UNAVAIL - сервис недоступен (например, несконфигурирован, отcутствует файл resolv.conf),
SUCCESS - запрос обслужен, данные найдены.
Модификаторов может быть несколько, тогда они следуют друг за другом внутри квадратных скобок через пробел.
Пример строки наиболее распространенной конфигурации
hosts: files [NOTFOUND=continue] dnsозначает, что сначала просматривается файл /etc/hosts, и в случае, если искомые данные не найдены, запрашивается сервер DNS.
В Linux порядок использования служб распознавания имен задается в файле /etc/host.conf, например:
order hosts,bind,nis multi onДля решения этой задачи в других Unix-системах обратитесь к руководству системного администратора.
Если DNS-сервер не может выдать ответ на поступивший запрос (т.е. необходимые данные отсутствуют в его базе и кэше предыдущих запросов), он обращается к одному из корневых серверов (root servers). Рассмотрим на примере, что происходит дальше.
Итак, хост ada.vvsu.ru желает узнать IP-адрес хоста crypt.iae.nsk.su. Ada отправляет запрос своему DNS-серверу 212.16.195.98. возможная схема обработки запроса изображена на рис. 2.3.
Рис.2.2. Схема обработки запроса DNS-сервером
Если у сервера ns.vvsu.ru нет в кэше требуемых данных, он обращается к корневому серверу доменной системы (на самом деле таких серверов 13, все данные на них идентичны), адреса корневых серверов известны каждому DNS-серверу и содержатся в файле root.cache. Корневой сервер, как минимум, может ответить адресом сервера, отвечающего за зону su, однако в нашем случае ему известен адрес сервера, отвечающего за nsk.su (этот адрес мог оказаться в его кэше, но на самом деле корневые серверы отвечают не только за корень доменной системы, но и за большинство доменов верхнего уровня, следовательно, они могут непосредственно делегировать полномочия серверам доменов второго уровня - например, nsk.su). Ns.vvsu.ru повторяет запрос, адресуя его серверу ns.nsk.su, в кэше и базе данных которого нет готового ответа, и ns.nsk.su возвращает адрес сервера, ответственного за iae.nsk.su. Обратившись к этому последнему, ns.vvsu.ru получает IP-адрес хоста crypt.iae.nsk.su, поскольку эти данные хранятся непосредственно в базе данных на iaebox.nsk.su, и возвращает его клиенту на ada.vvsu.ru.
Сервер после передачи полученных данных клиенту кэширует их для дальнейшего возможного использования. Также кэшируются и все дополнительные данные, полученные в процессе обработки запроса - например, при запросе IP-адреса хоста alpha.iae.nsk.su сервер ns.vvsu.ru сразу обратится к iaebox.iae.nsk.su, минуя опрос вышестоящих серверов. Последние версии ПО также могут кэшировать и отрицательные результаты поиска.
Различают рекурсивные и итеративные запросы. При получении рекурсивного запроса сервер должен вернуть либо ответ на запрос, либо сообщение об ошибке; все действия по поиску данных и опросу других серверов сервер берет на себя. При получении итеративного запроса сервер может вместо ответа вернуть адрес другого сервера; предполагается, что сделавший запрос клиент перенаправит это запрос указанному серверу. В примере на рис 2.2 DNS-клиент на хосте ada производит рекурсивный запрос, а сервер ns.vvsu.ru посылает другим серверам итеративные запросы.
Преобразование "доменное имя в IP-адрес" выполняется всякий раз при попытке установления TCP/IP-соединения с хостом, если указано доменное имя этого хоста (так происходит почти всегда при работе пользователя с приложениями Интернет). Некоторые программы выполняют также и обратное DNS-преобразование. Эти операции скрыты от пользователя.
%nslookup www.ibm.com Server: maria.vvsu.ru Address: 212.16.195.98 Name: www.ibm.com Address: 204.146.18.33Вывод программы означает, что был опрошен сервер maria.vvsu.ru (его IP-адрес 212.16.195.98) и получен ответ IP(www.ibm.com) = 204.146.18.33.
Пример обратного преобразования:
%nslookup 204.146.18.33 Server: maria.vvsu.ru Address: 212.16.195.98 Name: www.ibm.com Address: 204.146.18.33Программа nslookup работает также в режиме командной строки. Необходимые команды:
server и lserver отличаются тем, что при смене сервера
командой server адрес нового сервера преобразуется с помощью текущего
сервера, а команда lserver производит то же преобразование с помощью
сервера, установленного для nslookup по умолчанию - "своего" сервера. Это
имеет значение, когда текущий сервер по какой-либо причине не отвечает
на запросы.
>set type=NS >ibm.comозначает запрос списка DNS-серверов, отвечающих (authoritative) за домен ibm.com. (Запрос в этом случае должен состоять из имени домена, а не отдельного хоста.)
Возможные типы:
Задание 2. Выполнить прямое преобразование для указанного преподавателем доменного имени. Обратить внимание на наличие канонического доменного имени и псевдонима (alias). Выполнить обратное преобразование для полученного IP-адреса. Преобразования выполнять путем посылки итеративных запросов, не забудьте указывать абсолютные доменные имена. Выполнить прямое и обратное преобразования для cache.roscredit.ru, объяснить асимметричность.
Задание 3. Получить список хостов указанной преподавателем организации.
Задание 4. Переконфигурировать хост так, чтобы он обращался к другому DNS-серверу своей зоны. Список серверов своей зоны найти.
Задание 5. Если при вызове соединения указывается только имя
хоста без имени домена, то к нему автоматически присоединяется имя своего
домена. Сделать так, чтобы при указании имени хоста "www" (например, "ping
www") производилось соединение с хостом "www.ru", а не "www.vvsu.ru"),
а к любым другим именам по-прежнему добавлялось имя своего домена.
Изменения в базу данных DNS могут быть внесены только на первичном сервере. С точки зрения обслуживания клиентских запросов первичный и вторичные серверы идентичны, все они выдают авторитативные ответы. Рекомендуется, чтобы первичный и вторичные серверы находились в разных сетях - для увеличения надежности обработки запросов на случай, если сеть одного из серверов становится недоступной. Серверы DNS не обязаны находиться в том домене, за который они отвечают.
Примечание. Вторичный сервер необязательно получает данные непосредственно с первичного сервера; источником данных может служить и другой вторичный сервер. В любом случае сервер-источник данных для данного вторичного сервера называется "главным" ("master"). Далее в этом разделе считается, что вторичный сервер получает данные зоны непосредственно с первичного сервера.
Конфигурация и база данных DNS сервера состоит из нескольких файлов (используется пакет BIND - являющийся де-факто стандартом DNS-сервера).
Конфигурационный (загрузочный) файл содержит информацию о всех зонах, для которых DNS-сервер является первичным или вторичным. Помимо имени зоны, в первом случае указывается файл, в котором содержится база данных DNS для данной зоны, во втором - адрес первичного сервера и файл временного хранения базы данных, полученной от первичного сервера. В число зон входят зоны (домены), в которых сервер осуществляет прямой поиск ("имя в адрес"), зоны реверсивного поиска ("адрес в имя", домен *.in-addr.arpa, подробнее см. в п. "Файл обратной зоны") и зона локальной петли (0.0.127.in-addr.arpa, служит для преобразования адреса 127.0.0.1 в имя localhost). Также в конфигурационном файле указывается файл инициализации кэша и каталог, в который помещены все файлы с данными.
тип_сервера зона источник_данныхгде тип_сервера: primary, secondary, cache (каждый сервер кэширует проходящие через него данные), источник_данных: файл - для первичного сервера; первичный сервер и файл временного хранения - для вторичного сервера. Пример файла загрузки для первичного сервера домена vvsu.ru, занимающего сети 212.16.195.0 и 212.16.197.0; этот же сервер служит вторичным для домена vsue.ru, занимающего сеть 212.16.198.0 (строки, начинающиеся с точки с запятой, здесь и далее во всех файлах DNS являются комментариями - кроме файла /etc/named.conf в BIND v.8):
directory /usr/named ; type domain source file cache . root.cache primary vvsu.ru vvsu.hosts primary 195.16.212.IN-ADDR.ARPA vvsu-195.rev primary 197.16.212.IN-ADDR.ARPA vvsu-197.rev primary 0.0.127.IN-ADDR.ARPA local.rev secondary vsue.ru 212.16.198.4 vsue.hosts secondary 198.16.212.IN-ADDR.ARPA 212.16.198.4 vsue-198.revВ файле /usr/named/vvsu.hosts для каждого имени хоста из домена vvsu.ru указан IP-адрес и, возможно, дополнительная информация - см. ниже п. "Файл зоны". В файле /usr/named/vvsu-195.rev для каждого IP-адреса узла из сети 212.16.195.0/24 указано его доменное имя - см. ниже п. "Файл обратной зоны". Аналогично обстоит дело с обратным преобразованием из IP-адресов 212.16.197.0/24. Файл local.rev служит для обратного преобразования адреса 127.0.0.1 в имя localhost.
options { directory "/usr/named"; }; zone "vvsu.ru" { type master; file "vvsu.hosts"; }; zone "195.16.212.IN-ADDR.ARPA" { type master; file "vvsu-195.rev"; }; zone "197.16.212.IN-ADDR.ARPA" { type master; file "vvsu-197.rev"; }; zone "vsue.ru" { type slave; masters { 212.16.198.4; }; file "vsue.hosts"; }; zone "198.16.212.IN-ADDR.ARPA" { type slave; masters { 212.16.198.4; }; file "vsue198.rev"; }; zone "0.0.127.in-addr.arpa" { type master; file "local.rev"; }; zone "." { type hint; file "root.cache"; }; // однострочный комментарий /* многострочный комментарий */ # однострочный комментарийЗамечание. Символ ';' в этом файле не является комментарием.
Ниже, в п. "Дополнительные возможности BIND" будут приведены дополнительные директивы для конфигурационного файла; будет рассматриваться только версия 8.
Файлы баз данных DNS состоят из стандартных записей ресурсов. В общем виде стандартная запись ресурса связывает данные определенного типа с некоторым именем и формируется по шаблону:
имя [время_жизни_записи] IN тип_записи данныеИменем является некоторое доменное имя (необязательно имя физически существующих хоста или домена). Если поле "имя" пусто, то значение этого поля берется из предыдущей записи. Данными может быть, например, IP-адрес хоста, если имя относится к хосту, или DNS-сервер домена, если имя относится к домену, и т.п.
Время жизни записи определяет время хранения информации этой записи в кэше запросившего запись сервера (в секундах) и указывается, только если оно отличается от времени жизни, определенного для всей зоны в записи SOA (см. далее).
Основные типы записей рассмотрены ниже.
Имя: полностью уточненное доменное имя зоны, данные которой содержатся в файле. Полностью уточненное доменное имя оканчивается на точку, далее все доменные имена предполагаются полностью уточненными, если явно не указано иное. Вместо явного указанного доменного имени может стоять символ @, в этом случае имя зоны будет взято из раздела (строки) конфигурационного файла, соответствующего данному файлу зоны.
Данные: доменное имя сервера, email администратора DNS (символ @ заменяется на точку), далее в скобках:
vvsu.ru. IN SOA maria.vvsu.ru. dns.maria.vvsu.ru.( 1997120802 ; Serial 10800 ; Refresh 3 hours 3600 ; Retry 1 hour 3600000 ; Expire 1000 hrs 86400 ); Min 24 hoursNS (Name Server). Указание сервера DNS.
Имя: имя домена.
Данные: доменное имя сервера, обслуживающего данный домен. Указываются как первичные, так и вторичные сервера. Пример:
vvsu.ru. IN NS maria.vvsu.ru. IN NS ints.vtc.ru.MX (Mail Exchanger). Назначение обработчика почты.
Имя: доменное имя (имя хоста, имя домена зоны или любое доменное имя, входящее в обслуживаемую зону).
Данные: приоритет (число) и доменное имя хоста, на который должна отправляться почта, адресованная с указанным доменным именем. Пример:
vvsu.ru. IN MX 10 wildcat.vvsu.ru. IN MX 20 maria.vvsu.ru. specialmail.vvsu.ru IN MX 10 maria.vvsu.ruозначает, что вся почта, адресованная на somebody@vvsu.ru будет отправляться на хост wildcat.vvsu.ru, а в случае невозможности так сделать (обрыв связи и т.п.), почта будет отправлена на maria.vvsu.ru. Также maria будет принимать все почтовые сообщения, адресованные на somebody@specialmail.vvsu.ru. Порядок выбора обработчика почты (в этом контексте также используется термин mail relay) определяется приоритетом: чем меньше число, тем выше приоритет; имеет значение только отношение между числами, а не сами числа. Естественно, на указанных хостах должно быть запущено и должным образом сконфигурировано соответствующее программное обеспечение (см. тему "Электронная почта").
При отсутствии записи MX для какого-либо доменного имени, почта, адресованная с этим доменным именем, будет доставляться непосредственно на хост, имеющий такое имя. Однако, такого хоста может не быть (например, хоста specialmail.vvsu.ru не существует, это просто псевдодомен, используемый в адресах электронной почты для удобства пользования и администрирования), в этом случае почта вернется отправителю с сообщением об ошибке.
A (Address). Определение IP-адреса.
Имя: имя хоста. Если имя не является полностью уточненным (на конце нет точки), то к нему присоединяется доменное имя зоны.
Данные: IP-адрес.
Пример:
gw IN A 212.16.195.1 maria IN A 212.16.195.98 wildcat IN A 212.16.195.4Т.к. имена не полностью уточненные, то к ним добавляется имя зоны vvsu.ru, т.е. эти записи эквивалентны следующим:
gw.vvsu.ru. IN A 212.16.195.1и т.д.
CNAME (Canonical Name). Определение псевдонимов.
Имя: псевдоним (alias) хоста - доменное имя (может быть не полностью уточненное).
Данные: каноническое (настоящее) доменное имя хоста (во всех вышеперечисленных записях используется только каноническое имя).
Пример
www IN CNAME wildcat.vvsu.ru.означает, что www.vvsu.ru - на самом деле wildcat.vvsu.ru. При переносе WWW-сервера на другой компьютер (например, maria) достаточно будет изменить только одну строку в файле зоны, чтобы все существующие ссылки на этот сервер работали правильно:
www IN CNAME maria.vvsu.ru.HINFO (Host Info). Информация о хосте.
Имя: доменное имя хоста (может быть не полностью уточненное).
Данные: два текстовых поля (если несколько слов в одном поле, то поле берется в кавычки). Первое поле интерпретируется как модель компьютера, второе - как тип операционной системы. Запись встречается достаточно редко. Пример:
maria IN HINFO "SPARCstation 1" SolarisПример файла зоны vvsu.ru, содержащей три хоста gw, maria и wildcat, можно получить, собрав воедино все вышеприведенные примеры записей в порядке их следования (и, разумеется, исключив одно из определений псевдонима www).
Технология этого преобразования, использующего специальный домен in-addr.arpa, следующая. Заметим, что всякое DNS-преобразование представляет собой поиск узла в дереве и возврат информации, связанной с этим узлом. Деревом здесь является иерархия доменных имен, причем о смысле и виде того или иного имени не делается никаких предположений (например, имя может не относиться ни к какому физическому хосту, а обозначать некое множество почтовых адресов, как это приведено выше при рассмотрении записи MX).
Заметим далее, что пространство IP-адресов, записанных в десятично-точечной нотации, также представляет собой дерево (точнее, лес из 256 деревьев). Отличие от иерархии доменных имен одно: в доменном имени узлы, более близкие к корню, записываются справа, а в IP-адресе - слева. Иными словами, направление от общего к частному в первом случае справа налево, а во втором - слева направо.
Следовательно, можно взаимно однозначно отобразить пространство IP-адресов на специально образованное поддерево дерева доменных имен. Таким поддеревом является домен in-addr.arpa, в который в качестве поддоменов входят значения старшего октета IP-адреса. В каждом из этих поддоменов вида X.in-addr.arpa, где X=0..255, находится 256 поддоменов следующего уровня, представляющие значения второго справа октета IP-адреса - и так далее. Таким образом, IP-адрес 212.16.195.98 представлен узлом в доменном дереве, имеющем имя 98.195.16.212.in-addr.arpa, а сеть 212.16.195.0 - доменом 195.16.212.in-addr.arpa (см. рис. 2.3).
Рис. 2.3. Прямое и обратное преобразование в системе DNS
Смысл описанной схемы состоит в том, что таким образом обратное DNS-преобразование "адрес в имя" не является каким-то особенным преобразованием, а представляет собой обычное прямое преобразование в одном из поддоменов домена in-addr.arpa, при этом данными для каждого узла (т.е., фактически, IP-адреса) в этом домене выступает собственно доменное имя хоста. Например, данными для объекта 98.195.16.212.in-addr.arpa является строка "maria.vvsu.ru", и для выполнения преобразования IP-адреса 212.16.195.98 в доменное имя сервер DNS выполняет поиск данных для "доменного имени" 98.195.16.212.in-addr.arpa и возвращает полученный результат.
Поиск производится по обычному алгоритму: сначала запрашивается корневой сервер, который, если у него в кэше нет готового ответа, возвращает адрес сервера, отвечающего за in-addr.arpa. Далее сервер in-addr.arpa (при отсутствии готового ответа) возвращает адрес сервера, отвечающего за 212.in-addr.arpa - и так далее. Искомые данные данные находятся на DNS-сервере, отвечающем за зону 195.16.212.in-addr.arpa и хранятся в файле, указанном в /etc/named.boot. Такие данные имеют тип PTR.
Тип записи: PTR (Pointer).
Имя: последний (младший) октет IP-адреса.
Данные: полностью уточненное доменное имя хоста с таким адресом.
Пример:
98 IN PTR maria.vvsu.ru.Ниже приведен пример файла обратной зоны 195.16.212.in-addr.arpa для зоны vvsu.ru (vvsu-195.rev), включающей хосты gw, maria, wildcat.
@ IN SOA maria.vvsu.ru. fire.maria.vvsu.ru. ( ;@ = взять имя зоны из файла named.boot (195.16.212.IN-ADDR.ARPA) 1997120802; Serial 10800 ; Refresh 3 hours 3600 ; Retry 1 hour 3600000 ; Expire 1000 hours 86400 ) ; Minimum 24 hours ; IN NS maria.vvsu.ru. IN NS ns.rosprint.net. 1 IN PTR gw.vvsu.ru. 98 IN PTR maria.vvsu.ru. 4 IN PTR wildcat.vvsu.ru.
@ IN SOA maria.vvsu.ru. fire.maria.vvsu.ru. ( 1997120802; Serial 36000 ; Refresh 10800 ; Retry 3600000 ; Expire 86400 ) ; Minimum ; IN NS maria.vvsu.ru. IN NS ns.rosprint.net. 1 IN PTR localhost.Символ @ в первой строке означает, что имя зоны следует взять из конфигурационного файла (/etc/named.conf) из строки, соответствующей данному файлу, т.е. имя зоны: 0.0.127.IN-ADDR.ARPA.
Этот файл, как и root.cache, одинаков для всех серверов.
При создании подзоны управление соответствующей базой данных делегируется первичному и вторичным серверам нового поддомена из файла зоны вышестоящего домена, например, в зоне vvsu.ru создается подзона sub.vvsu.ru с DNS-серверами ns.sub.vvsu.ru (IP=212.16.196.130, первичный сервер) и maria.vvsu.ru. В файле зоны vvsu.ru должно быть записано:
sub.vvsu.ru. IN NS ns.sub.vvsu.ru. ns.sub.vvsu.ru. IN A 212.16.196.130 sub.vvsu.ru. IN NS maria.vvsu.ru.Заметим, что хотя сервер ns.sub.vvsu.ru уже не находится в зоне "родительского" сервера, тем не менее в базе данных родительского сервера указывается его IP-адрес - иначе возникла бы тупиковая ситуация: для того, чтобы получить данные из зоны sub.vvsu.ru, нужно обратиться к серверу ns.sub.vvsu.ru, но IP-адрес этого сервера хранится как раз в базе данных зоны sub.vvsu.ru. Подобные адресные записи на родительских серверах называются glue records. Если DNS-сервер, отвечающий за sub.vvsu.ru, находится за пределами домена vvsu.ru, то необходимость в glue record отпадает.
Следствие: DNS-сервер должен уведомить сервер вышестоящей зоны при изменении своего IP-адреса.
Важный вопрос - кто производит это делегирование. В данном случае делегирование этой зоны производится сервером, отвечающим за 16.212.in-addr.arpa - очевидно, это не DNS-сервер зоны vvsu.ru, скорее всего, это сервер организации, отвечающей за распределение IP-адресов в этом диапазоне (для выяснения этого вопроса нужно обратиться к провайдеру или в Интернет-регистр - www.ripe.net). А если бы для vvsu.ru была бы выделена сеть 212.16.0.0/16, то DNS-сервер зоны vvsu.ru отвечал бы за 16.212.in-addr.arpa, и он бы тогда и производил делегирование подзоны 196.16.212.in-addr.arpa.
Рассмотрим пример. В домене vvsu.ru создаются поддомены down.vvsu.ru и up.vvsu.ru. Для домена down.vvsu.ru выделена область 212.16.196.0/25, т.е. IP-адреса в диапазоне 212.16.196.0 - 212.16.196.127 адресуют хосты в домене down.vvsu.ru. Для домена up.vvsu.ru выделена область 212.16.196.128/25, т.е. IP-адреса в диапазоне 212.16.196.128 - 212.16.196.255 адресуют хосты в домене up.vvsu.ru.
Получается, что узлы одного домена 196.16.212.in-addr.arpa будут соответствовать уже разным поддоменам в vvsu.ru (см. рис. 2.4). Для осуществления делегирования обратных подзон для down.vvsu.ru и up.vvsu.ru из домена 196.16.212.in-addr.arpa нужно выделить два поддомена, но домен 196.16.212.in-addr.arpa нельзя разделить не поддомены, потому что в нем находятся последние октеты IP-адреса (листья дерева).
Рис. 2.4. Проблема делегирования обратных подзон внутри сети класса С
(Замечание. С точки зрения IP-трафика и маршрутизации хосты из down.vvsu.ru и up.vvsu.ru могут по-прежнему находиться в одной IP-сети. Разделение, производящееся в доменном пространстве, не обязательно соответствует структуре IP-сетей.)
Наиболее рациональный способ решения проблемы делегирования обратных подзон заключается в создании в домене 196.16.212.in-addr.arpa фиктивных промежуточных поддоменов subnet1 и subnet2, с помощью которых можно собрать в одну группу узлы, соответствующие down.vvsu.ru, а в другую - узлы, соответствующие up.vvsu.ru, и произвести делегирование обратных подзон на уровне поддоменов subnet1.196.16.212.in-addr.arpa и subnet2.196.16.212.in-addr.arpa (см. рис 2.5).
Рис. 2.5. Решение проблемы делегирования обратных подзон внутри сети класса С
Создание subnet1 и subnet2 выполняется при помощи записи CNAME для каждого узла (значения последнего октета IP-адреса) в домене 196.16.212.in-addr.arpa. Это большой объем работы, но более рационального варианта не существует; работа выполняется в файле обратной зоны 196.16.212.in-addr.arpa на соответствующем первичном сервере:
1.196.16.212.in-addr.arpa. IN CNAME 1.subnet1.196.16.212.in-addr.arpa. 2.196.16.212.in-addr.arpa. IN CNAME 2.subnet1.196.16.212.in-addr.arpa. ... 127.196.16.212.in-addr.arpa. IN CNAME 127.subnet1.196.16.212.in-addr.arpa. subnet1.196.16.212.in-addr.arpa. IN NS ns.down.vvsu.ru. subnet1.196.16.212.in-addr.arpa. IN NS ns2.down.vvsu.ru. 128.196.16.212.in-addr.arpa. IN CNAME 128.subnet2.196.16.212.in-addr.arpa. 129.196.16.212.in-addr.arpa. IN CNAME 129.subnet2.196.16.212.in-addr.arpa. ... 255.196.16.212.in-addr.arpa. IN CNAME 255.subnet2.196.16.212.in-addr.arpa. subnet2.196.16.212.in-addr.arpa. IN NS ns.up.vvsu.ru. subnet2.196.16.212.in-addr.arpa. IN NS ns2.up.vvsu.ru.В выше приведенном листинге также произведено делегирование - указаны DNS-сервера для подзон subnet1 и subnet2.
Таким образом, при выполнении обратного преобразования адреса 212.16.196.25 DNS-сервер будет сначала искать данные (имя хоста), связанные с узлом 25.196.16.212.in-addr.arpa. Однако, он обнаружит, что 25.196.16.212.in-addr.arpa является псевдонимом, тогда как каноническое имя этого узла - 25.subnet1.196.16.212.in-addr.arpa. Последний который находится в зоне subnet1.196.16.212.in-addr.arpa, обслуживаемой DNS-сервером домена down.vvsu.ru. Аналогично, при выполнении обратного преобразования адреса 212.16.196.200 будет производиться поиск данных, связанных с узлом 200.196.16.212.in-addr.arpa, каноническим именем которого окажется 200.subnet2.196.16.212.in-addr.arpa. Это имя в свою очередь находится в зоне subnet2.196.16.212.in-addr.arpa, обслуживаемой DNS-сервером домена up.vvsu.ru.
В конфигурационном файле сервера ns.down.vvsu.ru для обратной зоны указывается (версия 4):
primary subnet1.196.16.212.in-addr.arpa. filenameверсия 8:
zone "subnet1.196.16.212.in-addr.arpa" { type master; file filename; };Соответственно, в загрузочном файле сервера ns.up.vvsu.ru:
primary subnet2.196.16.212.in-addr.arpa. filenameили
zone "subnet2.196.16.212.in-addr.arpa" { type master; file filename; };где filename - имя файла обратной зоны.
Файлы обратной зоны в созданных поддоменах up и down не содержат никаких специфических для рассматриваемого случая записей и имеют обычную структуру, как описано выше в п. "Файл обратной зоны".
В BIND существует возможность уведомить вторичный сервер о том, что данные на первичном сервере изменились. Для этого первичный сервер посылает вторичному сообщение-запрос специального типа "NOTIFY", получение которого подтверждается вторичным сервером также посылкой специального сообщения. После этого вторичный сервер производит обычную операцию: запрашивает с первичного сервера запись SOA, проверяет серийный номер и, если он увеличился, производит передачу данных зоны. Заметим, что само по себе сообщение "NOTIFY" не является командой на передачу данных, а служит лишь сигналом произвести досрочную проверку того, надо ли обновлять данные.
В BIND-8 механизм уведомления по умолчанию включен. Для его выключения (для всех зон, обслуживаемых сервером) подается директива в разделе options:
options { notify no; };Для запрещения уведомления вторичных серверов какой-то определенной зоны эта директива может быть подана в разделе зоны:
zone "vvsu.ru" { type master; file "vvsu.hosts"; notify no; };
Механизм динамического редактирования базы данных используется, в основном, серверами DHCP. После выдачи динамического IP-адреса DHCP-сервер должен зарегистрировать его в DNS. Функции, формирующие сообщения update, встроены внутрь ПО DHCP-сервера (подробнее см. тему "DHCP").
Программа nsupdate (обычно /usr/sbin/nsupdate) позволяет выполнить динамическое редактирование вручную. Ниже приводится списко команд nsupdate, дающий такде представление о возможностях механизма динамического редактирования.
%nsupdate > prereq yxrrset specialmail.vvsu.ru. mx > update delete specialmail.vvsu.ru. mx > update add specialmail.vvsu.ru. 500 mx 10 maria.vvsu.ru. > update add specialmail.vvsu.ru. 500 mx 50 wildcat.vvsu.ru. >означает: проверить, существуют ли записи MX для specialmail.vvsu.ru, если да - удалить их и добавить новые (условие, задаваемое командой prereq, распространяется на все команды до ввода пустой строки). Пустая строка после ввода команд является указанием программе связаться с сервером и произвести редактирование базы данных зоны.
Для авторизации хостов, с которых может производиться динамическое редактирование, следует в конфигурационном файле указать их с помощью директивы allow-update в разделе зоны, базу данных которой требуется редактировать:
zone "vvsu.ru" { type master; file "vvsu.hosts"; allow-update { 212.16.195.99; 212.16.195.100; }; };По умолчанию динамическое редактирование запрещено.
Для организации работы DNS по схеме с форвардерами требуется указать список форвардеров в разделе options конфигурационного файла (естественно, на серверах, которые форвардерами НЕ являются); для самих форвардеров никаких модификаций не требуется.
options { forwarders {212.16.195.98; 212.16.195.4; }; };Если ни один форвардер не отвечает, сервер произведет обычную обработку запроса. Такое поведение можно запретить - т.е. запретить посылать запросы любым другим серверам, кроме форвардеров:
options { forwarders {212.16.195.98; 212.16.195.4; }; forward-only; };
Список хостов, запросы от которых обслуживаются сервером, устанавливается в конфигурационном файле с помощью директивы allow-query. Эта директива может быть помещена в раздел той или иной зоны, тогда ее действие распространяется на запросы данных этой зоны. Если директива allow-query помещена в раздел options, ее действие распространяется на все запросы, кроме тех зон, что имеют собственную директиву allow-query.
options { allow-query {212.16.195.0/24; 212.16.197.0/24; }; }; zone "up.vvsu.ru" { type slave; file "vvsu.up.hosts"; masters { 212.16.196.130; }; allow-query {212.15.196.128/25 ; }; };Список хостов, на которые разрешено пересылать содержимое баз данных зон, формируется аналогично с помощью директивы allow-transfer. Естественно, что в этот список должны входить вторичные DNS-серверы. (Примечание. Команда nslookup ls имя_домена также вызывает пересылку базы данных зоны.)
options { allow-transfer {212.16.195.98; }; # без маски - значит, адрес хоста }; zone "up.vvsu.ru" { type master; file "vvsu.up.hosts"; allow-transfer {212.15.196.128/25 ; }; };Замечание. Вторичные серверы DNS могут также осуществлять передачу другому хосту базы данных запрошенной зоны. (Например, вторичный сервер может выступать в качестве источника данных для других вторичных серверов.) Поэтому для обеспечения полной секретности при передаче баз данных зон требуется на вторичных серверах, которые никому не должны передавать базу данных, указать allow-transer { none; }:
zone "up.vvsu.ru" { type slave; file "vvsu.up.hosts"; masters { 212.16.196.130; }; allow-transfer {none ; }; };Запрет отправлять запросы DNS-серверу 10.0.0.2:
server 10.0.0.2 { bogus yes; };
if [ -f /usr/sbin/in.named -a -f /etc/named.conf ]; then /usr/sbin/in.named & echo named > /dev/console ; fiПосле внесения изменений в файлы сервера DNS следует послать серверу сигнал прочесть эти файлы заново. Сигналы посылаются командой
kill -SIG PID
где SIG - сокращенное обозначение сигнала, PID - идентификатор процесса named, найти этот PID можно с помощью команды (Solaris):
ps -e | grep namedили (Linux):
ps ax | grep namedСигналы (SIG), понимаемые демоном named:
INT - дамп внутренней базы данных сервера (данные из файлов+ кэш) в файл /var/tmp/named_dump.db.
ABRT - вывод статистики сервера в /var/tmp/named.stats.
USR1 - включить вывод отладочной информации в /var/tmp/named.run. Последующие сигналы USR1 повышают уровень детализации.
USR2 - выключить вывод всей отладочной информации.
WINCH - включить регистрацию всех запросов с помощью стандартного средства syslog с приоритетом LOG_INFO.
Задание 7. Для указанного преподавателем хоста хоста найти зону DNS, к которой он принадлежит; серверы DNS, которые ее обслуживают; временные характеристики взаимодействия первичного и вторичного серверов для этой зоны; хосты, получающие почту для этой зоны и для данного хоста; возможные псевдонимы данного хоста. Получать только авторитативные ответы.
Задание 8. Организовать доменную систему, изображенную на рис. 2.6.
Рис. 2.6. Доменная система для лабораторной работы
Для каждого домена указаны его имя, область занимаемых IP-адресов, первичный (master) и вторичный (slave) серверы. За конфигурацию домена отвечает студент, работающий на первичном сервере этого домена. В каждом домене (кроме cts-class.vvsu.ru) зарегистрировать хосты A и B с IP-адресами в пространсте домена, хост A назначить обработчиком почты, приходящей на имя домена, а хост B - www-сервером домена. Кроме этого в каждом домене (включая cts-class.vvsu.ru) определить имя ns.имя_домена, указывающее не первичный сервер домена. Ограничения на обслуживание запросов и передачу зон не ставить.
С помощью программы nslookup убедиться в корректном функционировании своего домена (опрашивать 3 сервера: свой, вторичный и maria.vvsu.ru). Убедиться, что первичный сервер своего домена обслуживает также запросы о внешних доменных именах (например, www.ibm.com и т.п.).
Задание 9. Используется доменная система, построенная в задании 8. Разрешить динамическое редактирование своей зоны для первичного и вторичного серверов и uran.vvsu.ru. С помощью программы nsupdate добавить хост C с IP-адресами в пространсте домена (предварительно проверив его несуществование). С помощью программы nslookup убедиться, что запись появилась в базе данных (проверить прямое и обратное преобразования). Удалить хост С (предварительно проверив его существование). С помощью программы nslookup убедиться, что запись удалена из базы данных (проверить прямое и обратное преобразования). В домен cts-class.vvsu.ru вставлять хост С с IP-адресом из пространства домена d2.
Задание 10 (доп). Предложить способ делегирования обратной подзоны, в случае когда исходный домен располагается в сети класса А или В 15.1.0.0, а для нового поддомена выделяется область IP-адресов 15.1.200.0 netmask 255.255.248.0.