Рис 2.1. Дерево доменных имен
См. архив на Уране.
В этом разделе изучается работа клиента и сервера DNS, конфигурирование соответствующего программного обеспечения, получение информации из баз данных DNS.
Как известно, помимо 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, в которой содержится только информация о делегировании полномочий для каждого поддомена.
При конфигурировании на хосте стека TCP/IP, кроме указания IP-адреса хоста, создания таблицы маршрутов (в простейшем случае - указания IP-адреса шлюза, т.е. строки default в таблице маршрутов), обычно конфигурируется и клиент DNS. Задача клиента - взаимодействие с DNS-сервером, который будет, по запросу клиента, выполнять описанные выше преобразования. При ручном конфигурировании DNS-клиента указываются:
Получение всех этих данных возможно автоматически - в случае конфигурирования стека TCP/IP с помощью DHCP-сервера, либо их выдает администратор сети.
В MS Windows адрес DNS-сервера, имя домена и имя хоста устанавливаются в настройках сети (выбрать протокол TCP/IP, перейти к его свойствам и выбрать закладку DNS).
В Unix имя домена и адрес DNS-сервера указываются в файле /etc/resolv.conf в формате:
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".
Помимо DNS и файла /etc/hosts существуют и другие службы, выполняющие преобразования "имя в адрес" и "адрес в имя", например, NIS (Network Information Service). В большинстве Unix-систем требуется указать какие службы будут использоваться для распознавания имен и в каком порядке.
В ОС Solaris такие указания делаются в файле /etc/nsswitch.conf в строке hosts. Формат строки:
hosts: служба [модификатор(ы)] служба ...
где служба - служба распознавания имен (dns, files, nis); files означает просмотр /etc/hosts; службы используются в порядке их появления в строке, модификатор задает условие перехода от использования одной службы к другой и имеет вид
событие=действие
Примеры событий:
NOTFOUND - запрос обслужен, данные не найдены,
TRYAGAIN - сервис временно недоступен (например, произошел тайм-аут),
UNAVAIL - сервис недоступен (например, несконфигурирован, отcутствует файл resolv.conf),
SUCCESS - запрос обслужен, данные найдены.
Действия: continue - использовать следующую службу, return - прекратить поиск.
Модификаторов может быть несколько, тогда они следуют друг за другом внутри квадратных скобок через пробел.
Пример строки наиболее распространенной конфигурации
hosts: files [NOTFOUND=continue] dns
означает, что сначала просматривается файл /etc/hosts, и в случае, если искомые данные не найдены, запрашивается сервер DNS.
В Linux порядок использования служб распознавания имен задается в файле /etc/host.conf, например:
order hosts,bind,nis
multi on
Для решения этой задачи в других Unix-системах обратитесь к руководству системного администратора.
При необходимости произвести какое-либо из DNS-преобразований ("адрес в имя", "имя в адрес") хост обращается к своему серверу DNS, адрес которого устанавливается как описано выше. Обращение происходит через протокол UDP на порт 53.
Если 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 (обычно - /usr/sbin/nslookup в Unix)позволяет произвести 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. (Запрос в этом случае должен состоять из имени домена, а не отдельного хоста.)
Возможные типы:
Более подробно о типах данных в базе данных DNS см. часть 2 этой темы "Конфигурирование сервера DNS".
Любой ввод, не являющийся командой, воспринимается как запрос. Перенаправление вывода в файл производится с помощью символа >.
Задание 1. Объяснить и устранить ошибку в конфигурации клиента DNS на своей рабочей станции.
Задание 2. Выполнить прямое преобразование для указанного преподавателем доменного имени. Обратить внимание на наличие канонического доменного имени и псевдонима (alias). Выполнить обратное преобразование для полученного IP-адреса. Преобразования выполнять путем посылки итеративных запросов, не забудьте указывать абсолютные доменные имена. Выполнить прямое и обратное преобразования для cache.roscredit.ru, объяснить асимметричность.
Задание 3. Получить список хостов указанной преподавателем организации.
Задание 4. Переконфигурировать хост так, чтобы он обращался к другому DNS-серверу своей зоны. Список серверов своей зоны найти.
Задание 5. Если при вызове соединения указывается только имя хоста без имени домена, то к нему автоматически присоединяется имя своего домена. Сделать так, чтобы при указании имени хоста "www" (например, "ping www") производилось соединение с хостом "www.ru", а не "www.vvsu.ru"), а к любым другим именам по-прежнему добавлялось имя своего домена.
За каждую зону DNS отвечает не менее двух серверов. Один из них является первичным, primary, остальные - вторичными, secondary. Первичный сервер содержит оригинальные файлы с базой данных DNS для своей зоны. Вторичные серверы получают эти данные по сети от первичного сервера и периодически запрашивают первичный сервер на предмет обновления данных (признаком обновления данных служит увеличение серийного номера в записи SOA - см. ниже). В случае, если данные на первичном сервере обновлены, вторичный сервер запрашивает "передачу зоны" ("zone transfer")- т.е. базы данных требуемой зоны. Передача зоны происходит с помощью протокола TCP, порт 53 (в отличие от запросов, которые направляются на UDP/53).
Изменения в базу данных DNS могут быть внесены только на первичном сервере. С точки зрения обслуживания клиентских запросов первичный и вторичные серверы идентичны, все они выдают авторитативные ответы. Рекомендуется, чтобы первичный и вторичные серверы находились в разных сетях - для увеличения надежности обработки запросов на случай, если сеть одного из серверов становится недоступной. Серверы DNS не обязаны находиться в том домене, за который они отвечают.
Примечание. Вторичный сервер необязательно получает данные непосредственно с первичного сервера; источником данных может служить и другой вторичный сервер. В любом случае сервер-источник данных для данного вторичного сервера называется "главным" ("master"). Далее в этом разделе считается, что вторичный сервер получает данные зоны непосредственно с первичного сервера.
Конфигурация и база данных DNS сервера состоит из нескольких файлов (используется пакет BIND - являющийся де-факто стандартом DNS-сервера).
Конфигурация DNS-сервера описывается в конфигурационном файле /etc/named.conf (BIND v.8). В предыдущей версии 4 этот файл назывался загрузочным и имел имя /etc/named.boot. Форматы директив конфигурации сервера у этих двух версий несовместимы (будут рассмотрены оба формата), но формат файлов баз данных, которым посвящены следующие пункты, один и тот же.
Конфигурационный (загрузочный) файл содержит информацию о всех зонах, для которых DNS-сервер является первичным или вторичным. Помимо имени зоны, в первом случае указывается файл, в котором содержится база данных DNS для данной зоны, во втором - адрес первичного сервера и файл временного хранения базы данных, полученной от первичного сервера. В число зон входят зоны (домены), в которых сервер осуществляет прямой поиск ("имя в адрес"), зоны реверсивного поиска ("адрес в имя", домен *.in-addr.arpa, подробнее см. в п. "Файл обратной зоны") и зона локальной петли (0.0.127.in-addr.arpa, служит для преобразования адреса 127.0.0.1 в имя localhost). Также в конфигурационном файле указывается файл инициализации кэша и каталог, в который помещены все файлы с данными.
Строка загрузочного файла /etc/named.bootв BIND v.4 формируется по принципу:
тип_сервера зона источник_данных
где тип_сервера: 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.
Та же самая конфигурация в BIND v.8 (/etc/named.conf) выглядит:
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.
Файл инициализации кэша root.cache содержит IP-адреса корневых серверов иерархии DNS, с опроса которых начинается процедура поиска информации (если искомая информация не содержится в кэше или в собственной базе данных). Для обновления файла root.cache нужно получить список всех корневых серверов, т.е. серверов, отвечающих за домен "."(точка). Получить такой список можно с помощью программы nslookup (вывод направить в файл, файл отредактировать по формату уже имеющегося root.cache).
Файл зоны (в нашем примере - vvsu.hosts) содержит стандартные записи ресурсов базы данных DNS для преобразования доменных имен хостов в данной зоне в IP-адреса, определения авторитативных DNS-серверов данной зоны, определения хостов-обработчиков почты для доменных имен в данной зоне и др.
Файлы баз данных DNS состоят из стандартных записей ресурсов. В общем виде стандартная запись ресурса связывает данные определенного типа с некоторым именем и формируется по шаблону:
имя [время_жизни_записи] IN тип_записи данные
Именем является некоторое доменное имя (необязательно имя физически существующих хоста или домена). Если поле "имя" пусто, то значение этого поля берется из предыдущей записи. Данными может быть, например, IP-адрес хоста, если имя относится к хосту, или DNS-сервер домена, если имя относится к домену, и т.п.
Время жизни записи определяет время хранения информации этой записи в кэше запросившего запись сервера (в секундах) и указывается, только если оно отличается от времени жизни, определенного для всей зоны в записи SOA (см. далее).
Основные типы записей рассмотрены ниже.
SOA (Start Of Authority). Первая запись в файле.
Имя: полностью уточненное доменное имя зоны, данные которой содержатся в файле. Полностью уточненное доменное имя оканчивается на точку, далее все доменные имена предполагаются полностью уточненными, если явно не указано иное. Вместо явного указанного доменного имени может стоять символ @, в этом случае имя зоны будет взято из раздела (строки) конфигурационного файла, соответствующего данному файлу зоны.
Данные: доменное имя сервера, email администратора DNS (символ @ заменяется на точку), далее в скобках:
Пример записи SOA из файла зоны vvsu.ru:
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 hours
NS (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).
Файл обратной зоны (в нашем примере - named.rev) предназначен для проведения обратного DNS-преобразования, т.е. "IP-адрес в доменное имя".
Технология этого преобразования, использующего специальный домен 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.
Файл и зона локальной петли (loopback) предназначены для преобразования адреса 127.0.0.1 в имя localhost. Поскольку сеть 127.0.0.0 специально зарезервирована для использования в качестве ссылки на свой хост, никакой регистр Интернет этой сетью не распоряжается, следовательно каждый DNS-сервер может быть первичным для зоны 0.0.127.in-addr.arpa. Так как файл (в нашем примере - local.rev) предназначен для проведения обратного DNS-преобразования, то его структура не отличается от приведенной выше:
@ 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-адреса.
Вместе с делегированием подзоны производится и делегирование обратной подзоны - для тех IP-адресов, которые войдут в новый поддомен. Делегирование обратной подзоны является тривиальной операцией только в том случае, когда для нового поддомена выделяется новая IP-сеть типа /8, /16 или /24, т.е. с разделением сеть/хост на границе октета, например для поддомена sub.vvsu.ru выделена сеть 212.16.196.0. В этом случае обратная зона выглядит как 196.16.212.in-addr.arpa и файл для нее создается, как описано выше.
Важный вопрос - кто производит это делегирование. В данном случае делегирование этой зоны производится сервером, отвечающим за 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.
В случае расположения нескольких зон в одной сети класса С делегирование обратной подзоны - нетривиальная задача. В этом случае хосты, IP-адреса которых имеют одинаковые значениями трех старших октетов, будут находиться в различных доменах.
Рассмотрим пример. В домене 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 версии 8.
Обычно для того, чтобы выяснить, не изменились ли данные на первичном сервере, вторичный сервер опрашивает первичный через определенные промежутки времени (см. выше запись типа SOA).
В BIND существует возможность уведомить вторичный сервер о том, что данные на первичном сервере изменились. Для этого первичный сервер посылает вторичному сообщение-запрос специального типа "NOTIFY", получение которого подтверждается вторичным сервером также посылкой специального сообщения. После этого вторичный сервер производит обычную операцию: запрашивает с первичного сервера запись SOA, проверяет серийный номер и, если он увеличился, производит передачу данных зоны. Заметим, что само по себе сообщение "NOTIFY" не является командой на передачу данных, а служит лишь сигналом произвести досрочную проверку того, надо ли обновлять данные.
В BIND-8 механизм уведомления по умолчанию включен. Для его выключения (для всех зон, обслуживаемых сервером) подается директива в разделе options:
options {
notify no;
};
Для запрещения уведомления вторичных серверов какой-то определенной зоны эта директива может быть подана в разделе зоны:
zone "vvsu.ru" {
type master;
file "vvsu.hosts";
notify no;
};
BIND-8 поддерживает механизм динамического редактирования базы данных зоны (dynamic update, RFC 2136) хостами, авторизованными для выполнения этой операции. Это значит, что по запросу от такого хоста записи в базе данных DNS могут создаваться и удаляться "на лету" - естественно, сообщения update должны отправляться серверу, отвечающему (authoritative) за данную зону (при этом неважно, первичный этот сервер или вторичный; вторичные сервера перенаправят сообщение первичному).
Механизм динамического редактирования базы данных используется, в основном, серверами DHCP. После выдачи динамического IP-адреса DHCP-сервер должен зарегистрировать его в DNS. Функции, формирующие сообщения update, встроены внутрь ПО 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-серверов. Для ограничения внешнего трафика, особенно при узком канале мжед сетью организации и Интернет, имеет смысл организовать работу DNS-серверов так, чтобы все DNS-запросы во внешний мир отправлялись через один-два выделенных DNS-сервера. То есть, когда какой-либо из прочих серверов организации получает запрос на DNS-преобразование и не находит требуемой информации в соей локальной базе данных и кэше, он обрабатывает этот запрос не по обычной схеме, рассмотренной выше в п. Порядок выполнения DNS-запроса, а перенаправляет его рекурсивно одному из выделенных серверов - они называются форвардерами. Форвардер производит обычную обработку запроса, если в его кэше или базе данных нет готового ответа, и посылает запросившему серверу окончательный результат поиска. При этом для все организации поддерживается общий кэш, что уменьшает нагрузку на канал связи с внешним миром.
Для организации работы DNS по схеме с форвардерами требуется указать список форвардеров в разделе options конфигурационного файла (естественно, на серверах, которые форвардерами НЕ являются); для самих форвардеров никаких модификаций не требуется.
options {
forwarders {212.16.195.98; 212.16.195.4; };
};
Если ни один форвардер не отвечает, сервер произведет обычную обработку запроса. Такое поведение можно запретить - т.е. запретить посылать запросы любым другим серверам, кроме форвардеров:
options {
forwarders {212.16.195.98; 212.16.195.4; };
forward-only;
};
BIND позволяет ограничить список хостов, запросы которых будут обслуживаться сервером, а также установить список хостов, которым пересылается полное содержимое баз данных. По умолчанию и то, и другое разрешено для всех хостов. Можно также запретить отправлять запросы определенному серверу (серверам), которые присылают неверную информацию.
Список хостов, запросы от которых обслуживаются сервером, устанавливается в конфигурационном файле с помощью директивы 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;
};
Программой, реализующей функции сервера DNS, является демон named, запускаемый из файла /usr/sbin/in.named. Named должен запускаться при загрузке системы, для этого команду его запуска следует внести в файлы загрузки типа /etc/rc* (детали зависят от типа системы, в Solaris это файл /etc/rc2.d/S72inetsvc). Команда запуска named выглядит например:
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:
HUP - перезагрузка файлов базы данных, все файлы должны иметь одинаковый серийный номер, больший, чем предыдущий.
INT - дамп внутренней базы данных сервера (данные из файлов+ кэш) в файл /var/tmp/named_dump.db.
ABRT - вывод статистики сервера в /var/tmp/named.stats.
USR1 - включить вывод отладочной информации в /var/tmp/named.run. Последующие сигналы USR1 повышают уровень детализации.
USR2 - выключить вывод всей отладочной информации.
WINCH - включить регистрацию всех запросов с помощью стандартного средства syslog с приоритетом LOG_INFO.
Задание 6. Обновить файл инициализации кэша. Примечание: данные в файле root.cache, помещенном здесь в качестве примера, существенно устарели.
Задание 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.