DNS - ДОМЕННАЯ СЛУЖБА ИМЕН - Об ОС *Nix - Системное администрирование - Каталог статей - Архив документации и мануалов для админов

Вторник, 06.12.2016, 02:49
Приветствую Вас Гость | RSS
Мой сайт
Главная
Регистрация
Вход
Форма входа

Меню сайта

Категории раздела
Об ОС Windows [137]
В категории размещаются статьи, касающщиеся операционных систем от Microsoft.
Об ОС *Nix [198]
В данной категории собраны статьи об ОС семейства Unix/Linux/FreeBSD/...
Справочные материалы [351]
Справка по всему разделу.
Виртуализация и Облака [46]
Networks & Routing [86]
DataBases [22]

Наш опрос
Оцените мой сайт
Всего ответов: 193

Статистика

Онлайн всего: 1
Гостей: 1
Пользователей: 0

Главная » Статьи » Системное администрирование » Об ОС *Nix

DNS - ДОМЕННАЯ СЛУЖБА ИМЕН
Технологии Интернет
Лабораторный практикум
Тема 2. DNS - ДОМЕННАЯ СЛУЖБА ИМЕН
Часть 1. Использование DNS
Служба DNS
Конфигурирование клиента DNS
Другие службы распознавания имен и порядок их использования хостом
Порядок выполнения DNS-запроса
Программа nslookup
Задания по части 1
Часть 2. Конфигурирование сервера DNS
Первичные и вторичные серверы DNS
Конфигурационный файл /etc/named.conf (/etc/named.boot)
Файл root.cache
Файл зоны
Типы стандартных записей ресурсов
Файл обратной зоны
Файл локальной петли
Создание поддомена
Дополнительные возможности BIND
Уведомление об изменении базы данных
Динамические изменения в базе данных
Форвардеры
Вопросы безопасности
Управление работой демона named
Задания по части 2
Литература и ссылки
Cricket Liu, Paul Albitz "DNS and BIND" - O'Reilly, Third Edition, September 1998; ISBN 1-56592-512-2, 502 pages.
Оригинальный сайт BIND в Internet Software Consortium (дистрибутив, документация).
man named, man nsupdate, man nslookup
Используемое ПО:
Unix (Solaris 2.x),
BIND v. 8.2.1 (распространяется свободно).

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

Часть 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).

Рис 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-клиента указываются:
имя хоста,
домен, в котором находится данный хост,
IP-адрес сервера DNS, обслуживающего этот домен.

Получение всех этих данных возможно автоматически - в случае конфигурирования стека TCP/IP с помощью DHCP-сервера (см. тему 3 "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.

Рис.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. (Запрос в этом случае должен состоять из имени домена, а не отдельного хоста.)

Возможные типы:
SOA (Start Of Authority) - заголовок зоны,
NS (Name Server) - сервер DNS,
A (Address) - IP-адрес, если указано доменное имя, или доменное имя, если указан IP-адрес (выбрано по умолчанию),
MX (Mail Exchanger) - обработчик почты,
CNAME (Canonical Name) - каноническое имя,
PTR (Pointer) - запрос по обратной зоне,
ANY - все записи.

Более подробно о типах данных в базе данных 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
Конфигурационный файл /etc/named.conf (/etc/named.boot)
Файл root.cache
Файл зоны
Типы стандартных записей ресурсов
Файл обратной зоны
Файл локальной петли
Создание поддомена
Дополнительные возможности BIND
Уведомление об изменении базы данных
Динамические изменения в базе данных
Форвардеры
Вопросы безопасности
Управление работой демона named
Задания по части 2
Первичные и вторичные серверы 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).

Рис. 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. Однако,

Источник: http://athena.vvsu.ru/inetcourse/labs/dns.html

Категория: Об ОС *Nix | Добавил: admin (19.07.2010)
Просмотров: 1327 | Рейтинг: 0.0/0
Всего комментариев: 0
Имя *:
Email *:
Код *:
Поиск

Друзья сайта
  • Официальный блог
  • Сообщество uCoz
  • FAQ по системе
  • Инструкции для uCoz


  • Copyright MyCorp © 2016