Подробное изложение принципов настройки DNS с примером настройки сервера имен.


СТАНДАРТЫ DNS
ФОРМАТ ЗАПИСЕЙ В ФАЙЛАХ БАЗЫ DNS
ТИПЫ РЕСУРСОВ
SOA (НАЧАЛО ПОЛНОМОЧИЙ)
NS (СЕРВЕР ИМЕН)
A (АДРЕС)
CNAME (КАНОНИЧЕСКОЕ ИМЯ)
HINFO (ИНФОРМАЦИЯ О ХОСТЕ)
MX (ПОЧТОВЫЙ ШЛЮЗ)
PTR (УКАЗАТЕЛЬ)
СПЕЦИФИКАЦИЯ BIND
ПРИМЕР РЕАЛИЗАЦИИ DNS В ЛОКАЛЬНОЙ СЕТИ

ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ


Среди администраторов сетей бытует мнение, что DNS следует использовать только при наличии подключения к Internet. Но DNS позволяет упростить администрирование локальных сетей TCP/IP независимо от того, имеют они выход в Internet или нет.

При отсутствии DNS добавление компьютера в локальную сеть приводит к тому, что в файл hosts каждого хоста необходимо ввести информацию о новом компьютере. Это нетрудно, если машин в сети немного. А если их десятки или сотни?

При использовании DNS вся процедура сводится к добавлению одной-двух строк в файлы базы DNS на первичном сервере имен. После этого хосты сети будут распознавать новый компьютер по имени автоматически.

Если по каким-либо причинам необходимо изменить IP-адрес или имя хоста, то с DNS сделать это довольно просто. Кроме того, использование DNS значительно облегчает процедуру подключения корпоративной сети к Internet.

СТАНДАРТЫ DNS

Настройка базы DNS задается в специальных текстовых файлах на серверах имен. Форматы записей в этих файлах регламентируются стандартами, изложенными в документах RFC (Request For Comments). Они разрабатываются "законодательным" органом Internet - IETF (Internet Engineering Task Force). Однако сам набор файлов и порядок их загрузки на серверах имен RFC не регламентируется. Для этого существует стандарт de facto под названием BIND (Berkley Internet Name Domain). Данная спецификация была разработана в университете Беркли и впервые реализована в BSD Unix. Подавляющее большинство серверов имен поддерживают спецификацию BIND.

Многие версии программного обеспечения серверов имен имеют административные утилиты, упрощающие настройку и управление базами DNS. Тем не менее администраторы сетей, как правило, предпочитают не пользоваться ими, а работать напрямую с файлами базы DNS. Хотя это несколько усложняет администрирование, но в то же время дает максимальную гибкость и полный контроль при управлении DNS.

В общем случае порядок запуска серверов имен следующий: сначала создаются файлы базы DNS (напрямую или через административные утилиты), а затем запускается сервис DNS (в Unix - демон named, в NetWare - программа NAMED.NLM).

ФОРМАТ ЗАПИСЕЙ В ФАЙЛАХ БАЗЫ DNS

В файлах базы DNS серверов имен используется так называемый формат записи стандартных ресурсов (Standard Resource Record Format). Выглядит этот формат следующим образом:

[] [] []  

Каждая составляющая здесь является полем записи и отделена от других пробелами или знаками табуляции.

- имя описываемого ресурса. Оно зависит от поля и может обозначать домен, зону управления, имя хоста и т. д. Если поле пустое, то в качестве него используется последнее заданное поле (в предыдущих записях).

- время жизни (в секундах). Определяет, как долго клиент DNS будет хранить запись в кэш-памяти. Если данное поле пустое, то в качестве берется значение поля , задаваемое в записи SOA (см. ниже).

описание класса используемых протоколов. Для Internet (TCP/IP) значение этого поля - IN. Если поле пустое, то в качестве него используется последний заданный класс.

- поле, задающее тип ресурса записи. Возможные значения этого поля приведены в разделе "Типы ресурсов".

- поле, устанавливающее данные текущего ресурса. Его содержание зависит от поля . Поле может быть составным, т. е. состоять из нескольких полей.

Следующие символы в записях имеют специальное значение (ниже перечислены некоторые из этих символов).

. Отдельно стоящая точка в поле обозначает текущий домен.

@ Отдельно стоящий символ "@" в поле обозначает текущий исходный домен.

( ) Скобки используются для размещения поля на нескольких строках (когда поле занимает несколько строк).

* Метасимвол. Заменяет любой набор символов.

; Символ комментария. От этого символа и до конца строки информация игнорируется.

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

ТИПЫ РЕСУРСОВ

Тип ресурса задается в поле записи ресурса.

Типов ресурсов множество. Полный их список можно узнать в соответствующих RFC (см. "Дополнительную информацию"). Ниже приводятся наиболее используемые типы.

SOA
Начало полномочий (управления) сервера имен.
NS
Сервер имен.
A
Адрес хоста.
CNAME
Каноническое имя. Используется для задания псевдонимов.
HINFO
Информация о хосте.
MX
Почтовый шлюз.
PTR
Указатель.

Рассмотрим каждый из этих типов.

SOA (НАЧАЛО ПОЛНОМОЧИЙ)

Запись с ресурсом типа SOA обозначает начало зоны управления сервера имен. Зона управления действует до следующей записи SOA. На Распечатке 1 дается формат записи SOA, а также пример использования.

Здесь поле является составным и включает поля , , и т. д.

Обозначает имя домена зоны управления.

Имя первичного сервера имен зоны.

Почтовый ящик лица, ответственного за зону. Данное поле формируется аналогично электронному адресу, но вместо символа "@" ставится точка (т. е. koka@aozio.msk.ru заменяется на koka.aozio.msk.ru).

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

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

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

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

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

NS (СЕРВЕР ИМЕН)

Запись с ресурсом типа NS обозначает имя хоста, являющегося первичным сервером имен для домена. На Распечатке 2 дается формат и пример использования записи NS.

обозначает домен, а - имя сервера имен. В примере показывается, что серверы srv.comp1.com и srv.comp2.com представляют собой серверы имен домена comp1.com.

A (АДРЕС)

Запись с ресурсом типа A служит для задания сетевого адреса хоста. На Распечатке 3 приводится формат и пример использования записи A. Здесь - доменное имя хоста, а

- его IP-адрес.

CNAME (КАНОНИЧЕСКОЕ ИМЯ)

Запись с ресурсом типа CNAME применяется для указания псевдонима хоста. Формат и пример использования записи CNAME приведены на Распечатке 4. обозначает псевдоним, а - официальное (каноническое) имя хоста.

HINFO (ИНФОРМАЦИЯ О ХОСТЕ)

Запись с ресурсом типа HINFO служит для хранения информации о хосте, в частности об аппаратной платформе и операционной системе компьютера. На Распечатке 5 представлен формат и пример использования записи HINFO. Поле обозначает доменное имя хоста, - аппаратную платформу, - ОС хоста. Значения полей и стандартизированы, их следует брать из RFC 1700. Но можно применять и свои варианты, поскольку данный RFC сильно устарел (там нет ПК старше 386, а также Windows NT, Windows 95 и т. д.).

MX (ПОЧТОВЫЙ ШЛЮЗ)

Для отдельных хостов или всего домена запись с ресурсом типа MX позволяет определить почтовый шлюз - компьютер, куда будет направляться электронная почта, предназначенная для этих хостов. Формат и пример использования записи MX представлены на Распечатке 6. Поле обозначает домен или имя хоста, для которого устанавливается почтовый шлюз. - имя хоста почтового шлюза. задает приоритет доставки, при этом ноль означает самый высокий приоритет. В примере показано, что если почта предназначена для домена comp.com, то она доставляется на машину unix1.comp.com. Если же почта предназначена для любого компьютера домена, имя которого оканчивается на -dos, то она направляется на unix2.comp.com.

Таким образом, письмо, отправленное по адресу:

1. ivan@comp.com, переадресуется ivan@unix1.comp.com;

2. ivan@pc-dos.comp.com, переадресуется ivan@unix2.comp.com;

3. ivan@host1.comp.com, попадет к ivan@host1.comp.com.

PTR (УКАЗАТЕЛЬ)

Прежде чем рассматривать записи с ресурсом типа PTR, следует остановиться на поиске доменного имени хоста по его IP-адресу (так называемое обратное преобразование).

Структура имен в доменной системе построена так, что, продвигаясь вдоль иерархического дерева DNS, за счет последовательного обращения к серверам имен IP-адрес хоста можно найти по его имени (прямое преобразование). А вот доменное имя хоста по его IP-адресу в такой системе найти довольно трудно.

Для того чтобы облегчить эту задачу, в пределах общей доменной структуры был создан вспомогательный домен. Он имеет специальное название IN-ADDR.ARPA. Внутри этого домена существуют поддомены для каждой IP-сети. Имена этих поддоменов основаны на сетевых адресах, причем байты (октеты) IP-адресов представлены в обратном порядке.

Например, сеть cso.uiuc.edu имеет сетевой адрес 128.174 (вернее, 128.174.0.0, это IP-сеть класса B). Внутри этой сети имеется хост vmd.cso.uiuc.edu с IP-адресом 128.174.5.98. Тогда для всей сети вспомогательный домен будет 174.128.in-addr.arpa. Имя хоста в этом домене будет 98.5.174.128.in-addr.arpa.

Ресурсы с записью типа PTR служат для отображения этих специальных доменных имен в обычные. На Распечатке 7 представлен формат записи PTR и пример использования. Поле обозначает специальное доменное имя (в домене IN-ADDR.ARPA), а поле - официальное доменное имя хоста.

Вспомогательный домен IN-ADDR.ARPA используется также для указания шлюза (маршрутизатора) для сетей. Шлюз представляет собой хост, соединяющий несколько IP-сетей. Для него существуют обычные записи PTR хоста, но, кроме того, имеются специальные записи PTR, представляющие IP-сети целиком. Эти записи включают только первые 1, 2 или 3 байта (октета) IP-адреса сети в зависимости от класса IP-сети (A, B или C).

Допустим, имеется шлюз gw.comp1.com, объединяющий сети класса A, B и C и имеющий соответствующие IP-адреса: 12.2.0.7, 129.14.1.3 и 194.140.13.2. На Распечатке 8 представлены записи A и PTR для данного шлюза.

СПЕЦИФИКАЦИЯ BIND

Как уже отмечалось, стандартом de facto в описании состава файлов DNS и порядка их загрузки на сервере имен является спецификация BIND. Она поддерживается во всех Unix-системах, в NetWare (программные продукты Novell NFS Services, FTP Services, NetWare/IP) и ряде других систем.

Согласно данной спецификации существует файл загрузки базы DNS. В Unix-системах обычно это файл /etc/named.boot, в NetWare - SYS:ETCNAMED.CFG, который загружается при запуске сервиса DNS на сервере имен. Основное назначение файла загрузки - указывать, где расположены файлы базы DNS, а также адреса серверов имен. При любом изменении как файла загрузки, так и файлов базы DNS сервис DNS необходимо перезапускать.

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

1. directory

Устанавливает каталог хранения файлов базы DNS, если не указаны абсолютные пути к файлам. Пример: directory /etc

2. domain

Определяет домен по умолчанию для данного сервера имен. Пример: domain company.msk.ru

3. primary

Показывает, что сервер имен является первичным для домена и что база домена хранится в файле . Пример: primary company.msk.ru /usr/named.data

4. secondary [...]

Указывает, что данный сервер имен является вторичным для домена . Первичные серверы расположены по IP-адресам , и т. д. Данный вторичный сервер запрашивает по порядку первичные серверы и копирует полученную с первого ответившего первичного сервера информацию в файл . Пример: secondary comp.com 194.132.14.3 named.bak

5. cache

Указывает, что данный сервер является кэш-сервером имен для домена . Параметры кэш-сервера (прежде всего адреса и имена серверов имен корневого домена) считываются из файла . Пример: cache . named.ca

6. Строка, начинающаяся с символа ";", считается комментарием.

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

ПРИМЕР РЕАЛИЗАЦИИ DNS В ЛОКАЛЬНОЙ СЕТИ

Подводя итоги, рассмотрим пример настройки DNS на серверах имен типичной локальной сети TCP/IP.

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

IP-адреса сетей и хостов, а также доменные имена вымышленные и приведены лишь для простоты понимания.

В реальной жизни, если сеть будет подключаться к Internet, необходимо получить официальные IP-адреса сетей и зарегистрированный домен. Их выдачей занимается специализированная организация в рамках Internet под названием InterNIC, при этом регистрация доменов происходит независимо от выдачи IP-адресов. Однако в России IP-адреса можно получить с помощью своего Internet-провайдера или обратившись по адресу ncc@ussr.EU.net или ncc@kiae.su. Доменное имя регистрируется через Internet-провайдера.

Если локальная сеть не имеет выхода в Internet, то IP-адреса и доменные имена можно выбрать по своему усмотрению. Если в дальнейшем возникнет потребность подключения к Internet, то перестроить DNS не составит труда.

Рассматриваемая локальная сеть состоит из двух IP-сетей класса C: 194.170.12.0 и 194.170.13.0 (Рисунок 1). Допустим, эти сети образуют один домен comp1.msk.ru. IP-сети объединяют шлюз (маршрутизатор) gw с адресами: 194.170.12.1 и 194.170.13.4. Подключение к Internet также происходит через данный шлюз. В домене имеется первичный сервер имен srv1 (194.170.12.2) и вторичный сервер имен srv2 (194.170.13.3), а также ряд хостов: host1, host2, host3. Хост mail (194.170.13.2) является почтовым шлюзом для всего домена, к тому же у него есть псевдоним host4.

Picture 1(1x1)

Рисунок 1.
Пример реализации DNS.

На Распечатке 9 представлены состав и содержимое базы DNS для первичного сервера имен srv1.comp1.msk.ru, а на Распечатке 10 - для вторичного сервера srv2.comp1.msk.ru.

Как для первичного, так и для вторичного сервера имен, в случае если локальная сеть не имеет выхода в Internet, следует убрать строку cache в файле /etc/named.boot и удалить файл /etc/named.ca.

Об именах и адресах серверов имен корневого домена, перечисленных в файле /etc/named.ca, необходимо справиться у Internet-провайдера. Кроме того, Internet-провайдер должен внести данные о серверах имен srv1.comp1.msk.ru и srv2.comp1.msk.ru в свою базу DNS, чтобы обеспечить доступ из Internet к машинам домена comp1.msk.ru.

Вспомогательный домен 0.0.127.in-addr.arpa, а также хост localhost (127.0.0.1) в каждой из зон необходимы для создания локальной "петли" TCP/IP.

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


Константин Пьянзин - администратор сети АО "Подольский машиностроительный завод". С ним можно связаться по адресу: koka@aozio.msk.ru.

РАСПЕЧАТКА 1 - ЗАПИСЬ SOA

  []  []  SOA      (
                                 
                                 
                                 
                                 
                                   )

comp.com.      IN  SOA  srv.comp.com.  root.srv.comp.com. (
                        970308
                        3600
                        600
                        3600000
                        86400  )


РАСПЕЧАТКА 2 - ЗАПИСЬ NS

[]  []  []  NS  

comp1.com.            NS  srv.comp1.com.
                      NS  srv.comp2.com.


РАСПЕЧАТКА 3 - ЗАПИСЬ A

[]  [] []  A  

sri-nic.arpa.              A  10.0.0.51


РАСПЕЧАТКА 4 - ЗАПИСЬ CNAME

[]  []  []  CNAME  

pc1.comp.com.            CNAME  srv.comp.com.


РАСПЕЧАТКА 5 - ЗАПИСЬ HINFO

[]  []  []  HINFO    

pc1              HINFO  IBM-PC  MSDOS
rs1              HINFO  IBM-RS/6000  AIX


РАСПЕЧАТКА 6 - ЗАПИСЬ MX

[]  []  []  MX   

comp.com.           MX  10  unix1.comp.com.
*-dos.comp.com.     MX  10  unix2.comp.com.


РАСПЕЧАТКА 7 - ЗАПИСЬ PTR ДЛЯ ХОСТА

[]  []  []  PTR  

98.5.174.128.in-addr.arpa.   PTR  vmd.cso.uiuc.edu.
51.0.0.10.in-addr.arpa.      PTR  sri-nic.arpa.


РАСПЕЧАТКА 8 - ПРИМЕР ЗАПИСЕЙ PTR И A ДЛЯ ШЛЮЗА

;Записи A
gw.comp1.com.          A  12.2.0.7
                       A  129.14.1.3
                       A  194.140.13.2
; Записи PTR для шлюз  к к х(r)ст 
7.0.2.12.in-addr.arpa.      PTR  gw.comp1.com.
3.1.14.129.in-addr.arpa.    PTR  gw.comp1.com.
2.13.140.194.in-addr.arpa.  PTR  gw.comp1.com.
; З писи PTR для сете(c)
12.in-addr.arpa.          PTR  gw.comp1.com.
14.129.in-addr.arpa.      PTR  gw.comp1.com.
13.140.194.in-addr.arpa.  PTR  gw.comp1.com.


РАСПЕЧАТКА 9 - СОСТАВ И СОДЕРЖИМОЕ БАЗЫ DNS НА ПЕРВИЧНОМ СЕРВЕРЕ SRV1

; " (c)л  /etc/named.boot
directory  /etc
domain   comp1.msk.ru
primary  comp1.msk.ru             named.data
primary  12.170.194.in-addr.arpa  named.rev1
primary  13.170.194.in-addr.arpa  named.rev2
primary  0.0.127.in-addr.arpa     named.local
; вых(r)д в Internet
cache    .                        named.ca


; " (c)л  /etc/named.data
@         IN  SOA    srv1.comp1.msk.ru.  root.mail.comp1.msk.ru.  (
                        970308
                        3600
                        600
                        3600000
                        86400  )
                 NS     srv1.comp1.msk.ru.
localhost        A      127.0.0.1
gw               A      194.170.12.1
                 A      194.170.13.4
                 HINFO  IBM-RS/6000  AIX
srv1             A      194.170.12.2
                 HINFO  IBM-RS/6000  AIX
host1            A      194.170.12.3
                 HINFO  IBM-PC  MSDOS
host2            A      194.170.12.4
                 HINFO  IBM-PC  MSDOS
host3            A      194.170.13.1
                 HINFO  IBM-PC  MSDOS
mail             A      194.170.13.2
                 HINFO  IBM-PC  UNIX
host4            CNAME  mail.comp1.msk.ru.
srv2             A      194.170.13.3
                 HINFO  IBM-PC  UNIX
comp1.msk.ru.    MX  10  mail
*.comp1.msk.ru.  MX  0   mail.comp1.msk.ru.


; " (c)л /etc/named.rev1
@         IN  SOA    srv1.comp1.msk.ru.  root.mail.comp1.msk.ru.  (
                        960218
                        3600
                        600
                        3600000
                        86400  )
          NS     srv1.comp1.msk.ru.
1         PTR    gw.comp1.msk.ru.
12.170.194.in-addr.arpa.  PTR  gw.comp1.msk.ru.
2         PTR    srv1.comp1.msk.ru.
3         PTR    host1.comp1.msk.ru.
4         PTR    host2.comp1.msk.ru.


; " (c)л /etc/named.rev2
@         IN  SOA    srv1.comp1.msk.ru.  root.mail.comp1.msk.ru.  (
                        970205
                        3600
                        600
                        3600000
                        86400  )
          NS     srv1.comp1.msk.ru.
1         PTR    host3.comp1.msk.ru.
2         PTR    mail.comp1.msk.ru.
3         PTR    srv2.comp1.msk.ru.
4         PTR    gw.comp1.msk.ru.
13.170.194.in-addr.arpa.  PTR  gw.comp1.msk.ru.


; " (c)л /etc/named.local
@     IN  SOA    srv1.comp1.msk.ru.  root.mail.comp1.msk.ru.  (
                        960124
                        3600
                        600
                        3600000
                        86400  )
          NS     srv1.comp1.msk.ru.
1         PTR    localhost


; " (c)л /etc/named.ca
.   999999    IN   NS  sri-nic.arpa.
                   NS  brl-aos.arpa.
sri-nic.arpa.   999999  A  10.0.0.51
                999999  A  26.0.0.73
brl-aos.arpa.   999999  A  192.5.25.82
                999999  A  128.20.1.2


РАСПЕЧАТКА 10 - СОСТАВ И СОДЕРЖИМОЕ БАЗЫ DNS НА ВТОРИЧНОМ СЕРВЕРЕ SRV

; " (c)л  /etc/named.boot
directory  /etc
domain    comp1.msk.ru
secondary comp1.msk.ru  194.170.12.2  named.data.bak
secondary 12.170.194.in-addr.arpa 194.170.12.2 named.rev1.bak
secondary 13.170.194.in-addr.arpa 194.170.12.2 named.rev2.bak
primary  0.0.127.in-addr.arpa     named.local
; вых(r)д в Internet
cache    .                        named.ca


; " (c)л /etc/named.local
@     IN  SOA    srv2.comp1.msk.ru.  root.mail.comp1.msk.ru.  (
                        960124
                        3600
                        600
                        3600000
                        86400  )
          NS     srv2.comp1.msk.ru.1         PTR    localhost


; " (c)л /etc/named.ca
.   999999    IN   NS  sri-nic.arpa.
                   NS  brl-aos.arpa.
sri-nic.arpa.   999999  A  10.0.0.51
                999999  A  26.0.0.73
brl-aos.arpa.   999999  A  192.5.25.82
                999999  A  128.20.1.2


ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ

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

  1. P. Albitz and C. Liu. "DNS and BIND" Help for Unix System Administrators, O'Reilly and Associates, Inc. Это самая полная и понятная книга по DNS, но в ней приводятся сведения по настройке DNS только на Unix-машинах. Книга встречается в продаже в Москве.
  2. Документы RFC. Основными для знакомства с DNS являются RFC 1032, 1033, 1034 и 1035. Для глубокого понимания DNS рекомендуются RFC: 2052, 1996, 1995, 1912, 1886, 1876, 1816, 1794, 1788, 1713, 1712, 1706, 1703, 1664, 1612, 1611, 1591, 1536, 1535, 1530, 1529, 1528, 1519, 1517, 1464, 1401, 1383, 1183, 1136, 1101, 974, 921, 920, 897, 881, 799, 756, 752. RFC можно получить через анонимный ftp по любому из перечисленных адресов: ftp.misc.sri.com, nisc.junc.net, nnsc.nsf.net, munnari.oz.au.

Поделитесь материалом с коллегами и друзьями