The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Каталог документации / Раздел "DNS" (Архив | Для печати)

DNS - ДОМЕННАЯ СЛУЖБА ИМЕН

Владивостокский государственный университет экономики и сервиса

Максим Мамаев

Технологии Интернет
Лабораторный практикум

Тема 2. DNS - ДОМЕННАЯ СЛУЖБА ИМЕН

Часть 1. Использование DNS

Часть 2. Конфигурирование сервера DNS

Литература и ссылки

Используемое ПО:

См. архив на Уране.



Часть 1. Использование DNS

Служба DNS

В этом разделе изучается работа клиента и сервера 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).

Fig 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, в которой содержится только информация о делегировании полномочий для каждого поддомена.

Конфигурирование клиента DNS

При конфигурировании на хосте стека TCP/IP, кроме указания IP-адреса хоста, создания таблицы маршрутов (в простейшем случае - указания IP-адреса шлюза, т.е. строки default в таблице маршрутов), обычно конфигурируется и клиент DNS. Задача клиента - взаимодействие с DNS-сервером, который будет, по запросу клиента, выполнять описанные выше преобразования. При ручном конфигурировании DNS-клиента указываются:

Получение всех этих данных возможно автоматически - в случае конфигурирования стека TCP/IP с помощью DHCP-сервера, либо их выдает администратор сети.

Ручное конфигурирование. Windows.

В MS Windows адрес DNS-сервера, имя домена и имя хоста устанавливаются в настройках сети (выбрать протокол TCP/IP, перейти к его свойствам и выбрать закладку DNS).

Ручное конфигурирование. Unix.

В 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-преобразований ("адрес в имя", "имя в адрес") хост обращается к своему серверу DNS, адрес которого устанавливается как описано выше. Обращение происходит через протокол UDP на порт 53.

Если DNS-сервер не может выдать ответ на поступивший запрос (т.е. необходимые данные отсутствуют в его базе и кэше предыдущих запросов), он обращается к одному из корневых серверов (root servers). Рассмотрим на примере, что происходит дальше.

Итак, хост ada.vvsu.ru желает узнать IP-адрес хоста crypt.iae.nsk.su. Ada отправляет запрос своему DNS-серверу 212.16.195.98. возможная схема обработки запроса изображена на рис. 2.3.

Fig 2.2

Рис.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

Программа 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 [имя_опрашиваемого_сервера]
сменить опрашиваемый DNS сервер, например: server ns.kiae.su. Без аргумента - установить сервер по умолчанию ("свой" сервер). Все запросы (кроме команды lserver - см. след. абзац) отправляются к опрашиваемому серверу, установленному в данный момент. Nslookup позволяет напрямую обращаться с запросами к серверам, непосредственно отвечающим за ту или иную зону. Если же ответ поступил от сервера, не отвечающего за зону, для хоста которой запрашивалась информация (например, данные были извлечены из кэша), такой ответ будет помечен как "non-authoritative answer".

server и lserver отличаются тем, что при смене сервера командой server адрес нового сервера преобразуется с помощью текущего сервера, а команда lserver производит то же преобразование с помощью сервера, установленного для nslookup по умолчанию - "своего" сервера. Это имеет значение, когда текущий сервер по какой-либо причине не отвечает на запросы.

set type=тип_данных
установить запрос данных определенного типа. Например:

          >set type=NS
          >ibm.com
   

означает запрос списка DNS-серверов, отвечающих (authoritative) за домен ibm.com. (Запрос в этом случае должен состоять из имени домена, а не отдельного хоста.)

Возможные типы:

Более подробно о типах данных в базе данных DNS см. часть 2 этой темы "Конфигурирование сервера DNS".

set recurse
отправлять рекурсивные запросы (выбрано по умолчанию).

set norecurse
отправлять итеративные запросы.

set domain=имя_домена
установить имя домена, добавляемое к неполностью определенным доменным именам (по умолчанию берется из /etc/resolv.conf).

set debug
подробно показывать содержимое поступающих ответов.

set nodebug
отменить set debug (отменено по умолчанию).

set d2
подробно показывать содержимое отправляемых запросов.

set nod2
отменить set d2 (отменено по умолчанию).

set all
показать значения всех опций.

ls имя_домена
вывести список хостов указанного домена, например ls vvsu.ru. Предварительно следует переключиться на опрос сервера, отвечающего (authoritative) за данный домен. В целях безопасности некоторые серверы не выполняют эту команду (запрещена пересылка баз данных зоны - см. п. Вопросы безопасности).

help
помощь.

exit
выход.

Любой ввод, не являющийся командой, воспринимается как запрос. Перенаправление вывода в файл производится с помощью символа >.

Задания по части 1

Задание 1. Объяснить и устранить ошибку в конфигурации клиента DNS на своей рабочей станции.

Задание 2. Выполнить прямое преобразование для указанного преподавателем доменного имени. Обратить внимание на наличие канонического доменного имени и псевдонима (alias). Выполнить обратное преобразование для полученного IP-адреса. Преобразования выполнять путем посылки итеративных запросов, не забудьте указывать абсолютные доменные имена. Выполнить прямое и обратное преобразования для cache.roscredit.ru, объяснить асимметричность.

Задание 3. Получить список хостов указанной преподавателем организации.

Задание 4. Переконфигурировать хост так, чтобы он обращался к другому DNS-серверу своей зоны. Список серверов своей зоны найти.

Задание 5. Если при вызове соединения указывается только имя хоста без имени домена, то к нему автоматически присоединяется имя своего домена. Сделать так, чтобы при указании имени хоста "www" (например, "ping www") производилось соединение с хостом "www.ru", а не "www.vvsu.ru"), а к любым другим именам по-прежнему добавлялось имя своего домена.



Часть 2. Конфигурирование сервера DNS

Первичные и вторичные серверы DNS

За каждую зону DNS отвечает не менее двух серверов. Один из них является первичным, primary, остальные - вторичными, secondary. Первичный сервер содержит оригинальные файлы с базой данных DNS для своей зоны. Вторичные серверы получают эти данные по сети от первичного сервера и периодически запрашивают первичный сервер на предмет обновления данных (признаком обновления данных служит увеличение серийного номера в записи SOA - см. ниже). В случае, если данные на первичном сервере обновлены, вторичный сервер запрашивает "передачу зоны" ("zone transfer")- т.е. базы данных требуемой зоны. Передача зоны происходит с помощью протокола TCP, порт 53 (в отличие от запросов, которые направляются на UDP/53).

Изменения в базу данных DNS могут быть внесены только на первичном сервере. С точки зрения обслуживания клиентских запросов первичный и вторичные серверы идентичны, все они выдают авторитативные ответы. Рекомендуется, чтобы первичный и вторичные серверы находились в разных сетях - для увеличения надежности обработки запросов на случай, если сеть одного из серверов становится недоступной. Серверы DNS не обязаны находиться в том домене, за который они отвечают.

Примечание. Вторичный сервер необязательно получает данные непосредственно с первичного сервера; источником данных может служить и другой вторичный сервер. В любом случае сервер-источник данных для данного вторичного сервера называется "главным" ("master"). Далее в этом разделе считается, что вторичный сервер получает данные зоны непосредственно с первичного сервера.

Конфигурация и база данных DNS сервера состоит из нескольких файлов (используется пакет BIND - являющийся де-факто стандартом DNS-сервера).

Файл /etc/named.conf (/etc/named.boot)

Конфигурация 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). Также в конфигурационном файле указывается файл инициализации кэша и каталог, в который помещены все файлы с данными.

Версия 4 (/etc/named.boot)

Строка загрузочного файла /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.

Версия 8 (/etc/named.conf)

Та же самая конфигурация в 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

Файл инициализации кэша 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).

Fig 2.2

Рис. 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-адреса (листья дерева).

Fig. 2.4.

Рис. 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).

Fig. 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

Этот пункт основан на 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, дающий такде представление о возможностях механизма динамического редактирования.

prereq yxrrset доменное_имя тип_записи [данные]
последующие команды update будут выполнены, если существует запись указанного типа для указанного доменного имени [с указанными данными, если они есть]

prereq nxrrset доменное_имя тип_записи [данные]
последующие команды update будут выполнены, если НЕ существует запись указанного типа для указанного доменного имени [с указанными данными, если они есть]

prereq yxdomain доменное_имя
последующие команды update будут выполнены, если указанное доменное имя существует

prereq nxdomain доменное_имя
последующие команды update будут выполнены, если указанное доменное имя НЕ существует

update delete доменное_имя [тип_записи] [данные]
если указано только доменное имя, удаляет всю информацию об этом имени; если указан еще и тип записи, удаляет все записи указанного типа для данного доменного имени; если указаны все 3 параметра удаляет соответствующую запись

update add доменное_имя TTL тип_записи данные
добаляет указанную запись в базу данных зоны; обратите внимание, что параметр TTL (время жизни) обязателен

Пример:

%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;
};

Управление работой демона named

Программой, реализующей функции сервера 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.

Задания по части 2

Задание 6. Обновить файл инициализации кэша. Примечание: данные в файле root.cache, помещенном здесь в качестве примера, существенно устарели.

Задание 7. Для указанного преподавателем хоста хоста найти зону DNS, к которой он принадлежит; серверы DNS, которые ее обслуживают; временные характеристики взаимодействия первичного и вторичного серверов для этой зоны; хосты, получающие почту для этой зоны и для данного хоста; возможные псевдонимы данного хоста. Получать только авторитативные ответы.

Задание 8. Организовать доменную систему, изображенную на рис. 2.6.

Lab task

Рис. 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.




Курс "Технологии Интернет"
Кафедра КТС
Максим Мамаев






Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру