Хант Крэйг. TCP/IP Сетевое администрирование

Подождите немного. Документ загружается.

262

Глава 8. Настройка DNS

ся примеры таких файлов. Если в вашей системе их нет, возьмите файлы на-

стройки с работающего сервера имен.

Оставшиеся файлы настройки named более сложны, но и менее востребованы,

если брать общее число серверов имен. Полный набор файлов настройки ну-

жен лишь основному серверу, а в каждой зоне основной сервер только один.

Файл обратной зоны

Файл обратной зоны весьма схож строением с файлом named.local. Оба фай-

ла преобразуют IP-адреса в имена узлов, поэтому оба содержат записи PTR.

Файл 172.16.rev в нашем случае является файлом обратной зоны для домена

16.172.in-addr.arpa. Администратор домена создает этот файл на узле crab,

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

серверу crab.

Как и в прочих файлах зон, в качестве первой RR-записи в файле обратной

зоны выступает запись SOA. Символ @ в поле имени SOA-записи является

ссылкой на текущую зону. Поскольку данный файл зоны не содержит ди-

рективы $ORIGIN, явным образом задающей текущую зону, текущей зоной

является домен 16.172.in-addr.arpa, обозначенный оператором zone этого

файла в файле named.conf:

Символ @ в SOA-записи позволяет оператору zone определять домен для

файла зоны. Точно такая же запись SOA используется для всех зон; она всег-

Настройка демона named 263

да ссылается на верное имя домена, поскольку ссылается на домен, опреде-

ленный для текущей зоны в файле named.conf. Измените имя узла (crab.wro-

u thebook.com.) и почтовый адрес руководителя (jan.crab.wrotethebook.com.),

и записью можно будет пользоваться в любом файле зоны.

NS-записи, следующие за SOA-записью, определяют серверы имен домена.

Как правило, серверы имен перечисляются сразу после SOA-записи с пусты-

ми полями имен. Вспомните, что пустое поле имени означает, что запись на-

ходится в области действия последнего упомянутого доменного имени. Та-

ким образом, последующие NS-записи относятся к тому же домену, что и за-

пись SOA.

Основу файла обратной зоны составляют записи PTR, поскольку они исполь-

зуются для преобразования адресов в имена узлов. Записи PTR в нашем при-

мере обеспечивают преобразование адреса в имя для узлов 12.1, 12.2, 12.3,

12.4 и 2.1 сети 172.16. Поскольку значения в полях имен PTR-записей не за-

канчиваются точкой, они интерпретируются относительно текущего домена.

Например, значение 3.12 интерпретируется как 3.12.16.172.in-addr.arpa. В

поле данных PTR-записи содержится абсолютное имя узла, что предотвраща-

ет интерпретацию имени в качестве относительного для текущего имени до-

мена и потому оканчивается точкой. Используя информацию в этой PTR-за-

ниси, named преобразует 3.12.16.172.in-addr.arpa в horseshoe.wrotethebook.com.

Последние две строки файла содержат дополнительные NS-записи. Как лю-

бой другой домен, in-addr.arpa может содержать поддомены. Две последние

NS-записи реализуют как раз создание поддомена; они указывают узлы hor

seshoe и linuxuser в качестве серверов имен для поддомена 6.16.172.in-addr.ar-

pa. Любой запрос, касающийся информации поддомена 6.16.172.in-addr.ar-

pa, перенаправляется к этим серверам. NS-записи, указывающие на серверы

поддомена, должны быть размещены в домене более высокого уровня, преж-

де чем к поддомену можно будет обращаться.

Доменные имена - не то же самое, что IP-адреса, и структура этих сущнос-

тей различна. Когда IP-адрес преобразуется в доменное имя in-addr.arpa, че-

тыре байта адреса интерпретируются в качестве четырех компонентов одно-

го имени. В действительности IP-адрес - это 32 последовательных бита, а не

четыре отдельных байта. Подсети разделяют адресное пространство IP, а

маски подсетей - побитовые, то есть не ограничены рамками отдельных бай-

тов. Ограничение поддоменов рамками байтов делает их менее гибкими, чем

подсети, которые эти поддомены должны поддерживать. В нашем примере

домен in-addr.arpa делегирует поддомен по границе байта, то есть каждый

байт адреса считается самостоятельным «именем». Таков простейший меха-

низм делегирования обратных поддоменов, но в отдельных случаях он мо-

жет оказаться недостаточно гибким.

Приведенный ранее пример использования директивы $GENERATE позво-

ляет сделать делегирование обратных доменов более гибким. Директива

$GENERATE создала CNAME-записи, отображающие диапазон адресов до-

мена in-addr.arpa в другой домен, с более гибкими правилами для доменных

имен. Доменные имена in-addr.arpa должны состоять из четырех числовых

264 Глава 8. Настройка DNS

Эти четыре команды $GENERATE выполняют отображение 256 численных

имен домена 30.168.192.in-addr.arpa в четыре других домена, по 64 числен-

ных имени в каждом. Когда удаленный сервер запрашивает PTR-запись для

52.30.168.192.in-addr.arpa, он получает уведомление, что каноническое имя

этого узла - 52.lst64.30.168.192.in-addr.arpa, и что следует запрашивать за-

пись-указатель этого узла у сервера домена lst64.30.168.192.in-addr.arpa. По

сути дела, директива $GENERATE позволяет разделить один домен 30.168.

192.in-addr.arpa на ряд доменов. После разделения каждый из фрагментов

может быть делегирован произвольному серверу имен.

Делегирование поддоменов может усложнить работу с обратными домена-

ми.

Однако в большинстве случаев файл обратной зоны проще, чем файл

прямого отображения зоны.

Файл прямого отображения зоны

Файл прямого отображения зоны содержит большую часть доменной инфор-

мации. Данный файл обеспечивает преобразование имен узлов в IP-адреса,

поэтому содержит преимущественно А-записи, но также записи типов MX,

CNAME и других. Файл зоны, как и файл обратной зоны, создается только

для основного сервера имен, все прочие серверы получают информацию от

основного.

Еще более сложные примеры приводятся в упоминавшейся ранее книге Альбитда

и Ли «DNS и BIND», 4-е издание.

полей, соответствующих четырем байтам IP-адреса, и строки in-addr.arpa.

Мы связали эти имена с более длинными и более гибкими именами посредст-

вом директивы $GENERATE. Вот еще один (более серьезный) пример рабо-

ты $GENERATE:

Настройка демона named 265

Подобно файлу обратной зоны, файл зоны начинается с записи SOA и не-

скольких записей NS, которые определяют домен и серверы домена; но при

этом файл зоны содержит более представительный набор RR-записей. Ис-

пользуя приведенный пример, рассмотрим каждую из этих записей в поряд-

ке их следования.

Первая МХ-запись обозначает почтовый сервер домена. Ее смысл: узел crab

является почтовым сервером домена wrotethebook.com и имеет значение

предпочтения 10. Почтовые сообщения с адресом вида user@wrotethebo-

ok.com передаются узлу crab для доставки. Разумеется, успешная доставка

почты узлом crab подразумевает его настройку в качестве почтового сервера.

Запись MX - лишь часть процесса настройки. Настройка sendmail описана в

главе 10.

Вторая запись MX обозначает узел horseshoe в качестве почтового сервера

домена wrotethebook.com со значением предпочтения 20. Значения предпоч-

тений позволяют создавать указатели на альтернативные почтовые серверы.

266

Глава 8. Настройка DNS

Чем ниже значение предпочтения, тем более предпочтителен сервер. Следо-

вательно, две приведенные МХ-записи сообщают следующее: «Почту домена

wrotethebook.com доставлять через узел crab; если crab не доступен, попробо-

вать доставить через horseshoe». Значения предпочтений позволяют созда-

вать указатели на резервные серверы, а не полагаться на единственный поч-

товый сервер. Если основной почтовый сервер по каким-либо причинам не-

доступен, почта домена передается одному из резервных серверов.

Приведенные МХ-записи осуществляют перенаправление почты, адресован-

ной в домен wrotethebook.com, но почта для user@jerboas.wrotethebook.com

по-прежнему будет передаваться напрямую узлу jerboas.wrotethebook.com,

а не crab или horseshoe. Данный вариант настройки позволяет использовать

упрощенную адресацию вида user@wrotethebook.com, но по-прежнему разре-

шает выполнять прямую доставку почты отдельным узлам.

Первая А-запись в данном примере определяет адрес узла localhost, выпол-

няя задачу, противоположную той, что возложена на соответствующую за-

пись PTR из файла named.local. Адресная запись позволяет пользователям

домена wrotethebook.com набрать имя localhost и получить доступ к системе

по адресу 127.0.0.1 при помощи локального сервера имен.

Следующая А-запись определяет IP-адрес узла crab, который является ос-

новным сервером этого домена. За этой адресной записью следует запись

CNAME, определяющая имя loghost в качестве псевдонима узла crab.

За адресной записью для узла rodent следует МХ-запись и CNAME-запись.

(Обратите внимание: записи, относящиеся к одному узлу, сгруппированы.

Такое строение файла зоны встречается чаще всего.) МХ-запись узла rodent

направляет всю почту, адресованную user@rodent.wrotethebook.com, узлу

crab. Наличие этой записи объясняется тем, что первая МХ-запись перена-

правляет почту только в том случае, если она адресована user@wrotethebo-

ok.com. Если требуется перенаправление почты, адресованной узлу rodent,

для него следует создать дополнительную МХ-запись.

Поле имени CNAME-записи содержит псевдоним официального имени узла.

Официальное, или каноническое, имя содержится в поле данных этой запи-

си. Приведенные CNAME-записи позволяют обращаться к узлу crab по име-

ни loghost, а к узлу rodent - по имени mouse. Псевдоним loghost - это обоб-

щенное имя узла, позволяющее направлять вывод демона syslogd узлу crab.

Псевдонимы узлов не следует использовать в других RR-записях.

Напри-

мер, не используйте псевдоним в качестве имени почтового сервера в МХ-за-

писи. Напротив, используйте только каноническое (официальное) имя,

определенное в адресной записи.

В каждом конкретном случае файл зоны может быть гораздо больше, чем

только что рассмотренный пример, но будет содержать в большинстве случа-

Более подробно обобщенные имена описаны в главе 3.

Дополнительные сведения о применении записи CNAME в файлах данных зоны

содержатся в приложении С.

•

Настройка демона named

267

ев преимущественно подобные записи. Если доступны имена и адреса узлов

домена, вы обладаете достаточным объемом информации для создания фай-

лов настройки named.

Управление процессом named

После создания файла named.conf и необходимых файлов зон запустите named,

named обычно запускается в процессе загрузки системы - из загрузочного сце-

нария. В системе Solaris 8 named запускается сценарием /etc/init.d/inetsvc.

В системе Red Hat Linux - сценарием /etc/rc.d/init.d/named. Сценарий Red

Hat может выполняться из командной строки и имеет ряд необязательных

аргументов. Например, в системе Red Hat для останова сервера имен может

применяться следующая команда:

# /etc/rc.d/init.d/named stop

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

# /etc/rc.d/init.d/named start

Загрузочные сценарии замечательно работают, но более эффективным инст-

рументом управления процессом named является программа ndc (named con-

trol). Она поставляется в составе BIND 8 и предоставляет набор функций, об-

легчающих управление демоном службы имен. Аналогичный инструмент в

BIND 9 называется

rndc.

В табл. 8.3 перечислены параметры ndc.

Таблица 8.3. Параметры ndc

Параметр

Назначение

status Отображает состояние процесса named

dumpdb

Записывает образ кэша в файл named_dump.db

reload Перезагружает сервер имен

stats Записывает статистику в файл named.stats

trace Включает запись отладочной информации в файл named.run

notrace Отключает запись отладочной информации и закрывает файл named.run

querylog

Переключает регистрацию запросов. При включенной регистрации за-

просов поступающие запросы фиксируются посредством демона syslogd

start

Запускает named

stop Останавливает named

restart Останавливает текущий процесс named и запускает новый

Данный файл сохраняется в каталоге, определенном параметром directory в файле na-

med.conf.

На момент написания книги команды status, trace и restart еще не реализованы

в rndc.

268

Глава 8. Настройка DNS

При первом запуске named обращайте внимание на сообщения об ошибках,

named заносит сообщения об ошибках в файл messages.

Как только демон na-

med заработает, воспользуйтесь командой

nslookup,

чтобы обратиться к серве-

ру и убедиться, что он предоставляет корректные сведения.

Работа с nslookup

nslookup - это инструмент отладки, который входит в состав пакета BIND.

Программа позволяет пользователю напрямую обращаться к серверу имен с

запросами и получать любую информацию, хранимую в распределенной ба-

зе данных DNS. Команда nslookup помогает определить факт работоспособ-

ности сервера и корректность его настройки, а также запросить информа-

цию, которой владеют удаленные серверы.

Программа nslookup позволяет выполнять запросы в диалоговом режиме либо

при помощи параметров командной строки. В следующем примере nslookup

применяется для создания запроса IP-адреса определенного узла:

Данный файл хранится в каталоге /usr/adm/messages нашей системы Solaris и в

каталоге / var/log /messages нашей системы Red Hat. В вашей системе он может

храниться в ином месте: сверьтесь с документацией.

Пользователь просит программу nslookup отобразить адрес узла crab.wrotet-

hebook.com. nslookup отображает имя и адрес сервера, который использовал-

ся для получения ответа, а затем и собственно ответ. Удобная возможность,

однако nslookup чаще используется в диалоговом режиме.

В диалоговом режиме работы заключена истинная сила

nslookup.

Чтобы при-

ступить к работе в диалоговом режиме, выполните команду nslookup без ар-

В данной последовательности команд предполагается наличие некоторой па-

узы между остановом старого процесса named и запуском нового. Чтобы пере-

запустить процесс named действительно быстро, воспользуйтесь параметром

restart:

Параметры ndc легко понять и применить. Следующие команды останавли-

вают, а затем запускают процесс named:

Работа с nslookup

269

Смысл словосочетания «все доступные» изменяется в зависимости от типа узла,

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

вернет полный набор записей. Некомпетентный сервер, кэширующий информа-

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

леко не полным.

гументов. Завершается диалоговый сеанс сочетанием клавиш <Ctrl>+<D>

ID) или набором команды exit в приглашении

nslookup.

В качестве диалого-

вого сеанса предшествующий запрос выглядит следующим образом:

По умолчанию nslookup выполняет запрос А-записей, но при помощи коман-

ды set type можно запросить любой тип RR-записей либо выполнить специ-

альный запрос с типом ANY. ANY позволяет получить все доступные RR-за-

писи для конкретного узла.

В следующем примере выполняется поиск МХ-записей для узлов crab и ro-

dent. Обратите внимание, что указание типа запроса действует на все после-

дующие запросы - автоматического возврата к типу А не происходит. Чтобы

выполнить сброс типа запроса, необходима еще одна команда set type.

Сервер, к которому обращены запросы, можно изменить при помощи коман-

ды

server.

Данная возможность особенно полезна в случае необходимости об-

270

Глава 8. Настройка DNS

ратиться за информацией напрямую к компетентному серверу. В следую-

щем примере выполняется именно такая операция. Фактически он содер-

жит ряд интересных команд:

• Во-первых, мы выполняем команду set type=NS и получаем NS-записи до-

мена zoo.edu.

• Исходя из полученной информации, мы выбираем сервер и при помощи

команды

serveг

предписываем nslookup обращаться к этому серверу.

• Затем при помощи команды set domain определяем домен по умолчанию -

zoo.edu. nslookup использует доменные имена по умолчанию для дополне-

ния имен узлов в запросах точно так же, как это делает клиент DNS для

доменного имени по умолчанию, определенного в файле resolv.conf.

• Мы переустанавливаем тип запроса в ANY. Если этого не сделать, nslookup

будет по-прежнему искать NS-записи.

• Наконец, мы запрашиваем информацию об узле tiger.zoo.edu. Поскольку

значение домена по умолчанию - zoo.edu, мы набираем в приглашении

nslookup только имя узла - tiger.

А вот и сам пример:

Работа с nslookup

271

Из соображений безопасности многие серверы имен не реагируют на команду Is.

Реализация ограничений на передачу зоны описана в приложении С (параметр

allow-transfer).

Приведенные примеры показывают, что nslookup позволяет:

• Запрашивать RR-записи любого из стандартных типов

• Напрямую обращаться к компетентным серверам доменов

Последний пример демонстрирует, как загрузить целый домен с компетент-

ного сервера и изучить его в локальной системе. Команда Is запрашивает пе-

редачу зоны и отображает содержимое полученной зоны.

Если в файле зоны

много строк, перенаправьте вывод в файл и воспользуйтесь командой view,

чтобы изучить его содержимое, (view сортирует файл и отображает его стро-

ки посредством Unix-команды more.) Сочетание Is и view полезно при поиске

определенного удаленного узла. В данном примере команда Is инициирует

передачу зоны big.com и сохраняет информацию в файле temp.file. Для про-

смотра temp.file применяется view.