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

Формат записей в файлах базы 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 Начало полномочий (управления) сервера имен.
ћ NS Сервер имен.
ћ A Адрес хоста.
ћ CNAME Каноническое имя. Используется для задания псевдонимов.
ћ HINFO Информация о хосте.
ћ MX Почтовый шлюз.
ћ PTR Указатель.

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

SOA (начало полномочий)

Запись с ресурсом типа SOA обозначает начало зоны управления сервера имен. Зона управления действует до следующей записи SOA.

ПРИМЕР ЗАПИСИ SOA

<Name>  [<TTL>]  [<Class>]  SOA  <Origin>  <Person>  (
                                 <Serial>
                                 <Refresh>
                                 <Retry>
                                 <Expire>
                                 <Minimum>  )

komtek.dp.ua.      IN  SOA  srv.komtek.dp.ua.  root.srv.komtek.dp.ua. (
                            970308
                            3600
                            600
                            3600000
                            86400  )

Здесь поле <Data> является составным и включает поля <Origin>, <Person>, <Serial> и т. д.

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

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

<Person> Почтовый ящик лица, ответственного за зону. Данное поле формируется аналогично электронному адресу, но вместо символа "@" ставится точка (т. е. alex@komtek.dp.ua заменяется на alex.komtek.dp.ua).

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

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

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

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

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

NS (сервер имен)

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

ПРИМЕР ЗАПИСИ NS

[<Domain>]  [<TTL>]  [<Class>]  NS  <Server>

komtek.dp.ua.                   NS  srv1.komtek.dp.ua.
                                NS  srv2.komtek.dp.ua.

<Domain> обозначает домен, а <Server> - имя сервера имен. В примере показывается, что серверы srv1.komtek.dp.ua и srv2.komtek.dp.ua представляют собой серверы имен домена komtek.dp.ua.

A (адрес)

Запись с ресурсом типа A служит для задания сетевого адреса хоста. Здесь <Host> - доменное имя хоста, а <Address>- его IP-адрес.

ПРИМЕР ЗАПИСИ A

[<Host>] [<TTL>] [<Class>] A <Adress>

sri-nic.arpa.
A 10.0.0.51

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

Запись с ресурсом типа CNAME применяется для указания псевдонима хоста. <Nickname> обозначает псевдоним, а <Host> - официальное (каноническое) имя хоста.

ПРИМЕР ЗАПИСИ CNAME

[<Nickname>]  [<TTL>]  [<Class>]  CNAME  <Host>

rs1                               CNAME  srv1.komtek.dp.ua.
www                               CNAME  srv2.komtek.dp.ua
ftp                               CNAME  srv2.komtek.dp.ua

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

Запись с ресурсом типа HINFO служит для хранения информации о хосте, в частности об аппаратной платформе и операционной системе компьютера.

Поле <Host> обозначает доменное имя хоста, <Hardware> - аппаратную платформу, <Software> - ОС хоста. Значения полей <Hardware> и <Software> стандартизированы, их следует брать из RFC 1700.

ПРИМЕР ЗАПИСИ HINFO

[<Host>]  [<TTL>]  [<Class>]  HINFO  <Hardware>  <Software>

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

MX (почтовый шлюз)

Так как не на всех хостах запущен сервер e-mail, то для отдельных хостов или всего домена запись с ресурсом типа MX позволяет определить почтовый шлюз - компьютер, куда будет направляться электронная почта, предназначенная для этих хостов. Поле <Name> обозначает домен или имя хоста, для которого устанавливается почтовый шлюз. <Host> - имя хоста почтового шлюза. <Reference> задает приоритет доставки, при этом ноль означает самый высокий приоритет.

В примере показано, что если почта предназначена для домена komtek.dp.ua, то она доставляется на машину unix1.komtek.dp.ua. Если же почта предназначена для любого компьютера домена, имя которого оканчивается на -dos, то она направляется на unix2.komtek.dp.ua.

ПРИМЕР ЗАПИСИ MX

[<Name>]  [<TTL>]  [<Class>]  MX <Preference>  <Host>

komtek.dp.ua.                 MX  10  unix1.komtek.dp.ua.
*-dos.komtek.dp.ua.           MX  10  unix2.komtek.dp.ua.

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

1. alex@komtek.dp.ua, переадресуется alex@unix1.komtek.dp.ua;
2. vad@pc-dos.komtek.dp.ua, переадресуется vad@unix2.komtek.dp.ua;
3. dba@host1.komtek.dp.ua, попадет к dba@host1.komtek.dp.ua.

Если администратор определяет несколько записей MX, то для указания порядка опроса почтовых шлюзов используется число (в примере - 10) первым опрашивается шлюз с меньшим числом.

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 служат для отображения этих специальных доменных имен в обычные. Поле <Special-name> обозначает специальное доменное имя (в домене IN-ADDR.ARPA), а поле <Name> - официальное доменное имя хоста.

ПРИМЕР ЗАПИСИ 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.

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

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

ПРИМЕР ЗАПИСЕЙ PTR И A ДЛЯ ШЛЮЗА

;Записи A
gw.komtek.dp.ua.       A  192.168.1.7
                       A  192.168.2.3
                       A  194.140.13.2
; Записи PTR для шлюза 
7.1.168.192.in-addr.arpa.   PTR  gw.komtek.dp.ua.
3.2.168.192.in-addr.arpa.   PTR  gw.komtek.dp.ua.
2.13.140.194.in-addr.arpa.  PTR  gw.komtek.dp.ua.
; Записи PTR для сетей
1.1.168.192.in-addr.arpa.   PTR  gw.komtek.dp.ua.
2.168.192.in-addr.arpa.     PTR  gw.komtek.dp.ua.
13.140.194.in-addr.arpa.    PTR  gw.komtek.dp.ua.

Спецификация BIND

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

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

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

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

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

2. domain <Domain> Определяет домен по умолчанию для данного сервера имен. Пример: domain komtek.dp.ua

3. primary <Domain> <FileName> Показывает, что сервер имен является первичным для домена <Domain> и что база домена хранится в файле <FileName>. Пример: primary komtek.dp.ua /usr/named.data

4. secondary <Domain> <IP-1> [<IP-2>...] <FileName> Указывает, что данный сервер имен является вторичным для домена <Domain>. Первичные серверы расположены по IP-адресам <IP-1>, <IP-2> и т. д. Данный вторичный сервер запрашивает по порядку первичные серверы и копирует полученную с первого ответившего первичного сервера информацию в файл <FileName>. Пример: secondary komtek.dp.ua 192.168.1.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-провайдера. Доменное имя можно зарегистрировать через Internet-провайдера.

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

Рассматриваемая локальная сеть состоит из двух IP-сетей класса C: 194.170.12.0 и 194.170.13.0. Допустим, эти сети образуют один домен komtek.dp.ua.

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.

Ниже представлены состав и содержимое базы DNS для первичного сервера имен srv1.komtek.dp.ua и для вторичного сервера srv2.komtek.dp.ua.

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

; /etc/named.boot
directory  /etc
domain   komtek.dp.ua
primary  komtek.dp.ua             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
cache    .                        named.ca


; /etc/named.data
@         IN  SOA    srv1.komtek.dp.ua.  root.mail.komtek.dp.ua.  (
                        970308
                        3600
                        600
                        3600000
                        86400  )
                 NS     srv1.komtek.dp.ua.
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.komtek.dp.ua.
srv2             A      194.170.13.3
                 HINFO  IBM-PC  UNIX
komtek.dp.ua.    MX  10  mail
*.komtek.dp.ua.  MX  0   mail.komtek.dp.ua.


; /etc/named.rev1
@         IN  SOA    srv1.komtek.dp.ua.  root.mail.komtek.dp.ua.  (
                        960218
                        3600
                        600
                        3600000
                        86400  )
                          NS     srv1.komtek.dp.ua.
1                         PTR    gw.komtek.dp.ua.
12.170.194.in-addr.arpa.  PTR    gw.komtek.dp.ua.
2                         PTR    srv1.komtek.dp.ua.
3                         PTR    host1.komtek.dp.ua.
4                         PTR    host2.komtek.dp.ua.


; /etc/named.rev2
@         IN  SOA    srv1. komtek.dp.ua..  root.mail. komtek.dp.ua. (
                        970205
                        3600
                        600
                        3600000
                        86400  )
                          NS     srv1.komtek.dp.ua.
1                         PTR    host3.komtek.dp.ua.
2                         PTR    mail.komtek.dp.ua.
3                         PTR    srv2.komtek.dp.ua.
4                         PTR    gw.komtek.dp.ua.
13.170.194.in-addr.arpa.  PTR    gw.komtek.dp.ua.


; /etc/named.local
@     IN  SOA    srv1.komtek.dp.ua.  root.mail.komtek.dp.ua.  (
                        960124
                        3600
                        600
                        3600000
                        86400  )
                          NS     srv1.komtek.dp.ua.
1                         PTR    localhost


; /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 НА ВТОРИЧНОМ СЕРВЕРЕ SRV

; /etc/named.boot
directory  /etc
domain    komtek.dp.ua
secondary komtek.dp.ua  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
; выход в Internet
cache    .                        named.ca


; /etc/named.local
@     IN  SOA    srv2.komtek.dp.ua.  root.mail.komtek.dp.ua.  (
                        960124
                        3600
                        600
                        3600000
                        86400  )
          NS     srv2.komtek.dp.ua.
1         PTR    localhost


; /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

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

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

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

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

К содержанию Вперед Назад

Контроль за системой адресации

К содержанию Вперед Назад

Контроль за системой адресации

Управление адресацией и сервером имен систем по протоколу IP достаточно сложно и часто приводит к ошибкам. Двойные идентификаторы и ошибки конфигурации приводят к простоям и дорогостоящей диагностической работе. Административные системы построенные на ручном конфигурировании очень трудоемки. Поэтому автор посчитал необходимым уделить этой проблеме особое внимание.

Постановка задачи

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

По этим причинам, управление адресами IP и сервером имен (DNS) может стать очень трудоЈмким для администраторов. Ранее усложняло эту проблему и тот факт, что не имелось каких-либо автоматизированных инструментальных средств для избежания дублирования IP адресов и синхронизации адресов IP с сервером имен. Поэтому для удовлетворения этой потребности в 4-й версии AIX встроена поддержка динамического протокола конфигурации узлов (DHCP), и динамического сервера имен (DDNS).

DHCP Краткий обзор

При традиционном обслуживании сетевой среды управляемой вручную, всякий раз, когда пользователь перемещается и повторно соединяет свою систему по протоколу TCP/IP, администратор сети должен назначить для этого пользователя новый адрес IP, заданный по умолчанию gateway, сервер имен, и другие требуемые параметры. Затем пользователь должен вручную ввести эти параметры в свой файл конфигурации TCP/IP и перезапустить стек протокола. Этот ручной процесс - и он чаще всего приводит к ошибкам и фактически, ошибки администратора или пользователя в этом процессе, являются источником более 50 процентов ошибок конфигурации TCP/IP.

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

Как работает модель DHCP

Решение DHCP основано на двухуровневой модели клиент/сервер. Узел сети должен быть dhcp-д