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.uaHINFO (информация о хосте)
Запись с ресурсом типа 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 AIXMX (почтовый шлюз)
Так как не на всех хостах запущен сервер
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
должна стоять первой в зоне управления.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
Контроль за системой адресации
Управление адресацией и сервером имен
систем по протоколу 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-доступным. Процесс можно описать
следующим образом:
1. Клиент вводит сеть IP в состоянии
инициализации и передает по
широковещательное сообщение по всем
доступным сетям с запросом на получение IP
адреса и описанием требований к соединению
(DHCPDISCOVER).
2. Агент ретрансляции BOOTP обнаруживает это
сообщение и передает его всем доступным
серверам DHCP для обработки.
3. Каждый сервер DHCP отвечает на запрос
клиента с сообщением предложения (DHCPOFFER),
которое состоит из доступного адреса IP и
информации конфигурации на основе
предопределенных администратором
требований к соединению для этого узла.
4. Клиент получает все ответы от серверов и
определяет наилучшее предложение
используя встроенный алгоритм.
5. Затем клиент отправляет выбранному
серверу запрос на получение адреса и информации
конфигурации (DHCPREQUEST).
6. В заключение, выбранный сервер DHCP
посылает в сеть сообщение о подтверждении
получения обслуживания (DHCPACK). После этого
все другие сервера, которые не были выбраны,
освобождают адреса IP, которые они
предложили клиенту и возвращаются в режим
опроса сети, ожидая следующий пакет DHCPDISCOVER.
7. После того, как сервер DHCP получает
подтверждение от клиента DHCP, сервер
автоматически модифицирует сервер имен DNS в
соответствии с этим адресом IP.
8. Так как адрес IP, назначенный клиенту
выдан только временно (арендуется) он должен
быть периодически возобновляться, клиент
стартует таймер и устанавливает его на
половину продолжительности арендного
договора.
9. Когда время таймера истекает, клиент
посылает DHCPREQUEST пакет серверу, запрашивая
обновление "арендного договора".
10. Если клиент не получает никакого ответа
от сервера, то он ждет до истечения трех
четвертей продолжительности "арендного
договора" и затем передает DHCPREQUEST пакет
ко всей сети, чтобы запросить обслуживание
у нового сервера. Этот процесс гарантирует,
что сервис DHCP продолжается без прерывания.
Продолжительность времени "арендного
договора" устанавливается
администратором, когда он конфигурирует
сервер DHCP. Вся клиентура DHCP внутри сети или
подсети имеет одно и то же время "арендного
договора"; однако, пользователи, в случае
необходимости, могут отменять заданный по
умолчанию промежуток "арендного
договора".
DHCP - протокол прикладного уровня
основанный на BOOTP, который выполняется при
помощи протокола UDP. Если размер сети
требует обслуживания DHCP во многих
связанных сетях межсетевой маршрутизатор
должен поддерживать возможность передачи
сообщений агента ретрансляции BOOTP. Как
указано выше, этот агент ретран-ляции