Глава 23. Система доменных имен

Глава 23. Система доменных имен

Русский перевод: Вадим Лопатюк

Использование системы доменных имен рассмотрено в предыдущих главах без углубления в детали установки сервера предоставляющего услугу. Эта глава описывает установку простого, маленького сервера системы доменных имен (DNS) в системе NetBSD. Сюда входит краткое рассмотрение и обзор DNS. Более подробную информацию можно получить из каталога происхождения DNS (DNSRD) на http://www.dns.net/dnsrd/.

23.1. DNS: сущность и принципы

DNS это широко используемая в Интернет и других сетях TCP/IP служба имен. Сетевые протоколы, форматы данных и файлов, и другие аспекты DNS в стандартах Интернет, определены в документах RFC, и описаны во множестве других руководств и справочников. DNS представляет собой клиент-серверную архитектуру. Это описание реализации клиента и сервера, но это не часть стандарта. Это она из возможных реализаций доступная для множества платформ.

23.1.1. Служба имен

Служба имен используется для реализации отображения текстовых имен и конфигурационных данных в единой форме. Сервер имен поддерживает это отображение и клиенты просят сервер разрешить имя в присоединяемых данных.

Читатель должен иметь хорошее представление об основах хостов, картах IP адресов и спецификации классов IP адресов, см. Раздел 20.6, «Концепция сервиса имен».

В случае DNS, конфигурационные данные связывают имя в форме стандартной ресурсной записи (RR). Эти текстовые имена соответствуют определенной структурной договоренности.

23.1.2. Пространство имен DNS

DNS представляет собой иерархическое пространтсво имен, совсем как файловая система UNIX, изображаемое как перевернтуое дерево с корнем наверху.

ВЕРХНИЙ-УРОВЕНЬ       .org
           |
СРЕДНИЙ-УРОВЕНЬ      .diverge.org
      _____________________|_____________________
     |      |      |
НИЖНИЙ-УРОВЕНЬ rider.diverge.org samwise.diverge.org wormtongue.diverge.org

Система может также быть, при желании, логически разделена на независимые узлы. Вышеприведенный пример показывает три узла в домене diverge.org, но мы можем разделить даже diverge.org на поддомены, например «rider.net1.diverge.org», «samwise.net2.diverge.org» и «wormtongue.net2.diverge.org»; в этом случае, 2 узла переместятся в «net2.diverge.org» и один в «net1.diverge.org».

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

В отличие от большинства схем имен файловых систем, доменные имена записываются с внутренним именем слева и далее вышестоящие справа весь путь до корневого каталога, если необходимо. Разделитель, используемый при написании доменных имен - точка ".".

Как и пути файловой системы, доменные имена могут быть записаны в абсолютной или относительной форме, хотя здесь есть некоторые различия в деталях. Например, здесь невозможно обратиться к вышестоящему домену с помощью .. как в UNIX каталоге. Многие (но не все) разрешения предлагают стредтсво поиска пути, так частично определенные имена могут разрешиться автоматически в дополнительно указанном поддомене, отличном от собственного домена клиента. Полностью определенные имена с полным путем к корню называются полностю определенными доменными именами (Fully Qualified Domain Names) или FQDN. Определяющей особенностью FQDN является запись с завершающей точкой. Некоторые имена, без завершающей точки, могут считаться относящимися к некоторому другому поддомену. Это редко происходит без злонамеренных целей, но из-за того, что это возможно, FQDN, в некоторых обстоятельствах, требует конфигурационные параметры.

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

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

Записи ресурсов домена хранятся в стандартном формате в текстовом файле ASCII, часто называемом файлом зоны. Часто используются следующие записи ресурсов (есть еще несколько, но они используются не часто или не долго). В некоторых случаях, может быть множество типов RR ассоциированных с одним именем или все одинакового типа.

Общие ресурсные записи DNS

A: Address (адрес)

Эта запись содержит цифровой IP адрес ассоциированный с именем.

CNAME: Canonical Name (каноническое имя)

Эта запись содержит каноническое имя (FQDN с которым ассоциируется запись A) хоста с которым объединяется эта запись. Этот тип записи используется для предоставления псевдонимов имен, для осуществления ссылки на другое имя которому соответствует другая RR. Если имя имеет запись CNAME относящуюся к нему, она образует псевдоним и другие RR не смогут использовать то же самое имя.

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

PTR: Pointer (указатель)

Эта запись содержит текстовое имя. Эти записи объединяют имена встроенные в специальные пути от цифрового IP адреса и используются для предоставления обратного преобразования из IP в текстовое имя. Более подробно это описано в Раздел 23.1.8, «Обратное разрешение».

NS: Name Server (сервер имен)

Запись этого типа используется для делегирования поддеревьев пространства доменных имен другому серверу имен. Запись содержит FQDN сервера имен DNS с информацией о поддомене и связанным с поддоменом. Таким способом устанавливается иерархическая структура DNS. Делегирование более подробно описано в Раздел 23.1.4, «Делегирование».

MX: Mail eXchange (почтовый обменник)

Эта запись содержит FQDN хоста, разрешающего SMTP электронной почты для именованного домена, вместе со значением приоритета, используемого для выбора хоста MX при передаче почты. Это используется для определения других серверов, которые доставляют и буферизируют почту если в данный момент главный MX недоступен. Также это используется для прямой доставки почты на центральный сервер, а не к каждой рабочей станции.

HINFO: Host Information (информация о хосте)

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

TXT: Text (текст)

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

SOA: Start of Authority (начало управления)

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

23.1.4. Делегирование

Использование записей NS, управляет разделением пространства имен DNS между разными точками в дереве посредством делегирования и следующие подразделы в них делегируются вновь. Этот нюанс в различии между доменами и зонами очень важен. Любое имя в DNS называется доменом и срок обновления для этого имени и для всех подчиненных имен за ним един для дерева. Ограничение зоны сужает полномочия и определяется делегированием. Зона начинается с делегирования (или из корня) и охватывает все имена в домене после этой точки, за исключением имен в следующих вложенных делегированиях.

Это важное определение - зона это единичная административная сущность (с одной записью SOA) и все данные, относящиеся к зоне, находятся в одном фале, называемом файлом зоны. Файл зоны может содержать более одного, разделенного точкой, уровня дерева пространства имен, если необходимо, включая точки в именах в этом файле зоны. В порядке упрощения администрирования и предотвращения сильного разрастания файлов зон, почти официально для DNS серверов, используется делегирование самих себя, разбиением домена на отдельные зоны содержащиеся на одном сервере.

23.1.5. Делегирование множеству серверов

Дополнительно, общее (и часто административно необходимое требование) требование - предоставлять информацию о зоне более чем одному серверу имен. Так же часто бывает, что один из этих серверов располагается на некотором расстоянии (в понятиях сетевой топологии) от остальных, так данные об этой зоне могут быть недоступны, в случае потери соединения. Каждый сервер имен должен быть описан в NS записи совместно с именем зоны, находящейся в родительской зоне, на сервере, ответственном за родительский домен. Таким образом поиск по именной иерархии сверху вниз позволяет соединяться с любым из серверов, сужая поиск. Иногда это называют проходом по дереву.

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

23.1.6. Вторичность, кэширование и SOA запись

В порядке поддержки согласованности между этими серверами, один обычно настраивается как первичный (primary) сервер и все административные изменения производятся на этом сервере. Остальные сервера настраиваются как вторичные (secondary) и передают содержание первичных. Эта операционная модель не обязательна, но по некоторым соображениям это бывает необходимо, вместо этого можно использовать несколько первичных, но тогда согласованность должна поддерживаться другим способом. Серверы имен, которые содержат записи RR для определенной зоны, какими бы они не являлись, первичными или вторичными, считаются авторитетными по этой зоне. Сервер DNS может быть авторитетным для нескольких зон.

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

Здесь перечислим некоторые параметры, необходимые для поддержки содержимого вторичных серверов и кэшей. Значения этих параметров для конкретного файла доменной зоны содержатся в записи SOA. Это поля:

Поля записи SOA

Серийный номер

Серийный номер файла зоны. Он должен увеличиваться каждый раз при внесении изменений в данные домена. Когда вторичный сервер хочет проверить необходимость обновления данных, он проверяет серийный номер записи SOA на первичном сервере.

Обновление

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

Повтор

Когда вторичный сервер не может подключиться к первичному по истечении времени обновления (например, если хост отключен), этим значением определяется время задержки, в секундах, между повторными попытками обновления.

Срок

Если повторные попытки обновления не привели к успеху в течение этого времени - вторичный сервер уничтожает свою копию данных файла(ов) зоны и прекращает отвечать на запросы для этого домена. Это позволяет остановить повторение и циркуляцию очень старых и потенциально неточных данных.

TTL (Время жизни)

Это поле определяет время, в секундах, в течение которого запись ресурса этой зоны остается действительной в кэше других серверов. Если данные изменяются, это значение должно быть маленьким. TTL это часто используемая аббревиатура, расшифровываемая как «Time To Live» (время жизни).

23.1.7. Разрешение имен

Клиенты DNS настраиваются на адреса DNS серверов. Обычно, это авторитетные серверы домена, членами которого они являются. Все запросы разрешения имен начинаются с запроса к одному из этих локальных серверов. Запросы DNS бывают двух форм:

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

  • Обычно, обрабатывается итеративный запрос, который поступает второму серверу имен, также ответственному за авторитетные ответы, или к адресам серверов имен (NS записям) перечисленным в их таблицах или кэшах как авторитетные для соответствующих зон. Тогда локальный сервер имен делает итеративный запрос, проходящий вниз по дереву, пока не будет получен авторитетный ответ (положительный или отрицательный) и возвращает его клиенту.

В некоторых конфигурациях, таких как брандмауэры предохраняющие прямые IP соединения между клиентами DNS и внешними серверами имен, или при подключении к остальному миру через низкоскоростное подключение сервер имен может быть настроен с учетом перенаправления на внешний сервер имен, на который локальный сервер имен будет делать запросы как клиент, отправляя полностью рекурсивные запросы и возвращая результат в одном запросе (который затем может быть изменен) перед ответом запрашивающему.

23.1.8. Обратное разрешение

DNS предоставляет разрешение имен в записи ресурсов, также как запись A с IP адресом. Это не предоставляет возможностей полного поиска совпадения в обратном направлении и это не механизм запроса "какое имя относится к соответствующей RR".

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

Это достигается следующим образом:

  • Обычное доменное имя зарегистрированное и определенное исключительно для отображения IP адресов. Доменное имя использует «in-addr.arpa.» в котором отражено историческое начало Интернет в государственной программе исследования прогрессивных проектов министерства обороны США (Advanced Research Projects Agency).

  • Этот домен разделяется и делегируется в соответствии со структурой IP адресов. Часто IP адреса записываются в четырехчисловом с точками виде, где каждый октет из 4-х октетного адреса записан в десятеричной системе и отделен точками. Диапазон IP адреса обычно делегируется из самой левой части адреса и часто очень небольшой. Таким образом, чтобы позволить простое делегирование обратного просмотра домена, все происходит наоборот когда используется иерархическое пространство имен DNS, в котором домены более высокого уровня находятся в правой части имени.

  • Каждый байт IP адреса записывается как текст ASCII, представляющий цифры в десятеричной системе, с обратным порядком октетов, разделенных точками и добавленным в конце доменным именем in-addr.arpa.. Например, чтобы описать имя хоста в сети, который имеет IP адрес 11.22.33.44 согласно этому алгоритму получится «44.33.22.11.in-addr.arpa.», что является правильным, структурированным доменным именем. Обычно сервис имен должен отправлять запрос серверу имен о PTR записи присвоенной сгенерированному имени.

  • Если запись PTR найдена она должна содержать FQDN хоста.

Одно последствие этого - то, что могут быть получены несовпадающие данные. Разрешение имени в запись A и последующее разрешение имени по адресу из записи а в PTR запись, может дать другой результат PTR записи, которая содержит оригинальное имя. Это не ограничение DNS, «обратное» отображение должно совпадать с «прямым» отображением. Это свойство используется в некоторых ситуациях, особенно когда требуется присвоить более одного имени записи A относящейся к одному IP адресу.

В то время как нет такого ограничения в пределах DNS, некоторые прикладные программы сервера или сетевые библиотеки все равно отклонят подключения от хостов, которые не проходят следующий тест:

  • сотояние информации вложенной во входящем соединении, включая IP источника запроса.

  • проверка PTR правильно возвращает FQDN хоста создающего соединение.

  • проверка A возвращенного имени проходит удачно и соединение разрывается если IP адрес источника не перечислен в полученных записях A.

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

23.2. Файлы DNS

Теперь давайте посмотрим на настройку небольшой сети с DNS. Мы продолжим использовать примеры описанные в Глава 21, Практическая настройка TCP/IP в NetBSD, т.е. мы имеем:

  • Наша сеть IP корректно работает

  • Наш IPNAT корректно работает

  • На данный момент хосты используют DNS предоставленный провайдером

Наш сервер имен будет на хосте «strider», на котором также запущен IPNAT, и наши два клиента используют "strider" как шлюз. В действительности не важно какой тип интерфйса у «strider», но аргумента ради, мы говорим об удаленном подключении 56k.

Так, перед тем как что-либо сделать, давайте посмотрим наш /etc/hosts файл на "strider" на котором ранее была настроена альтернатива DNS.

Пример 23.1. файл /etc/hosts на strider

127.0.0.1  localhost
192.168.1.1  strider
192.168.1.2  samwise sam
192.168.1.3  wormtongue worm

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

Следующее соглашение, мы хотим настроить этот домен как diverge.org и этот домен будет известен только в нашей локальной сети и недоступен извне. Полная регистрация IP адреса сервера имен требует, кроме прочего, статического IP. Что влечет за собой административные осложнения, которые здесь не рассматриваются.

NetBSD предоставляет Вам набор конфигурационных файлов, используемых для настройки DNS. Они находятся в каталоге /etc/namedb. Я настоятельно рекомендую сделать резервную копию этого каталога на всякий случай.

По умолчанию каталог содержит следующие файлы:

  • named.conf

  • localhost

  • 127

  • loopback.v6

  • root.cache

В этом разделе Вы увидите модифицированные версии этих файлов.

Замечание

В примерах этой главы используется BIND версии 8, тем не менее, нужно отметить, что формат базы данных имен и других конфигурационных файлов 100% совместим между различными версиями. Единственное отличие в том, что данные «$TTL» более не обязательны.

23.2.1. /etc/namedb/named.conf

Первый файл, который мы будем смотреть это /etc/namedb/named.conf. Это конфигурационный файл bind (легко запоминающееся имя). Настраивает систему, и как мы увидим, достаточно прост. Сначала нужно сделать чтоб он выглядел примерно так:

options {
  directory "/etc/namedb";
  allow-transfer { 192.168.1.0/24; };
  allow-query { 192.168.1.0/24; };
  listen-on port 53 { 192.168.1.1; };
};

zone "localhost" {
 type master;
 notify no;
 file "localhost";
};

zone "127.IN-ADDR.ARPA" {
 type master;
 notify no;
 file "127";
};

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" {
 type master;
 file "loopback.v6";
};

zone "diverge.org" {
 type master;
 notify no;
 file "diverge.org";
};

zone "1.168.192.in-addr.arpa" {
 type master;
 notify no;
 file "1.168.192";
};

zone "." in {
 type hint;
 file "root.cache";
};

Заметьте, что в моем named.conf корневая («.») секция последняя, это потому что в Интернет имеется еще один домен с именем diverge.org (я счастливый его обладатель) и я хочу чтобы система разрешения имен проверяла домены в Интернет в последнюю очередь. Это обычный выбор для большинства систем.

Еще одна очень важная деталь, которую нужно отметить, это если Вы имеете внутреннюю настройку, другими словами Вам не нужно живого подключения к Интернет и/или не нужно просматривать корневые сервера, закомментируйте корневую («.») зону. Это может вызвать некоторые проблемы разрешения имен если требовательный клиент решит сослаться на домен в Интернет, который наш сервер не может сам разрешить.

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

Давайте пройдемся по секциям named.conf:

23.2.1.1. options

Эта секция определяет некоторые глобальные параметры, наиболее упоминаемые это расположение таблиц DNS, в данной конкретной системе, они будут помещены в /etc/namedb как показано в опции «directory».

Далее остальные параметры:

allow-transfer

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

allow-query

В этой опции определяются из каких сетей хосты могут делать запросы к данному серверу имен. Ограничение запросов только для локальной сети (192.168.1.0/24) отклоняет запросы поступающие на внешний интерфейс DNS сервера и устраняет возможные проблемы безопасности.

listen-on port

Эта опция определяет порты и ассоциированные IP адреса, на которых данный сервер будет запущен named(8). Снова, «внешний» интерфейс здесь не перечислен, чтобы отклонить запросы получаемые «снаружи».

Остаток файла named.conf содержит «зоны». Зоны, в пространстве которых, имеются составляющие элементы, которые необходимо разрешать, например, домен может иметь имена которые необходимо разрешать в IP адреса и в обратной зоне могут иметься IP адреса, которые необходимо разрешать в имена хостов. Каждая зона имеет файл с ней ассоциируемый и таблицу в этом файле для разрешения данной зоны. Так как очевидно, что ее формат в named.conf очень прост, мы покажем только одну из этих записей:

23.2.1.2. zone «diverge.org»

type

Тип зоны, обычно «master» во всех случаях кроме корневой зоны «.» и вторичных (резервных) зон, тип последних «secondary».

notify

Вы хотите отправлять уведомления вторичным серверам если ваша зона изменилась? Очевидно нет в данной настройке, по этому здесь стоит «no».

file

В этой опции устанавливается имя файла в нашем каталоге /etc/namedb где находятся описания сответствующих зон. Для зоны "diverge.org" zone, используется файл /etc/namedb/diverge.org.

23.2.2. /etc/namedb/localhost

В большей части файлы зон выглядят очень просто, тем не менее, каждая из них имеет некоторые уникальные свойства. Например файл localhost выглядит так:

Пример 23.2. localhost

 1|$TTL 3600
 2|@    IN SOA strider.diverge.org. root.diverge.org. (
 3|      1  ; Serial
 4|      8H  ; Refresh
 5|      2H  ; Retry
 6|      1W  ; Expire
 7|      1D)  ; Minimum TTL
 8|    IN NS localhost.
 9|localhost.  IN  A  127.0.0.1
10|    IN  AAAA ::1

Построчно:

Строка 1:

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

Строка 2:

Эта строка обычно одинакова во всех файлах зон, за исключением root.cache. Здесь определяется так называемый заголовок "Начала управления" (Start Of Authority - SOA), который содержит некоторую основную информацию о зоне. Особенно интересны в этой строке "strider.diverge.org." и "root.diverge.org." (заметьте завершающие точки!). Очевидно первое это имя данного сервера, а второе - контактная информация данного DNS сервера, в большинстве случаев root выглядит немного неоднозначно, это означает основную учетную запись email, используемую в контактной информации, с "@" замененной на "." (например, у меня должно быть "jrf.diverge.org.").

Строка 3:

Эта строка является серийным номером, определяющим "версию" набора данных зоны (файла). Серийный номер должен увеличиваться каждый раз при внесении изменений в файл, стандартный формат это начать с "1" и наращивать ее при каждом изменении, или использовать значение "ГГГГММДДНН" что расшифровывается как год (ГГГГ), месяц (ММ), день (ДД) и номер изменений файла в этот день (НН).

Строка 4:

Это скорость обновления сервера, здесь выставлена на один раз каждые 8 часов.

Строка 5:

Скорость повторного запроса.

Строка 6:

Срок поиска.

Строка 7:

Минимальное время жизни.

Строка 8:

Это строка сервера имен, используемая как ресурсная запись "NS" чтобы отобразить данный "localhost" (этот компьютер) как DNS сервер управляющий данными этой зоны (где "@", синоним имени зоны используемом в файле named.conf, т.е. "diverge.org").

Строка 9:

Это элемент localhost, использующий ресурсную запись "A" для индикации имени "localhost" которое должно разрешаться в IP адрес 127.0.0.1 для запросов IPv4 (специфицирующихся как запись "A").

Строка 10:

Это элемент IPv6, возвращающий ::1 на запрос адреса IPv6 (AAAA запись) для "localhost.".

23.2.3. /etc/namedb/zone.127.0.0

Файл (или зона) обратного поиска чтобы разрешить особый IP адрес 127.0.0.1 обратно в "localhost":

 1| $TTL 3600
 2| @    IN SOA strider.diverge.org. root.diverge.org. (
 3|      1  ; Serial
 4|      8H  ; Refresh
 5|      2H  ; Retry
 6|      1W  ; Expire
 7|      1D)  ; Minimum TTL
 8|     IN NS localhost.
 9| 1.0.0   IN PTR localhost.

В этом файле все строки такие же как файле зоны localhost за исключением строки 9, это запись обратного поиска (PTR). Здесь опять используется символ "@", позволяющий назначить занчение полученное из named.conf, т.е. "127.in-addr.arpa". Это специальный "домен" который используется для обратного разрешения IP адресов обратно, в имена хостов. Для его работы, используются четыре байта IPv4 адреса и добавляется домен "in-addr.arpa", так чтобы разрешить IP адрес "127.0.0.1", запрашивается PTR запись в "1.0.0.127.in-addr.arpa", которая и определена в этой строке.

23.2.4. /etc/namedb/diverge.org

Этот файл зоны заполнен записями всех наших хостов. Что выглядит примерно так:

 1| $TTL 3600
 2| @    IN SOA strider.diverge.org. root.diverge.org. (
 3|       1  ; serial
 4|       8H  ; refresh
 5|       2H  ; retry
 6|       1W  ; expire
 7|       1D ) ; minimum seconds
 8|     IN NS strider.diverge.org.
 9|     IN MX 10 maila.diverge.org. ; primary mail server
10|     IN MX 20 mailb.diverge.org. ; secondary mail server
11| strider   IN A  192.168.1.1
12| maila   IN CNAME strider.diverge.org.
13| samwise   IN A  192.168.1.2
14| www    IN CNAME samwise.diverge.org.
15| mailb   IN CNAME samwise.diverge.org.
16| worm   IN A  192.168.1.3

Здесь имеется масса новых вещей, так что давайте разберем каждую новую строчку:

Строка 9

Эта строка отображает почтовый обменник (MX), в данном случае это "strider", но по некоторым причинам мы хотим называть его "maila". Цифра указанная перед "maila.diverge.org." это величина приоритета, меньшая цифра означает больший приоритет. Способ, которым мы здесь воспользовались, позволяет если "strider" не может управлять почтой попробовать передать ее через "mailb" (который в дествительности "samwise").

Строка 12

CNAME обозначает каноническое имя или синоним существующего имени хоста, который должен иметь запись A. Так мы имеем следующие синонимы:

maila.diverge.org to strider.diverge.org
mailb.diverge.org to samwise.diverge.org
www.diverge.org   to samwise.diverge.org

Остальные записи просто отображают IP адреса в полные имена (записи A).

23.2.5. /etc/namedb/1.168.192

Эта зона является обратным файлом для всех записей хостов, чтобы отобразить их IP номера, используемые в локальной сети, обратно в имена хостов. Формат такой же как и в случае "localhost" кроме очевидных исключений в отличающихся адресах и другой зоне полученной из файла named.conf, т.е. "0.168.192.in-addr.arpa":

 1|$TTL 3600
 2|@    IN SOA strider.diverge.org. root.diverge.org. (
 3|      1  ; serial
 4|      8H  ; refresh
 5|      2H  ; retry
 6|      1W  ; expire
 7|      1D ) ; minimum seconds
 8|    IN NS strider.diverge.org.
 9|1    IN PTR strider.diverge.org.
10|2    IN PTR samwise.diverge.org.
11|3    IN PTR worm.diverge.org.

23.2.6. /etc/namedb/root.cache

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

;
;  This file holds the information on root name servers needed to
;  initialize cache of Internet domain name servers
;  (e.g. reference this file in the "cache . <file>"
;  configuration file of BIND domain name servers).
;
;  This file is made available by InterNIC
;  under anonymous FTP as
;   file    /domain/db.cache
;   on server   FTP.INTERNIC.NET
;  -OR-     RS.INTERNIC.NET
;
;  last update: Jan 29, 2004
;  related version of root zone: 2004012900
;
;
; formerly NS.INTERNIC.NET
;
.      3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.  3600000  A  198.41.0.4
;
; formerly NS1.ISI.EDU
;
.      3600000  NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.  3600000  A  192.228.79.201
;
; formerly C.PSI.NET
;
.      3600000  NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.  3600000  A  192.33.4.12
;
...

Файл может быть получен у ISC на http://www.isc.org/ и обычно поставляется вместе с дистрибутивом BIND. Файл root.cache входит в набор "etc" операционной системы NetBSD.

В этом разделе были описаны важнейшие файлы и настрйоки сервера DNS. Пожалуйста изучите документацию BIND на /usr/src/dist/bind/doc/bog и named.conf(5) для более подробного ознакомления.

23.3. Использование DNS

В этом разделе мы посмотрим как запустить DNS и настроить "strider" использовать собственные DNS сервисы.

Настройка автоматического старта named очень проста. Просто установите named=yes в /etc/rc.conf. Дополнительные опции могут быть определены в named_flags, например, мне нравится использовать -u nobody, чтобы процесс "named" запускался без высших привилегий.

В дополнение к возможности запуска "named" во время загрузки есть возможность управления им с помощью команды ndc. Командой ndc можно останавливать, запускать и перезапускать процесс сервера. Ей можно также выполнять многие другие вещи. Перед использованием, должна быть установлена связь с процессом "named", см. ndc(8) и named.conf(5) страницы руководств для ознакомления с подробностями настройки каналов связи между "ndc" и процессом "named".

Далее нам необходимо указать "strider" на самого себя для поиска. Сначала определимся с нашим порядком разрешения. В нашей маленькой сети каждый хост имеет копию таблицы хостов, сначала берется информация из /etc/hosts, и затем уже из DNS. Тем не менее в больших сетях намного проще использовать DNS. В любом случае, файл, в котором обусловливается порядок использования сервисов имен для разрешения это /etc/nsswitch.conf (см. Пример 21.2, «nsswitch.conf»). Здесь приведена часть типичного nsswitch.conf:

. . .
group_compat: nis
hosts:   files dns
netgroup:  files [notfound=return] nis
. . .

Строка, которая нас интересует это строка "hosts". "files" говорит системе использовать сначала файл /etc/hostsдля разрешения имен и если в нем не найдено необходимых вхождений пытается использовать DNS.

Следующий файл для проверки это /etc/resolv.conf, который используется для настройки поиска DNS ("разрешения") на клиентской стороне. Формат сам себя объясняет но мы его все равно рассмотрим:

domain diverge.org
search diverge.org
nameserver 192.168.1.1

В окружении этот файл сообщает разрешающей системе что данная машина принадлежит домену "diverge.org", которое означает, что поиск содержащий лишь имя без "." добавляет данный домен для создания FQDN. Ели этот поиск завершается неудачей, домены в строке "search" проверяются следующими. В конце концов строка "nameserver" предоставляет IP адреса других DNS серверов которые должны разрешать запросы DNS.

Для проверки нашего сервера мы можем использовать некоторые команды, например:

# host sam
sam.diverge.org has address 192.168/1.2

Как можно видеть, домен был добавлен автоматически, используя значение из /etc/resolv.conf. Следующий пример, вывод команды host www.yahoo.com:

$ host www.yahoo.com
www.yahoo.com is an alias for www.yahoo.akadns.net.
www.yahoo.akadns.net has address 68.142.226.38
www.yahoo.akadns.net has address 68.142.226.39
www.yahoo.akadns.net has address 68.142.226.46
www.yahoo.akadns.net has address 68.142.226.50
www.yahoo.akadns.net has address 68.142.226.51
www.yahoo.akadns.net has address 68.142.226.54
www.yahoo.akadns.net has address 68.142.226.55
www.yahoo.akadns.net has address 68.142.226.32

Другие команды отладки DNS кроме host(1) это nslookup(8) и dig(1). Заметьте, что ping(8) не используется для отладки DNS, так как используется независимо от конфигурации /etc/nsswitch.conf чтобы разрешить имя.

Теперь сервер настроен правильно. Процедура настройки клиентских хостов намного проще, Вам необходимо настроить только /etc/nsswitch.conf и /etc/resolv.conf с такими же значениями как на сервере.

23.4. Настройка только кэширующего сервера

Только кэширующий сервер имен не имеет локальных зон; все полученные запросы перенаправляются на корневые сервера, а ответы аккумулируются в локальном кэше. В следующий раз запрос получит ответ быстрее, поскольку данные уже находятся в серверном кэше. Поскольку этот тип сервера не управляет локальными зонами для разрешения имен локальных хостов ему все еще необходимо использовать уже известный файл /etc/hosts.

Поскольку NetBSD по умолчанию поставляет для всех файлов настройки необходимые кэширующему серверу, необходимо лишь подключить и запустить и он уже готов к работе! Для подключения named, вставьте named=yes в /etc/rc.conf, и скажите системе использовать добавленную строку в файле /etc/resolv.conf:

# cat /etc/resolv.conf
nameserver 127.0.0.1

Теперь можно запустить named:

# sh /etc/rc.d/named restart

23.4.1. Тестирование сервера

Теперь, когда сервер запущен, мы можем протестировать его, используя программу nslookup(8):

$ nslookup
Default server: localhost
Address: 127.0.0.1

>

Давайте попробуем разрешить имя хоста, например "www.NetBSD.org":

> www.NetBSD.org
Server: localhost
Address: 127.0.0.1

Name: www.NetBSD.org
Address: 204.152.190.12

Если Вы повторите запрос второй раз, результат будет немного отличаться:

> www.NetBSD.org
Server: localhost
Address: 127.0.0.1

Non-authoritative answer:
Name: www.NetBSD.org
Address: 204.152.190.12

Как Вас, возможно, предупреждали, адрес тот же, но появилось сообщение «Non-authoritative answer». Это сообщение отображает что ответ получен не с авторитетного сервера для домена NetBSD.org, а из кэша Вашего собственного сервера.

В результате первый же тест подтверждает, что сервер работает корректно.

Мы также можем попробовать команды host(1) и dig(1), которые дадут следующий результат.

$ host www.NetBSD.org
www.NetBSD.org has address 204.152.190.12
$
$ dig www.NetBSD.org

; <<>> DiG 8.3 <<>> www.NetBSD.org
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19409
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 0
;; QUERY SECTION:
;;  www.NetBSD.org, type = A, class = IN

;; ANSWER SECTION:
www.NetBSD.org.   23h32m54s IN A 204.152.190.12

;; AUTHORITY SECTION:
NetBSD.org.    23h32m54s IN NS uucp-gw-1.pa.dec.com.
NetBSD.org.    23h32m54s IN NS uucp-gw-2.pa.dec.com.
NetBSD.org.    23h32m54s IN NS ns.NetBSD.org.
NetBSD.org.    23h32m54s IN NS adns1.berkeley.edu.
NetBSD.org.    23h32m54s IN NS adns2.berkeley.edu.

;; Total query time: 14 msec
;; FROM: miyu to SERVER: 127.0.0.1
;; WHEN: Thu Nov 25 22:59:36 2004
;; MSG SIZE sent: 32 rcvd: 175 

Как Вы можете увидеть dig(1) дает совсем другой вывод, ожидаемый ответ можно найти в секции "ANSWER SECTION". Остальные данные могут представлять интерес при отладке проблем DNS.

Обновлено: 16.03.2015