«Журнал сетевых решений/LAN» , № 03, 1997 1324 прочтения
Настройка серверов имен DNS
Подробное изложение принципов настройки 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). Выглядит этот формат следующим образом:
[<Name>] [<TTL>] [<Class>] <Type> <Data>
Каждая составляющая здесь является полем записи и отделена от других пробелами или знаками табуляции.
<Name> - имя описываемого ресурса. Оно зависит от поля <Type> и может обозначать домен, зону управления, имя хоста и т. д. Если поле <Name> пустое, то в качестве него используется последнее заданное поле <Name> (в предыдущих записях).
<TTL> - время жизни (в секундах). Определяет, как долго клиент DNS будет хранить запись в кэш-памяти. Если данное поле пустое, то в качестве <TTL> берется значение поля <Minimum>, задаваемое в записи SOA (см. ниже).
<Class> описание класса используемых протоколов. Для Internet (TCP/IP) значение этого поля - IN. Если поле пустое, то в качестве него используется последний заданный класс.
<Type> - поле, задающее тип ресурса записи. Возможные значения этого поля приведены в разделе "Типы ресурсов".
<Data> - поле, устанавливающее данные текущего ресурса. Его содержание зависит от поля <Type>. Поле <Data> может быть составным, т. е. состоять из нескольких полей.
Следующие символы в записях имеют специальное значение (ниже перечислены некоторые из этих символов).
. Отдельно стоящая точка в поле <Name> обозначает текущий домен.
@ Отдельно стоящий символ "@" в поле <Name> обозначает текущий исходный домен.
( ) Скобки используются для размещения поля <Data> на нескольких строках (когда поле <Data> занимает несколько строк).
* Метасимвол. Заменяет любой набор символов.
; Символ комментария. От этого символа и до конца строки информация игнорируется.
Примечание. Следует знать, что в записях ресурсов доменное имя, не заканчивающееся точкой, считается относительным. При обработке оно прибавляется к текущему домену. Поэтому, когда задается полное имя, его необходимо заканчивать точкой.
ТИПЫ РЕСУРСОВ
Тип ресурса задается в поле <Type> записи ресурса.
Типов ресурсов множество. Полный их список можно узнать в соответствующих RFC (см. "Дополнительную информацию"). Ниже приводятся наиболее используемые типы.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Рассмотрим каждый из этих типов.
SOA (НАЧАЛО ПОЛНОМОЧИЙ)
Запись с ресурсом типа SOA обозначает начало зоны управления сервера имен. Зона управления действует до следующей записи SOA. На Распечатке 1 дается формат записи SOA, а также пример использования.
Здесь поле <Data> является составным и включает поля <Origin>, <Person>, <Serial> и т. д.
<Name> Обозначает имя домена зоны управления.
<Origin> Имя первичного сервера имен зоны.
<Person> Почтовый ящик лица, ответственного за зону. Данное поле формируется аналогично электронному адресу, но вместо символа "@" ставится точка (т. е. koka@aozio.msk.ru заменяется на koka.aozio.msk.ru).
<Serial> Номер версии зоны. Когда производятся изменения в зоне, то это число необходимо увеличить. Именно по данному полю ориентируется вторичный сервер имен, определяя необходимость обновления информации по зоне.
<Refresh> Время в секундах, по прошествии которого вторичный сервер проверяет необходимость обновления информации по зоне.
<Retry> Время в секундах для повторного обращения вторичного сервера зоны, если ранее попытка обращения к первичному серверу была неудачной.
<Expire> Предел времени в секундах. Если вторичный сервер не может получить доступ к первичному в течение этого времени, то он будет считать информацию по зоне устаревшей.
<Minimum> Значение TTL в записях ресурсов данной зоны по умолчанию, т. е. когда поле <TTL> пустое.
NS (СЕРВЕР ИМЕН)
Запись с ресурсом типа NS обозначает имя хоста, являющегося первичным сервером имен для домена. На Распечатке 2 дается формат и пример использования записи NS.
<Domain> обозначает домен, а <Server> - имя сервера имен. В примере показывается, что серверы srv.comp1.com и srv.comp2.com представляют собой серверы имен домена comp1.com.
A (АДРЕС)
Запись с ресурсом типа A служит для задания сетевого адреса хоста. На Распечатке 3 приводится формат и пример использования записи A. Здесь <Host> - доменное имя хоста, а <Address> - его IP-адрес.
CNAME (КАНОНИЧЕСКОЕ ИМЯ)
Запись с ресурсом типа CNAME применяется для указания псевдонима хоста. Формат и пример использования записи CNAME приведены на Распечатке 4. <Nickname> обозначает псевдоним, а <Host> - официальное (каноническое) имя хоста.
HINFO (ИНФОРМАЦИЯ О ХОСТЕ)
Запись с ресурсом типа HINFO служит для хранения информации о хосте, в частности об аппаратной платформе и операционной системе компьютера. На Распечатке 5 представлен формат и пример использования записи HINFO. Поле <Host> обозначает доменное имя хоста, <Hardware> - аппаратную платформу, <Software> - ОС хоста. Значения полей <Hardware> и <Software> стандартизированы, их следует брать из RFC 1700. Но можно применять и свои варианты, поскольку данный RFC сильно устарел (там нет ПК старше 386, а также Windows NT, Windows 95 и т. д.).
MX (ПОЧТОВЫЙ ШЛЮЗ)
Для отдельных хостов или всего домена запись с ресурсом типа MX позволяет определить почтовый шлюз - компьютер, куда будет направляться электронная почта, предназначенная для этих хостов. Формат и пример использования записи MX представлены на Распечатке 6. Поле <Name> обозначает домен или имя хоста, для которого устанавливается почтовый шлюз. <Host> - имя хоста почтового шлюза. <Preference> задает приоритет доставки, при этом ноль означает самый высокий приоритет. В примере показано, что если почта предназначена для домена 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 и пример использования. Поле <Special-name> обозначает специальное доменное имя (в домене IN-ADDR.ARPA), а поле <Name> - официальное доменное имя хоста.
Вспомогательный домен 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 <Path>
Устанавливает каталог хранения файлов базы DNS, если не указаны абсолютные пути к файлам. Пример: directory /etc
2. domain <Domain>
Определяет домен по умолчанию для данного сервера имен. Пример: domain company.msk.ru
3. primary <Domain> <FileName>
Показывает, что сервер имен является первичным для домена <Domain> и что база домена хранится в файле <FileName>. Пример: primary company.msk.ru /usr/named.data
4. secondary <Domain> <IP-1> [<IP-2>...] <FileName>
Указывает, что данный сервер имен является вторичным для домена <Domain>. Первичные серверы расположены по IP-адресам <IP-1>, <IP-2> и т. д. Данный вторичный сервер запрашивает по порядку первичные серверы и копирует полученную с первого ответившего первичного сервера информацию в файл <FileName>. Пример: secondary comp.com 194.132.14.3 named.bak
5. cache <Domain> <FileName>
Указывает, что данный сервер является кэш-сервером имен для домена <Domain>. Параметры кэш-сервера (прежде всего адреса и имена серверов имен корневого домена) считываются из файла <FileName>. Пример: 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.
(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
<Name> [<TTL>] [<Class>] SOA <Origin> <Person> (
<Serial>
<Refresh>
<Retry>
<Expire>
<Minimum> )
comp.com. IN SOA srv.comp.com. root.srv.comp.com. (
970308
3600
600
3600000
86400 )
РАСПЕЧАТКА 2 - ЗАПИСЬ NS
[<Domain>] [<TTL>] [<Class>] NS <Server>
comp1.com. NS srv.comp1.com.
NS srv.comp2.com.
РАСПЕЧАТКА 3 - ЗАПИСЬ A
[<Host>] [<TTL>] [<Class>] A <Adress> sri-nic.arpa. A 10.0.0.51
РАСПЕЧАТКА 4 - ЗАПИСЬ CNAME
[<Nickname>] [<TTL>] [<Class>] CNAME <Host> pc1.comp.com. CNAME srv.comp.com.
РАСПЕЧАТКА 5 - ЗАПИСЬ HINFO
[<Host>] [<TTL>] [<Class>] HINFO <Hardware> <Software> pc1 HINFO IBM-PC MSDOS rs1 HINFO IBM-RS/6000 AIX
РАСПЕЧАТКА 6 - ЗАПИСЬ MX
[<Name>] [<TTL>] [<Class>] MX <Preference> <Host> comp.com. MX 10 unix1.comp.com. *-dos.comp.com. MX 10 unix2.comp.com.
РАСПЕЧАТКА 7 - ЗАПИСЬ PTR ДЛЯ ХОСТА
[<Special-name>] [<TTL>] [<Class>] PTR <Name> 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, можно порекомендовать специализированную литературу. К сожалению, вся она на английском языке.
- P. Albitz and C. Liu. "DNS and BIND" Help for Unix System Administrators, O'Reilly and Associates, Inc. Это самая полная и понятная книга по DNS, но в ней приводятся сведения по настройке DNS только на Unix-машинах. Книга встречается в продаже в Москве.
- Документы 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.
