WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 3 | 4 || 6 | 7 |   ...   | 9 |

«DNS and BIND Fourth Edition PaulAlbitz and Cricket Liu O'REILLY DNS и BIND Четвертое издание ПолАльбитц и Крикет Ли Пол Альбитц, Крикет Ли DNS и BIND Перевод М Зислиса Главный редактор А Галунов ...»

-- [ Страница 5 ] --

284 Глава 9. Материнство Но этих двух записей недостаточно. Видите, в чем проблема? Как мо жет DNS-сервер за пределами fx.movie.edu производить поиск инфор мации из fx.movie.edu? Ведь DNS-сервер movie.edu направит внешний сервер к DNS-серверам, авторитативным для зоны fx.movie.edu? Разу меется, но NS-записи в файле db.movie.edu содержат только имена DNS-серверов зоны fx.movie.edu. Серверу-иностранцу понадобятся IP адреса DNS-серверов fx.movie.edu, чтобы послать им запросы. Кто мо жет дать ему эти адреса? Только DNS-серверы зоны fx.movie.edu. Что было раньше - курица или яйцо?

Вот решение: адреса DNS-серверов fx.movie.edu следует включить в файл данных зоны movie.edu. Такая информация не принадлежит, строго говоря, зоне movie.edu, но она необходима, чтобы работало деле гирование для fx.movie.edu. Разумеется, если DNS-серверы fx.mo vie.edu находились бы не в пределах fx.movie.edu, эта информация называемая связующими записями (glue records) - не потребовалась бы. Сервер-иностранец нашел бы требуемые адреса, сделав несколько запросов к другим DNS-серверам.

Итак, в комплекте со связующими записями, фрагмент файла db.mo vie.edu выглядит следующим образом:

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

DNS-сервер BIND версии 4.9 или более поздней автоматически игно рирует связующие записи, которые не являются строго необходимы ми, и заносит в log-файл syslog сообщение о том, что записи были про игнорированы. Так, если бы у нас была NS-запись для movie.edu, ука зывающая на внешний DNS-сервер, ns-l.isp.net, и мы сделали бы ошибку, включив адресную запись для этого сервера в файл db.mo vie.edu на первичном мастер-сервере DNS зоны movie.edu, то увидели бы примерно такое сообщение в выводе syslog:

Если бы мы работали с DNS-сервером версии более ранней, чем 4.9, и он, по ошибке, включил бы ненужные связующие записи в данные Заводим детей: создание поддоменов при передаче данных DNS-серверу более поздней версии, мы могли бы увидеть примерно следующее сообщение в резервной копии файла данных зоны:

Обратите внимание, что лишняя адресная запись закомментирована.

И помните, что связующие записи должны быть актуальными. Если bladerunner обзаводится новым сетевым интерфейсом - а значит, и но вым IP-адресом - следует добавить еще одну адресную запись в связу ющие данные.

Мы могли бы также создать псевдонимы для любых узлов, осущест вляющих переезд из movie.edu в fx.movie.edu. К примеру, если необхо димо переместить plan9.movie.edu (сервер, хранящий важную библи отеку свободно доступных алгоритмов специальных эффектов) в зону fx.movie.edu, следует создать псевдоним в movie.edu, связывающий старое доменное имя с новым:

Это позволит пользователям вне зоны movie.edu получать доступ к уз лу plan9, используя даже прежнее доменное имя plan9.movie.edu.

Не следует размещать какую-либо информацию о доменных именах зоны fx.movie.edu в файле db.movie.edu. Псевдоним plan9 в действи тельности принадлежит зоне movie.edu (запись связана с именем plan9.movie.edu), так что ему место в файле db.movie.edu. С другой сто роны, псевдоним p9.fx.movie.edu для узла plan9.fx.movie.edu принадле жит зоне fx.movie.edu и должен содержаться в файле db.fx.movie.edu.

Случись администратору поместить в файл данных зоны «чужую» за пись, DNS-сервер BIND 4.9 или более поздней версии проигнорирует ее, как показано в примере с ненужными связующими записями. Бо лее старый DNS-сервер может загрузить запись в кэш и даже помес тить ее в свои авторитативные данные, но поскольку такое поведение приводит к непредсказуемым результатам и не реализовано в более но вых версиях BIND, лучше всего придерживаться правильного спосо ба, даже если этот способ не навязывается программным пакетом.

Делегирование зоны in-addr.arpa Мы чуть не забыли делегировать зону 254.253.192.in-addr.arpa! Здесь сложностей чуть больше, чем при делегировании fx.movie.edu, по скольку администрирование родительской зоны нам недоступно.

Во-первых, необходимо узнать, в какую родительскую зону входит 254.253.192.in-addr.arpa и кто занимается сопровождением этой зоны.

Получение этой информации может быть связано с сыскным делом, но мы уже рассматривали этот вопрос в главе 3 «С чего начать?».

286 Глава 9. Материнство Выясняется, что родительской зоной для 254.253.192.in-addr.arpa яв ляется in-addr.arpa. Если подумать, в этом есть определенный смысл.

Администраторы in-addr.arpa не видят особого смысла в делегирова нии зон 253.192.in-addr.arpa и 192.in addr.arpa отдельным инстанци ям, поскольку сети вроде 192.253.253/24 и 192.253.254/24 не имеют ничего общего, если 192/8 или 192.253/16 не является одним боль шим CIDR-блоком. Ими могут заведовать совершенно не связанные между собой организации.

Возможно читатели помнят (из главы 3), что сопровождением зоны in addr.arpa занимается организация ARIN (American Registry of Inter net Numbers). Если бы вы этого не помнили, то могли бы воспользовать ся программой nslookup для поиска контактного адреса из SOA-записи зоны in-addr.arpa, как мы демонстрировали в той же самой главе. Нам осталось только воспользоваться веб-интерфейсом «Modify Tool» (Ин струмент регистрации изменений) по адресу http://www.arin.net/cgi biп/amt.pl, чтобы запросить регистрацию зоны обратного отображения.

Еще один вторичный DNS-сервер movie.edu Если лаборатория специальных эффектов станет достаточно большой, возможно будет иметь смысл разместить вторичный DNS-сервер то vie.edu в сети 192.253.254/24. В этом случае разрешение большей доли DNS-запросов, создаваемых узлами fx.movie.edu, будет происходить локально. Кажется логичным сделать один из существующих DNS серверов зоны fx.movie.edu вторичным сервером movie.edu - так мы сможем более полно использовать уже существующий сервер, вместо того чтобы создавать еще один.

Мы решили сделать вторичным DNS-сервером movie.edu узел blade runner. Это не помешает работе узла bladerunner в качестве первично го мастер-сервера DNS зоны fx.movie.edu. Единственный DNS-сервер, если снабдить его достаточным количеством памяти, может быть авто ритативным буквально для тысяч зон. Один и тот же DNS-сервер мо жет выступать для одних зон в качестве первичного, а для других в ка честве вторичного. Изменения в настройке минимальны: к файлу named.conf узла blade runner добавляется один оператор, который сообщает серверу named, что следует загружать зону movie.edu с IP-адреса первичного мастер сервера DNS movie.edu, который называется terminator.movie.edu.

Содержимое файла named.conf:

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

Поддомены доменов in-addr.arpa Если используется DNS-сервер BIND 4, то содержимое файла па med.boot:

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

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

288 Глава 9. Материнство Формирование подсети на границе октета Поскольку в Университете кинематографии всего три сети /24 (класса С), по одной на сегмент, нет особой необходимости в формировании подсетей. Однако наш университет-побратим, Altered State, имеет сеть класса В, 172.20/16. Сеть этого университета разделена на подсети между третьим и четвертым октетом IP-адреса;

то есть маска подсети 255.255.255.0. Этот университет уже создал несколько поддоменов в своем домене altered.edu, в частности fx.altered.edu (признаемся, мы просто следовали их примеру), makeup.altered.edu и foley.altered.edu.

Поскольку каждый из этих факультетов имеет собственную подсеть (факультет Spesial Effects - подсеть 172.20.2/24, факультет Makeup 172.20.15/24, a Foley - 172.20.25/24), они хотели бы соответствую щим образом разделить и пространство имен in-addr.arpa.

Делегирование поддоменов in-addr.arpa ничем не отличается от деле гирования поддоменов доменов прямого отображения. В файле дан ных зоны db.l 72.20 университету Altered State понадобится создать примерно такие записи:

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

Несколько важных замечаний: администраторы Altered State могли использовать в поле имени владельца записи только третий октет под сети, поскольку суффикс по умолчанию для этого файла - 20.172.in addr.arpa. При этом им пришлось использовать в правой части NS-за писей абсолютные доменные имена, чтобы избежать добавления к ним суффикса по умолчанию. И они не добавили связующие записи, по скольку имена DNS-серверов, которым делегируется зона, не заканчи ваются доменным именем этой зоны.

Формирование подсети не на границе октета Что делать с сетями, подсети в которых формируются не на границах октетов, как в случае сети /24 (сети класса С)? В таких случаях можно производить делегирование по границам подсетей. Это приводит к од ной из двух ситуаций: существует несколько подсетей в каждой зоне in-addr.arpa либо существует много зон in-addr.arpa для каждой подсе ти. Оба варианта достаточно неприятные.

Поддомены доменов in-addr.arpa Сети классов А и В Возьмем случай сети /8 (сеть класса А) - 15/8, подсети в которой фор мируются маской 255.255.248.0 (13-битное поле подсети и 11-битное поле узла, 8192 подсети по 2048 узлов). В таком случае, скажем, сеть 15.1.200.0 охватывает диапазон адресов с 15.1.200.0 по 15.1.207.255.

Следовательно, делегирование для одного этого поддомена в db.15, файле данных зоны для 15.in-addr.arpa, может выглядеть следующим образом:

Для одной подсети - довольно объемная информация о делегировании!

К счастью, начиная с версии 8.2 серверы BIND реализуют поддержку директивы $GENERATE. $GENERATE позволяет создавать группу RR-записей, которые отличаются только численным итератором. К примеру, 16 только что перечисленных NS-записей можно создать сле дующей парой директив $GENERATE:

Синтаксис оператора довольно прост: DNS-сервер создает набор запи сей из оператора $GENERATE, заменяя символ доллара ($) поочеред но числами из диапазона, определенного в первом поле оператора.

Сети класса С Рассмотрим случай сети /24 (класса С), например 192.253.254/24, в которой формирование сетей производится на основе маски 255.255.255.192. В данном случае существует единственная зона in addr.arpa, 254.253.192.in-addr.arpa, которая соответствует подсетям 192.253.254.0/26, 192.253.254.64/26, 192.253.254.128/26 и 192.253.254.192/26. Это может быть проблемой, если необходимо раз решить различным организациям сопровождение информации обрат 290 Глава 9. Материнство ного отображения для этих сетей. Проблема решается одним из трех некрасивых способов.

Решение Первое решение: администрировать зону 254.253.192.in-addr.arpa в качестве единой сущности, даже не думая о делегировании. Для этого требуется сотрудничество администраторов четырех подсетей либо применение инструмента вроде Webmin (http://www.webmin.com/web min), который позволит каждому из администраторов сопровождать собственный раздел данных.

Решение Второе решение: произвести делегирование на четвертом октете. Это даже хуже, чем делегирование для сети /8, которое мы уже продемон стрировали. Нужна хотя бы пара NS-записей на каждый IP-адрес в файле db.192.253.254. Это выглядит примерно так:

и так далее, вплоть до 254.254.253.192.in-addr.arpa.

Можно существенно сократить объем, воспользовавшись оператором $GENERATE:

Поддомены доменов in-addr.arpa Конечно, подразумевается, что в файле named.conf на узле nsl.foo.com присутствует следующий фрагмент:

Если же на nsl.foo.com используется BIND 4, то следующие инструк ции присутствуют в файле named.boot:

а в файле db. 192.253.254.1 - одна-единственная PTR-запись:

Обратите внимание, что эта PTR-запись связана с доменным именем зоны, поскольку доменное имя зоны соответствует всего лишь одному IP-адресу. Теперь, получая запрос PTR-записи для имени 1.254.253.192.in-addr.arpa, DNS-сервер зоны 254.253.192.inaddr.arpa направляет клиент к серверам nsl.foo.com и ns2.foo.com, которые воз вращают именно эту, единственную в зоне, PTR-запись.

Решение И наконец, существует более умный способ, избавляющий нас от необ ходимости сопровождать отдельный файл данных зоны для каждого IP-адреса.1 Организация, отвечающая за всю сеть /24, создает CNAME записи для каждого из доменных имен зоны;

эти CNAME-записи ука зывают на доменные имена в новых поддоменах, которые, в свою оче Впервые мы увидели эту идею в конференции сотр.protocols.,tcp-ip.domains в изложении Глена Херрмансфельдта (Glen Herrmansfeldt) из КалТех. В настоящее время способ стандартизирован в документе RFC 2317.

292 Глава 9. Материнство редь, делегируются различным DNS-серверам. Новые поддомены могут иметь практически любые имена, например 0-63, 64-127,128-191 и 192 255, четко показывающие диапазоны адресов, для которых произво дится обратное отображение в каждом из доменов. При этом каждый поддомен содержит только PTR-записи для указанного диапазона.

Фрагмент файла db.192.253.254:

И опять можно использовать $GENERATE для сокращения:

Файл данных для зоны 0-63.254.253.192.in-addr.arpa (db.192.253.254.0 63) вполне может содержать только PTR-записи для IP-адресов с 192.253.254.1 по 192.253.254.63.

Фрагмент файла db.l 92.253.254.0-63:

Заботливые родители Работа этого варианта не очень прозрачна, поэтому рассмотрим про цесс несколько подробнее. Клиент запрашивает у локального DNS-cep вера PTR-запись для 1.254.253.192.in-addr.arpa. Локальный DNS-cep вер в итоге добирается до DNS-сервера 254.253.192.in-addr.arpa, кото рый возвращает CNAME-запись, сообщающую, что 1.254.253.192.in addr.arpa в действительности является всего лишь псевдонимом для 1.0-63.254.253.192.in-addr.arpa и что PTR-запись связана с последним именем. Ответ также содержит NS-записи, которые говорят локально му DNS-серверу, что авторитативными серверами для 0 63.254.253.192.in-addr.arpa являются nsl.foo.com и ns2.foo.com. Ло кальный DNS-сервер посылает запрос PTR-записи для 1. 63.254.253.192.in-addr.arpa - DNS-серверу nsl.foo.com или ns2.foo.com, и получает искомое.

Заботливые родители Теперь, разобравшись с делегированием DNS-серверам fx.movie.edu, мы - как заботливые родители - должны проверить делегирование с помощью программы host. Как? Мы еще не поделились с читателями программой host? Версия host для Unix-систем доступна для аноним ного FTP-копирования с сервера ftp.nikhef.nl (имя файла - /pub/net work /host. tar.Z).

Чтобы собрать программу host, следует сначала распаковать архив:

А затем выполнить команду:

host облегчает проверку делегирования. С помощью этого инструмента можно производить поиск NS-записей для зоны, используя DNS-cep веры зоны-родителя. Если с этими записями все в порядке, можно ис пользовать host для посылки запросов каждому из DNS-серверов, пе речисленных для SOA-записи зоны. Запросы нерекурсивны, поэтому DNS-сервер, к которому произошло обращение, не контактирует с дру гими DNS-серверами в поисках SOA-записи. Когда DNS-сервер возвра щает ответ, host проверяет ответ на предмет наличия установленного 294 Глава 9. Материнство бита аа - authoritative answer (авторитативный ответ). В случае поло жительного результата DNS-сервер проверяет ответное сообщение на присутствие собственно ответа. При выполнении этой пары условий DNS-сервер помечается как авторитативный для зоны. В противном случае сервер не является авторитативным, и host сообщает об ошибке.

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

Когда сервер получает запрос данных из зоны, для которой он не явля ется авторитативным, то прилагает все усилия, чтобы сообщить кли енту полезную информацию по теме. Эта «полезная информация» со держится в NS-записях ближайшей зоны-предка, которая известна DNS-серверу. (Мы вкратце поговорили об этом в главе 8 «Развитие до мена», когда обсуждали, почему не следует регистрировать DNS-сер вер, специализирующийся на кэшировании.) Допустим, один из DNS-серверов fx.movie.edu по ошибке получает ите ративный запрос адреса carrie.horror.movie.edu. Серверу ничего не из вестно о зоне horror.movie.edu (хотя возможно существуют какие-то данные в кэше), но, вполне вероятно, он кэшировал NS-записи для то vie.edu, поскольку эти записи содержат информацию о родительской зоне. И эти записи DNS-сервер возвращает автору запроса.

В описанном сценарии возвращаемые NS-записи могут помочь DNS серверу, от которого исходил запрос, найти ответ. Однако в сети Ин тернет правда жизни заключается в том, что не все администраторы следят за тем, чтобы файлы корневых указателей соответствовали ре альности. Если один из наших DNS-серверов использует для навигации некорректную информацию о делегировании и запросит у удаленного DNS-сервера данные, которых у того нет, может произойти следующее:

Заботливые родители Удаленный сервер попытался «помочь» нашему DNS-серверу, послав ему текущий перечень корневых серверов. К сожалению, удаленный DNS-сервер не шел в ногу со временем и поэтому вернул неправильные NS-записи. Наш локальный DNS-сервер, не имея лучшей альтернати вы, кэшировал эти данные.

DNS-серверы BIND версии 4.9 и более поздних не поддают ся на подобные провокации.

Запросы к некорректно настроеным DNS-серверам in-addr.arpa зачас тую приводят к получению некорректных NS-записей для корневых DNS-серверов, поскольку зоны in-addr.arpa и аrра являются ближай шими предками большинства поддоменов in-addr.arpa, a DNS-серверы очень редко кэшируют NS-записи in-addr.arpa и аrра. (Корневые DNS серверы редко возвращают эти записи, так как делегируют напрямую поддоменам более низких уровней.) Если DNS-сервер кэшировал не корректные NS-записи для корневых DNS-серверов, это может пагуб но повлиять на разрешение имен.

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

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

Первый шаг: используем host для поиска NS-записей нашей зоны с по мощью DNS-сервера родительской зоны и убедимся, что все в порядке.

Следующая команда производит проверку для NS-записей fx.mo vie.edu с помощью одного из DNS-серверов зоны movie.edu:

Если все в порядке, NS-записи отображаются в выводе программы:

296 Глава 9. Материнство Мы видим, что NS-записи, делегирующие зону fx.movie.edu, верны.

Теперь мы используем host для «SOA-теста» и запросим у каждого из DNS-серверов fx.movie.edu SOA-запись. Параллельно мы увидим, воз вращается ли авторитативный ответ:

Обычно это приводит к отображению уже показанных NS-записей на ряду с содержимым SOA-записи зоны fx.movie.edu:

Если один из DNS-серверов fx.movie.edu - скажем, outland - был на строен неправильно, мы можем увидеть следующее:

Смысл сообщения заключается в том, что DNS-сервер на узле outland работает, но не является авторитативным для зоны fx.movie.edu.

Если бы один из DNS-серверов fx.movie.edu не работал вовсе, мы уви дели бы такое сообщение:

В этом случае сообщение try again (повторите попытку) говорит о том, что программа host отправила серверу outland запрос, но не получила ответа за приемлемое время.

Разумеется, мы могли бы произвести проверку делегирования fx.mo vie.edu с помощью nslookup, но удобные ключи командной строки host позволяют решить эту задачу с особенной легкостью.

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

Но мы не сказали, какие обязанности возлагаются на родителя.

Оказывается, что работа.родителя в этом случае не очень сложна, осо бенно, если администраторы поддоменов присылают полную инфор Заботливые родители мацию. Предположим, что произошло расширение лаборатории спе циальных эффектов в новую сеть, 192.254.20/24. В этой сети прожи вает стадо новых графических рабочих станций повышенной произво дительности. Одна из них, alien.fx.movie.edu, будет выступать в качестве нового DNS-сервера этой сети.

Администраторы зоны fx.movie.edu (которая была делегирована ребя там из лаборатории) посылают администраторам родительской зоны (то есть нам) короткое уведомление:

Наша задача - задача администраторов movie.edu довольно проста: не обходимо добавить NS- и А-записи в файл db.movie.edu.

Что делать в случае, если мы используем программу h2n для создания данных DNS-сервера? Мы можем поместить информацию о делегиро вании в файл spcl.movie, который h2n включает с помощью директивы $INCLUDE в конец создаваемого файла db.movie.

Последнее действие администратора зоны fx.movie.edu - послать ана логичное уведомление по адресу noc@netsol.com (администратору зо ны in-addr.arpa), запросив делегирование поддомена 20.254.192.in addr.arpa DNS-серверам alien.fx.movie.edu, bladerunner.fx.movie.edu и outland.fx.movie.edu.

Заглушки: еще один способ управления делегированием Если вы работаете с DNS-сервером BIND версии 4.9 или более поздней, существует возможность избежать ручного сопровождения информа ции о делегировании. В DNS-серверах BIND начиная с версии 4.9 при сутствует реализация экспериментального механизма зон-заглушек, который и позволяет DNS-серверу самостоятельно отслеживать изме нения в информации, связанной с делегированием.

298 Глава 9. Материнство DNS-сервер, реализующий функциональность заглушки для зоны, выполняет дискретные запросы SOA- и NS-записей зоны, а также не обходимых связующих записей. DNS-сервер использует полученные NS-записи для делегирования зоны, а SOA-записи определяют частоту выполнения подобных запросов. В этом случае, когда администраторы поддомена вносят изменения в данные DNS-серверов поддомена, они просто обновляют NS-записи, а авторитативные DNS-серверы роди тельской зоны запрашивают обновленные записи в пределах интерва ла обновления.

На DNS-серверах movie.edu мы добавили бы следующий оператор в файл named.conf:

В случае DNS-сервера BIND 4.9 использовали бы такую инструкцию:

Обратите внимание, что следует настроить подобным образом все DNS серверы movie.edu, поскольку при изменении информации о делегиро вании fx.movie.edu не изменяется порядковый номер зоны movie.edu. Если все DNS-серверы movie.edu работают с зоной-заглушкой поддоме на, они синхронизируются.

Как справиться с переходом к поддоменам Мы не станем обманывать читателей - пример с поддоменом fx.mo vie.edu был не очень жизненным. Основная причина - волшебное по явление узлов лаборатории специальных эффектов. В реальной жизни лаборатория началась бы с нескольких узлов, которые входили бы в зону movie.edu. После получения щедрого пожертвования, гранта NSF или корпоративного подарка лаборатория может немного подрасти и купить еще несколько машин. Рано или поздно в лаборатории будет достаточно узлов, чтобы гарантировать создание нового поддомена.

Однако к тому моменту многие из узлов обретут известность под сво ими именами в домене movie.edu.

Мы коротко упоминали использование CNAME-записей в родитель ской зоне (в примере с узлом plan9.movie.edu), которые позволили бы пользователям безболезненно привыкнуть к переезду узла в другой до мен. Но представьте себе, что целая сеть или подсеть переезжает в дру гой домен!

Серверы имен BIND 9 обычно по передают NS-записи в родительскую зону, чтобы они не включались в данные при передаче зоны.

Как справиться с переходом к поддоменам Стратегия, которую мы рекомендуем, связана с использованием CNA МЕ-записей в аналогичном стиле, но в гораздо больших масштабах.

Используя инструмент вроде h2п, можно создавать CNAME-записи для большого числа узлов сразу. Это позволяет пользователям продол жать пользоваться прежними доменными именами любых из пере ехавших узлов. Однако, когда они попытаются соединиться с любым из этих узлов по протоколу telnet или FTP (или еще какому-то), то по лучат сообщение, что подключились к узлу fx.movie.edu:

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

На узлах fx.movie.edu, работающих со старыми версиями программы sendma.il, необходимо настроить sendmail на прием почтовых сообще ний для новых доменных имен. Современные версии sendmail произ водят канонизацию имен узлов из заголовков сообщений с помощью DNS-сервера, прежде чем посылать сообщения. Канонизация превра тит псевдоним из movie.edu в каноническое имя из fx.movie.edu. Одна ко если на принимающем узле работает старая версия sendmail, в кото рой жестко закодировано доменное имя локального узла, придется из менить это имя на новое вручную. Это обычно требует внесения прос тых изменений в класс w или файловый класс w в файле sendmail.cf;

более подробная информация содержится в разделе «МХ-алгоритм» главы 5 «DNS и электронная почта».

Как создать все эти псевдонимы? Достаточно просто сказать h2n, что следует создать псевдонимы для узлов в сетях fx.movie.edu (192.253.254/24 и 192.254.20/24) и задать (в файле /etc/hosts) новые доменные имена для этих узлов. К примеру, используя таблицу узлов fx.movie.edu, мы можем с легкостью создать псевдонимы в movie.edu для всех узлов fx.movie.edu.

Фрагмент файла /etc/hosts:

300 Глава 9. Материнство Ключ -с программы h2n в качестве аргумента принимает доменное имя зоны. Когда h2n обнаруживает узел из этой зоны в сети, для кото рой производится генерация данных, то создает псевдонимы в теку щей зоне (которая указывается с помощью ключа -d). Поэтому, вы полнив команду:

(где файл options содержит прочие ключи командной строки для созда ния данных, относящихся к прочим сетям movie.edu), мы можем со здать в movie.edu псевдонимы для всех узлов fx.movie.edu.

Удаление псевдонимов из родительской зоны Псевдонимы в родительской зоне полезны в плане минимизации отри цательных последствий при перемещении узлов, но они, по существу, являются костылями. Как и любые костыли, они ограничивают свобо ду движений. Они замусоривают пространство имен родительской зо ны, и это при том, что одна из причин создания поддоменов - разгруз ка и уменьшение зоны. Помимо этого, псевдонимы исключают ис пользование в родительской зоне узлов с именами, совпадающими с именами узлов поддомена.

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

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

h2n предоставляет простой способ удалить псевдонимы, столь же прос то созданные с помощью ключа -с, даже если записи для узлов поддо мена подмешаны в таблицу узлов или в ту же сеть, что узлы других зон. Ключ -е принимает доменное имя зоны в качестве аргумента и предписывает h2n исключить (е от слова exclude) все записи, содержа щие указанное доменное имя для всех сетей, для которых будет проис ходить создание данных. К примеру, следующая команда удалит все ранее созданные записи CNAME для узлов fx.movie.edu, но при этом Жизнь родителя все равно создаст адресную запись для узла movie-gw.movie.edu (при надлежащего сети 192.253.254/24):

Жизнь родителя Всю эту информацию о жизни родителя нелегко переварить за один прием, поэтому мы резюмируем основные пункты нашей дискуссии.

Жизненный цикл типичного родителя выглядит примерно так:

1. Единственная зона, которая содержит все узлы.

2. Зона разбивается на поддомены, некоторые из которых входят в ту же зону, что и родитель - при необходимости. Для широко извест ных узлов, совершивших переезд, в родительской зоне могут быть созданы CNAME-записи.

3. После тактичной паузы все существующие CNAME-записи удаля ются.

4. Администратор обновляет информацию о делегировании поддоме нов вручную либо при помощи зон-заглушек и периодически прове ряет работоспособность делегирования.

Теперь, когда мы рассказали все о родителях и детях, можно перехо дить к разговору о более серьезных возможностях DNS-серверов. Не которые из них могут пригодиться при воспитании детей.

• Списки отбора адресов и управления доступом • DNS: динамические обновления • DNS NOTIFY (уведомления об изменениях зоны.) • Инкрементальная передача зоны (IXFR) • Ретрансляция • Виды • Round Robin: распределение нагрузки • Сортировка адресов DNS-сервером • DNS-серверы: предпочтения • Нерекурсивный DNS-cepeep • Борьба с фальшивыми DNS-серверами • Настройка системы Дополнительные • Совместимость возможности • Основы адресации в IPv -...Но я могу вам сказать, как их зовут.

-А они, конечно, идут, когда их зовут? небрежно заметил Комар.

- Нет, кажется, не идут.

- Тогда зачем же их звать, если они не идут?

В последних версиях DNS-серверов BIND 8.2.3 и 9.1.0 огромное число новых возможностей. Из наиболее выдающихся нововведений можно отметить динамические обновления, асинхронные уведомления об из менениях зон («NOTIFY») и инкрементальную передачу зональных данных. Из прочих новшеств самые важные связаны с безопасностью:

они позволяют объяснить DNS-серверу, на чьи запросы следует отве чать, кому разрешать получение зоны и от кого допускать динамичес кие обновления. Многие из механизмов обеспечения безопасности не имеют применения в корпоративных сетях, а иные будут полезны ад министратору любого DNS-сервера.

В данной главе мы рассмотрим все эти возможности и их потенциаль ные применения в вашей инфраструктуре DNS. (За исключением под Списки отбора адресов и управления доступом робного материала по брандмауэрам, который мы приберегли для сле дующей главы.) Списки отбора адресов и управления доступом Но прежде чем перейти к новым возможностям, следует рассказать о списках отбора адресов (address match list). Практически каждый ме ханизм обеспечения безопасности в BIND 8 и 9 (а также некоторые ме ханизмы, вовсе не связанные с защитой) работает с применением спис ков отбора адресов.

Список отбора адресов - это список (а что же еще?) элементов, опреде ляющий набор из одного или более IP-адресов. Элементы списка могут являться отдельными IP-адресами, IP-префиксами, либо именованны ми списками отбора адресов (подробнее чуть позже).1 IP-префикс име ет следующий формат:

К примеру, сеть 15.0.0.0 с маской сети 255.0.0.0 (восемь единиц подряд) записывается как 15/8. В традиционной терминологии это сеть 15 клас са А. Сеть, состоящая из IP-адресов с 192.168.1.192 по 192.168.1. может быть представлена в виде 192.168.1.192/26 (сеть 192.168.1. с маской сети 255.255.255.192, в которой 26 единиц подряд). Вот спи сок отбора адресов, состоящий из двух сетей:

Именованный список отбора адресов - это точно такой же список, ко торому присвоено имя. Чтобы использоваться в другом списке отбора адресов, именованный список должен быть предварительно определен в файле named.conf с помощью оператора acl {от access control list).

Оператор acl имеет примитивный синтаксис:

Он делает определенное имя (пате) эквивалентом указанного списка отбора адресов. Хотя имя оператора, acl, наводит на мысли о списке управления доступом («access control list»), именованные списки отбо ра адресов можно использовать в любом месте, где может присутство вать такой список, включая и случаи, которые никоим образом не от носятся к разграничению доступа.

Если одни и те же элементы списка применяются во многих местах, разумно будет связать их с определенным именем с помощью операто В случае использования BIND 9 список отбора адресов может также вклю чать IPv6-адреса и IPv6-префиксы, описанные позже в данной главе.

304 Глава 10 Дополнительные возможности pa acl. Затем по имени можно ссылаться на созданный список. К при меру, назовем сеть 15/8 ее действительным именем: «HP-NET». А сети 192.168.1.192/26 дадим имя «internal»:

Теперь мы можем ссылаться на эти списки отбора адресов из других списков отбора адресов по именам. Это не только сокращает набор, но и делает конечный файл na.med.conf более читаемым.

Мы предусмотрительно поместили имена ACL-списков в кавычки, чтобы избежать конфликтов с именами, зарезервированными BIND для собственных нужд. Если вы уверены, что имена списков не кон фликтуют с зарезервированными словами, можно обойтись и без ка вычек.

Существует четыре предопределенных именованных списка отбора ад ресов:

попе Пустой список. В него не входит ни один IP-адрес any Любые IP-адреса localhost Любые IP-адреса локального узла (узла, на котором работает DNS сервер) localnets Любая из сетей, в которой есть сетевой интерфейс у локального уз ла (вычисление сетей происходит путем удаления битов узла из ад ресов интерфейсов с помощью соответствующих масок).

DNS: динамические обновления Мир сети Интернет и сетей TCP/IP в целом стал гораздо более дина мичным за последнее время. Большинство крупных корпораций ис пользуют DHCP для динамического распределения IP-адресов. Прак тически все интернет-провайдеры используют динамическое распре деление адресов DHCP для клиентов, использующих коммутируемые соединения и кабельные модемы. Чтобы не отстать, система DNS должна реализовывать поддержку динамического добавления и удале ния записей. Этот механизм, получивший название DNS Dynamic Up date (динамические обновления DNS), описан в документе RFC 2136.

BIND 8 и 9 реализуют поддержку механизма динамических обновле ний, описанных в RFC 2136. Это позволяет авторизованным клиентам производить добавление и удаление RR-записей зоны, для которой DNS: динамические обновления DNS-сервер является авторитативным. Автор обновления может опре делить авторитативные DNS-серверы зон путем поиска NS-записей.

Если DNS-сервер, получивший сообщение обновления от авторизован ного клиента, не является первичным DNS-мастер-сервером зоны, он передает обновление «вверх по течению» - своему мастеру. Этот про цесс называется «ретрансляцией обновлений». Если следующий DNS сервер оказывается, в свою очередь, вторичным для зоны, он также пе редает обновление вверх по течению. В конце концов, только первич ный DNS-мастер-сервер зоны владеет изменяемой копией данных;

все вторичные DNS-серверы получают свои копии данных зоны от первич ного мастера, прямо или косвенно (через другие вторичные серверы).

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

Динамические обновления предусматривают более сложные действия, чем удаление и добавление записей. Обновление может затрагивать добавление или удаление отдельных RR-записей, удаление RRset-на боров (наборов RR-записей, имеющих общего владельца, одинаковый класс и тип, например, все адресные записи для www.movie.edu) и даже удаление всех записей, связанных с определенным доменным именем.

Выполнение обновления также может требовать выполнения специ альных условий, например, существования или отсутствия определен ных записей в данных зоны. Так, обновление может добавить адрес ную запись:

только в случае, если доменное имя armageddon.fx.movie.edu в этот мо мент не используется, либо если для armageddon.fx.movie.edu не су ществует адресных записей.

Замечание по ретрансляции обновлений: реализация этого механизма в DNS-серверах BIND отсутствовала до версии 9.1.0, поэтому при использовании DNS-серверов более ран них версий следует проверять, что обновление посылается напрямую первичному DNS-мастер-серверу зоны, для ко торой оно предназначено. Вопрос можно снять, указав пер вичный DNS-мастер-сервер для зоны в поле MNAME запи си SOA. Большинство функций, связанных с динамически ми обновлениями, используют поле MNAME в качестве ис точника информации о том, каким авторитативным DNS серверам следует посылать обновления.

По большей части, функциональность динамических обновлений на ходит применение в программах вроде серверов DHCP, которые авто матически присваивают адреса компьютерам, что связано с необходи мостью регистрации соответствующих отображений имен в адреса и адресов в имена. Некоторые из этих программ используют новую 306 Глава 10. Дополнительные возможности функцию DNS-клиента, ns_update(), для создания сообщений обнов ления и отправки их авторитативному серверу для зоны, владеющей доменным именем.

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

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

nsupdate понимает следующие команды:

prereq yxrrset domain name type [rdata] Создание предварительного условия для выполнения команд об новления. Должен существовать RRset-набор типа type, связанный с доменным именем (domain name). Если указано поле rdata, эти данные также должны существовать.

prereq nxrrset Создание предварительного условия для выполнения команд об новления. Должен отсутствовать Rrset-набор типа type для домен ного имени domain name.

prereq yxdomain domain name Должно существовать указанное доменное имя.

prereq nxdomain Указанное доменное имя должно быть несуществующим.

update delete domain name [type] [rdata] Удаление указанного доменного имени либо, при указании поля type, удаление указанного RRset-набора, а в случае указания поля rdata - удаление записей, соответствующих параметрам domain па те, type и rdata.

update add domain name ttl [class] type rdata Добавление к зоне указанной записи. Обратите внимание, что зна чение TTL должно быть указано, как значения type и rdata, а поле класса является необязательным - по умолчанию принимается класс IN.

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

предписывает серверу добавить адресную запись для mib.fx.movie.edu, но только в том случае, если доменное имя еще не существует. Обрати DNS: динамические обновления те внимания на последнюю пустую строку - она говорит программе nsupdate, что обновление можно посылать. Хитро, а?

Команда:

проверяет, существуют ли МХ-записи для mlb.fx.movie.edu, удаляет их, если существуют, и заменяет двумя новыми.

Возможности динамических обновлений ограничены: невозможно удалить всю зону (хотя можно удалить все ее данные, за исключением SOA-записи и одной NS-записи), и невозможно создать новую зону.

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

DNS-серверы BIND 8 откладывают увеличение порядкового номера на пять минут, либо на 100 обновлений, в зависимости от того, какое ус ловие будет выполнено раньше. Такая пауза предназначена для сопря жения способности DNS-сервера обрабатывать динамические обновле ния с его способностью передавать зоны: последняя требует гораздо больших временных ресурсов в случае крупных зон. Когда DNS-сервер наконец увеличивает порядковый номер зоны, то посылает NOTIFY уведомление (о котором мы расскажем чуть позже в этой главе) вто ричным DNS-серверам зоны, чтобы сообщить, что порядковый номер изменился.

DNS-серверы BIND 9 увеличивают порядковый номер после каждого обработанного динамического обновления.

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

308 Глава 10. Дополнительные возможности Поэтому при получении динамических обновлений DNS-серверы BIND 8 и 9 просто добавляют короткую запись обновления в файл жур нала.1 Изменения, разумеется, немедленно отражаются на копии зо ны, которая хранится в памяти сервера. Но DNS-серверы могут запи сывать зону на диск только в определенные моменты времени (обычно это происходит каждый час). После этого DNS-серверы BIND 8 удаля ют log-файл, поскольку он больше не нужен. (В этот момент копия зо ны в памяти идентична тому, что записано в файле данных зоны.) DNS-серверы BIND 9 оставляют log-файл, поскольку он используется также для инкрементальной передачи зоны, о которой мы поговорим чуть позже в этой главе. (DNS-серверы BIND 8 хранят информацию, необходимую для инкрементальной передачи зоны, в отдельном файле.) В случае DNS-серверов BIND 8 имя log-файла создается путем добавле ния суффикса.log к имени файла данных зоны. В случае DNS-серверов BIND 9 используется суффикс.jnl. Поэтому, начав использовать дина мические обновления, не удивляйтесь появлению этих файлов рядом с файлами данных зон - это совершенно естественно.

В случае DNS-сервера BIND 8 log-файлы должны исчезать каждый час (хотя могут практически сразу появляться снова, если DNS-сервер по лучает много динамических обновлений), а также при нормальном за вершении работы DNS-сервера. В случае DNS-сервера BIND 9 log-фай лы не исчезают никогда. Сервер любой из этих версий вносит измене ния из log-файлов в зоны, если log-файл существует в момент запуска DNS-сервера.

Если кому-то интересно, log-файлы в BIND 8 поддаются прочтению людьми и содержат записи следующего вида:

Нельзя сказать того же о log-файлах BIND 9. По крайней мере, если речь идет о таких, как мы с вами, людях.

Списки управления доступом для обновлений Учитывая ужасающие возможности, которые попадают в руки автора обновлений, очевидно, следует ограничивать доступ к ним, если они вообще используются. По умолчанию, DNS-серверы BIND 8 и BIND не разрешают выполнять динамические обновления зон, для которых являются авторитативными. Чтобы воспользоваться динамическими Идея покажется знакомой всем, кому приходилось использовать журнали руемую файловую систему.

DNS: динамические обновления обновлениями, следует добавить предписание allow-update или update policy к оператору zone зоны, для которой необходимо разрешить ди намические обновления.

allow-update в качестве аргумента принимает список отбора адресов.

Обновления разрешается выполнять только адресу или адресам из это го списка. Разумной политикой является максимальное сокращение этого списка управления доступом:

Обновления с TSIG-подписями DNS-сервер BIND 9.1.0 и более поздних версий умеет производить ре трансляцию обновлений, так что возникает вопрос: какой смысл в спис ке управления доступом для IP-адресов? Если первичный DNS-мастер сервер разрешает обновления с адресов вторичных DNS-серверов, зна чит, любые ретранслированные обновления будут разрешены, вне за висимости от того, кто являлся изначальным их автором. Это плохо. Ну, во-первых, существует возможность определить, какие обновле ния ретранслируются. Предписание allow-update-forwarding в качест ве аргумента принимает список отбора адресов. Ретрансляция будет выполняться только для обновлений, поступающих с перечисленных IP-адресов. Так, следующий оператор zone разрешает ретрансляцию только тех обновлений, которые поступают из подсети факультета Special Effects:

Тем не менее, при использовании ретрансляции обновлений следует работать с динамическими обновлениями с TSIG-подписями. Подроб но механизм TSIG будет рассмотрен только в главе 11 «Безопасность», а сейчас читателям необходимо знать лишь, что динамические обнов ления с TSIG-подписями содержат криптографическую подпись авто ра. Если происходит ретрансляция таких сообщений, то подпись со храняется. В процессе проверки определяется имя ключа, который ис пользовался для создания подписи обновления. Имя ключа похоже на BIND 9.1.0 даже предупреждает, что небезопасно использовать списки уп равления доступом, состоящие из IP-адресов.

310 Глава 10. Дополнительные возможности доменное и довольно часто совпадает с доменным именем использую щего этот ключ узла.

В DNS-серверах BIND 8.2 и более поздних версий список отбора адре сов может содержать имена одного или нескольких TSIG-ключей:

Этот оператор позволяет автору обновления вносить любые изменения в зону fx.movie.edu - используя TSIG-ключ dhcp-server.fx.movie.edu. К сожалению, не существует способа ограничить автора с определенным TSIG-ключом набором исходных IP-адресов.

В BIND 9 реализован более совершенный, чем allow-update, механизм управления доступом, основанный также на TSIG-подписях. Использо вание этого механизма связано с новым предписанием оператора zone, update-policy. update-policy позволяет указать ключи, которым разре шено обновление, и записи, которые могут обновляться конкретными ключами. Это имеет смысл только для первичных DNS-мастер-серве ров зоны, поскольку вторичные DNS-серверы должны просто ретранс лировать обновления.

Обновление определяется именем ключа, используемого для подписи, а также доменным именем и типом записей, для которых это обновле ние предназначено. Синтаксис предписания update-policy:

Значения вариантов grant и deny очевидны: разрешить или запретить конкретное динамическое обновление. Параметр identity определяет имя ключа, который используется для создания подписи. Параметр nametype может принимать значения:

пате Соответствие доменного имени, для которого производится обнов ление, имени в поле аргумента пате..

subdomain Соответствие доменного имени, для которого производится обнов ление, поддомену имени в поле аргумента пате (обновляемое имя заканчивается значением из этого поля). (Разумеется, доменное имя должно входить в контекстную зону.) wildcard Соответствие доменного имени, для которого производится обнов ление, маске, определенной в поле аргумента пате.

DNS: динамические обновления self Соответствие доменного имени, для которого производится обнов ление, имени в поле identity (а не пате), то есть совпадение домен ного имени с именем ключа, который использовался для создания подписи обновления. Когда nametype принимает значение self, по ле пате игнорируется. Но несмотря на очевидную избыточность (мы сейчас увидим ее в примере), поле пате должно присутство вать и в этом случае.

Естественно, пате - доменное имя, соответствующее указанному ва рианту nametype. Если указать wildcard в качестве значения namety pe, поле пате должно содержать метку-маску.

Поле types является необязательным, и может содержать любой су ществующий тип записи (либо перечисление, с пробелом в качестве разделителя), кроме NXT. (Тип ANY является удобным сокращением для «всех типов, кроме NXT».) Если поле types отсутствует, происхо дит отбор всех типов записей, кроме SOA, NS, SIG и NXT.

Замечание по старшинству правил предписания update-po licy: к динамическому обновлению применяется первое со ответствие (не ближайшее, а точное).

Итак, если mummy.fx.movie.edu использует ключ mummy.fx.movie.edu, чтобы подписывать свои динамические обновления, мы можем запре тить mummy.fx.movie.edu обновлять любые записи, кроме собствен ных, с помощью следующего оператора:

либо - запретить обновлять любые записи, кроме собственных адрес ных:

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

312 Глава 10. Дополнительные возможности Поскольку правила в предписании update-policy проверяются в поряд ке следования, клиенты не могут обновлять свои SRV-записи, хотя мо гут обновлять собственные записи любого другого типа.

Для тех, кому интересно, разница между:

и:

в том, что первое правило разрешает ключу, указанному в поле iden tity изменять записи, связанные с fx.movie.edu (скажем, NS-записи этой зоны), а второе - нет.

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

DNS NOTIFY (уведомления об изменениях зоны) Традиционно вторичные DNS-серверы BIND самостоятельно опраши вали DNS-мастер-серверы, чтобы определить, не пора ли произвести получение зоны. Интервал опроса получил название интервала обнов ления. Прочие поля SOA-записи зоны также влияют на различные ас пекты работы механизма опросов.

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

Задержки такого рода могут привести к катастрофе в динамически ме няющейся среде. Разве не было бы здорово, если бы первичный DNS мастер-сервер мог говорить своим вторичным серверам, что данные зоны изменились? В конце концов, первичный DNS-мастер-сервер знает, что данные изменились;

данные были перезагружены, а сервер изучил параметр mtime (время изменения файла в файловой системе Unix) всех файлов данных зон, чтобы определить, какие именно изме нились1, либо сервер получил и обработал динамическое обновление.

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

В документе RFC 1996 был предложен механизм, который позволяет первичным DNS-мастер-серверам посылать вторичным серверам уве домления об изменениях данных зон. Этот механизм, получивший название DNS NOTIFY, реализован в DNS-серверах BIND 8 и 9.

DNS NOTIFY работает следующим образом: когда первичный DNS мастер-сервер замечает, что порядковый номер зоны изменился, то по сылает специальное объявление всем DNS-серверам, которые являют ся для этой зоны вторичными. Перечень вторичных серверов для зоны определяется путем выборки из NS-записей тех, которые указывают на DNS-сервер из поля MNAME SOA-записи зоны либо на доменное имя локального узла.

Когда DNS-сервер замечает изменение? Перезапуск первичного DNS мастер-сервера приводит к посылке текущих порядковых номеров зон всем вторичным серверам этих зон, поскольку первичный DNS-мас тер-сервер не в состоянии определить, были ли изменены файлы дан ных перед его запуском. Перезагрузка одной или нескольких зон с об новленными порядковыми номерами приводит к отправке уведомле ний вторичным серверам этих зон. Уведомление также посылается в результате обработки динамического обновления, в результате кото рой увеличивается порядковый номер зоны.

Специальное NOTIFY-объявление определяется кодом операции и за головком DNS-сообщения. Код операций для большинства запросов — QUERY. NOTIFY-сообщения, включая объявления и ответы, имеют специальный код операции, NOTIFY (сюрприз!). Во всем остальном со общения NOTIFY очень похожи на запрос SOA-записи для зоны: в них указывается доменное имя зоны, порядковый номер которой изменил Исключением является случай перезагрузки единственной зоны, когда сервер проверяет время модификации только для файла перезагружаемой зоны.

314 Глава 10. Дополнительные возможности ся, ее класс, а также тип SOA. Помимо этого, устанавливается бит ав торитативности.

Когда вторичный сервер получает NOTIFY-уведомление для зоны от одного из DNS-серверов, который считается первичным мастером, то посылает ответное NOTIFY-сообщение. Ответное сообщение говорит мастер-серверу о том, что уведомление для зоны получено, его не сле дует посылать повторно. После этого вторичный DNS-сервер работает точно так же, как в случае срабатывания таймера обновления: запра шивает SOA-запись зоны, которая изменилась, у основного DNS-cep вера. Если порядковый номер больше хранимого, происходит получе ние новой копии зоны.

Почему вторичный сервер не верит основному на слово - в том, что зо на действительно изменилась? Вполне возможно, что какой-то злодей подделал NOTIFY-уведомления, полученные узлами, чтобы перегру зить основной DNS-сервер ненужными процессами передачи зон, про изведя атаку DoS (denial-of-service, отказ от обслуживания).

Документ RFC 1996 предписывает вторичному серверу - в случае, ес ли получение зоны произошло, - послать собственные уведомления NOTIFY прочим авторитативным серверам зоны. Идея в основе этого предписания такова: первичный DNS-мастер-сервер мог уведомить не все вторичные DNS-серверы, поскольку некоторые из них могут не иметь прямой связи с основным, общаясь только с другими вторичны ми серверами. Такое поведение реализовано в BIND 8.2.3 и BIND 9, но не в более ранних версиях BIND 8. Вторичные DNS-серверы более ран них версий BIND 8 не посылают NOTIFY-сообщений, если не произве дена специальная настройка.

Вот как это работает на практике. В нашей сети первичным DNS-мас тер-сервером для зоны movie.edu является terminator.movie.edu, a worm hole.movie.edu и zardoz.movie.edu - вторичные DNS-серверы (рис. 10.1).

Рис. 10.1. movie.edu, передача зоны DNS NOTIFY (уведомления об изменениях зоны) Когда копия зоны movie.edu на узле terminator.movie.edu подвергается редактированию и перезагрузке либо для нее выполняется динамичес кое обновление, terminator.movie.edu посылает NOTIFY-объявления узлам wormhole.movie.edu и zardoz.movie.edu. Оба вторичных сервера отвечают узлу terminator.movie.edu, что информация получена. Затем они проверяют, увеличился ли порядковый номер зоны movie.edu, и если это так, производят получение зоны. Если wormhole.movie.edu и zardoz.movie.edu работают под управлением DNS-серверов BIND 8.2. или BIND 9, то после получения новой версии зоны они посылают NO TIFY-объявления друг другу, сообщая об изменениях. Но поскольку wormhole.movie.edu не является DNS-мастер-сервером для zardoz.mo vie.edu (в контексте зоны movie.edu) и обратное также неверно, каждый из серверов игнорирует NOTIFY-сообщение, полученное от второго.

DNS-сервер BIND 8 заносит информацию о сообщениях NOTIFY в log файл syslog. Эти сообщения были записаны в log-файл на узле termina tor.movie.edu после перезагрузки зоны movie.edu:

Первая запись отражает первое NOTIFY-объявление, посланное серве ром terminator.movie.edu двум узлам (2 NS), смысл которого в том, что порядковый номер зоны movie.edu теперь 2000010958. Следующие две строки отражают получение подтверждений от вторичных DNS-серве ров. (DNS-серверы BIND 9 обычно не регистрируют в log-файле NOTI FY-события.) Взглянем теперь на более сложную схему синхронизации зоны. В этом примере а является первичным DNS-мастер-сервером зоны и мастер сервером для b, при этом b является мастер-сервером для с. Помимо этого, у b есть два сетевых интерфейса (рис. 10.2).

В этом варианте а уведомляет узлы b и с о том, что зона обновилась. За тем b проверяет, действительно ли увеличился порядковый номер зоны, и инициирует получение зоны. Однако с игнорирует NOTIFY-сообще ние от а, поскольку а не сконфигурирован как DNS-мастер-сервер для с (в отличие от b). Если узел b работает под управлением DNS-сервера BIND 8.2.3 или BIND 9 либо явным образом настроен уведомлять узел с, то после завершения процесса передачи зоны b посылает уведомление NOTIFY узлу с, которое приводит к проверке узлом с порядкового номе ра, хранимого для зоны сервером b. Если узел с также работает под уп равлением BIND 8.2.3 или BIND 9, то после получения зоны с отправля ет NOTIFY-объявление узлу b, которое тот, разумеется, игнорирует.

316 Глава 10. Дополнительные возможности Рис. 10.2. Более сложный пример синхронизации зоны Отметим, что если существует хоть малейшая вероятность того, что узел с получит NOTIFY-уведомление с другого сетевого интерфейса Ъ, в соответствующем предписании masters для DNS-сервера с должны быть указаны адреса обоих сетевых интерфейсов. В противном случае с будет игнорировать NOTIFY-сообщения, получаемые через неизвест ный сетевой интерфейс.

Вторичные серверы BIND 4 (и прочие, не поддерживающие механизм NOTIFY) будут возвращать ошибку Not Implemented (NOTIMP, реали зация отсутствует). Обратите внимание, что сервер Microsoft DNS под держивает работу с механизмом DNS NOTIFY.

DNS NOTIFY по умолчанию работает в BIND 8 и 9, но можно глобаль но отключить этот механизм с помощью предписания notify:

Можно также включать или выключать NOTIFY для отдельных зон. К примеру, нам известно, что все вторичные серверы зоны fx.movie.edu работают под управлением BIND 4, а значит не понимают NOTIFY объявлений. Следующий оператор zone:

предотвращает посылку бесполезных NOTIFY-сообщений вторичным DNS-серверам зоны fx.movie.edu. Частные настройки NOTIFY для зо ны имеют более высокий приоритет, чем глобальные. К сожалению, Инкрементальная передача зоны (IXFR) ни в BIND 8, ни в BIND 9 нет возможности выключать механизм NO TIFY для отдельных серверов.

В BIND 8 и 9 существует даже возможность добавлять в «NOTIFY-спи сок» DNS-серверы помимо тех, что указаны в NS-записях зоны. К при меру, у нас может быть один или несколько незарегистрированных вторичных DNS-серверов (случай описан в главе 8 «Развитие домена») и мы хотим, чтобы они быстро реагировали на изменение зоны. Как вариант речь может идти о более старом вторичном DNS-сервере BIND 8, который является мастер-сервером для другого вторичного и должен передавать этому вторичному узлу NOTIFY-сообщения.

Чтобы добавить сервер в список рассылки NOTIFY-объявлений, следу ет воспользоваться предписанием also-notify оператора zone:

Начиная с BIND 8.2.2, also-notify может использоваться также и в ка честве предписания в операторе options. Такое предписание будет действовать для всех зон со включенным механизмом NOTIFY (и для которых отсутствуют частные предписания also-notify).

Начиная с BIND 9.1.0, в качестве аргумента предписания notify мож но указать ключевое слово explicit;

что приводит к подавлению посыл ки NOTIFY-сообщений для всех DNS-серверов, кроме тех, что перечис лены в списке also-notify. Помимо этого, можно использовать предпи сание allow-notify, чтобы DNS-сервер принимал NOTIFY-сообщения не только от DNS-мастер-серверов зоны:

В качестве предписания оператора options allow-notify относится ко всем вторичным зонам. В качестве частного предписания оператора zo ne allow-notify имеет приоритет больший, чем глобальное предписание allow-notify и действует в пределах текущей зоны.

Инкрементальная передача зоны (I XFR) Итак, мы используем динамические обновления и механизм NOTIFY, и когда мы обновляем зоны - в соответствии с изменениями в сети - об новления быстро распространяются на данные, хранимые всеми авто ритативными DNS-серверами для этих зон. Чего еще можно желать?

318 Глава 10. Дополнительные возможности Оказывается, есть чего. Представим себе, что крупная зона динами чески обновляется с ужасающей частотой. Такое вполне может слу читься: администратор заведует крупной зоной, у которой тысячи клиентов, и вдруг руководство посещает идея оборудовать клиентов системой Windows 2000 и начать использовать DHCP. Теперь каждый из клиентов будет обновлять свои адресные данные в зоне, а контрол леры домена будут обновлять записи, предоставляющие клиентам ин формацию о существующих службах. (Гораздо больше материала по Windows 2000 содержится в главе 16 «Обо всем понемногу».) Каждый раз, когда первичный DNS-мастер-сервер производит обнов ление, связанное с увеличением порядкового номера зоны, он посыла ет NOTIFY-объявления вторичным DNS-серверам. Каждый раз при получении уведомлений вторичные серверы проверяют, не увеличил ся ли порядковый номер зоны на основном сервере, и, возможно, про изводят синхронизацию. Если зона крупная, синхронизация займет определенное время, а за это время она снова может обновиться. И так вторичные серверы будут бесконечно долго заниматься исключитель но синхронизацией! В лучшем случае DNS-серверы потратят много времени на передачу данных зоны, причем весьма вероятно, что изме нения были довольно незначительными по размеру (скажем, добави лась адресная запись для клиента).

Инкрементальная передача зоны (incremental zone transfer или IXFR) решает эту проблему, позволяя вторичным DNS-серверам сообщать ос новным, какие версии зон ими хранятся, и запрашивать только изме нения зоны между хранимыми версиями и текущими. Это позволяет весьма значительно сократить объем передаваемых данных и время передачи.

Тип запроса для инкрементальной передачи зон - IXFR вместо AXFR (тип запроса для полной передачи зоны), при этом запрос содержит хранимую на вторичном сервере SOA-запись зоны в разделе авторита тивности. Когда основной DNS-сервер получает запрос инкременталь ной передачи зоны, он производит поиск записей об изменениях зоны, то есть разницы между существующей зоной и копией, хранимой вто ричным DNS-сервером. Если информация отсутствует, происходит полная передача зоны. В противном случае передается только найден ная разница.

Ограничения IXFR Звучит неплохо? И работает отлично! Но IXFR имеет несколько огра ничений, о которых читателям следует знать. Во-первых, этот меха низм толком заработал начиная с BIND 8.2.3. Все DNS-серверы BIND содержат реализацию IXFR, которая хорошо сосуществует с реализа цией BIND 8.2.3.

Инкрементальная передача зоны (IXFR) Кроме того, IXFR лучше всего работает, когда данные зоны изменяют ся только с помощью динамических обновлений. Выполнение динами ческих обновлений приводит к появлению записей о внесенных измене ниях и порядковом номере, которому эти изменения соответствуют, это именно та информация, которую основной сервер должен послать вторичному, получив запрос IXFR. Но первичный DNS-мастер-сервер BIND, перезагрузивший весь файл данных зоны, неспособен вычислить разницу между этой зоной и предыдущей ее копией. Вторичный DNS сервер BIND, при проведении полной передачи зоны, также не в состо янии понять, в чем разница между этой копией зоны и предыдущей.

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

Файлы IXFR DNS-серверы BIND 8 ведут журнал изменений IXFR, отдельный от файла динамических обновлений. Как и файл журнала динамических обновлений, журнал IXFR обновляется при каждом получении обнов ления серверов. В отличие от журнала динамических обновлений, журнал IXFR никогда не удаляется, хотя DNS-сервер можно настро ить на усечение этого файла при достижении им определенного разме ра. По умолчанию файл IXFR-журнала получает имя файла данных зоны с добавленным суффиксом.ixfr.

DNS-серверы BIND 9 используют файл журнала динамических обнов лений для сборки ответных IXFR-сообщений и поддержки целостнос ти данных зоны. Поскольку первичный DNS-мастер-сервер не знает, когда именно может понадобиться запись об определенной модифика ции зоны, то не удаляет файл журнала. Вторичный DNS-сервер BIND удаляет файл журнала при получении AXFR-запроса для зоны, по скольку после передачи полной копии зоны можно перестать отслежи вать изменения, приведшие к получению этой копии.

Настройка IXFR в BIND Настройка IXFR в BIND 8 достаточно прямолинейна. Во-первых, на основном DNS-сервере следует воспользоваться предписанием mainta in-ixfr-base оператора options, чтобы предписать хранение файлов IXFR журналов для всех зон - даже тех, для которых DNS-сервер является вторичным, поскольку могут существовать прочие вторичные DNS серверы, способные посылать ему IXFR-запросы:

320 Глава 10 Дополнительные возможности Теперь следует объяснить вторичным серверам, что IXFR-обновления доступны при работе с основным сервером. Это делается с помощью но вого предписания support-ixfr:

И это практически все, если нет необходимости изменять имя файла IXFR-журнала на первичном DNS-мастер-сервере. Если такая необхо димость существует, воспользуйтесь предписанием ixfr-base оператора zone:

Ах да, можно настроить DNS-сервер на усечение файла IXFR-журнала в момент превышения определенного размера: Как только размер IXFR-журнала превысит указанный на 100 кило байт, произойдет усечение до указанного размера. Буфер в 100 кило байт предотвращает выполнение усечения после каждого успешного обновления.

Эффективность синхронизации зон можно увеличить еще больше, ис пользуя формат передачи many-answers. Подробности в разделе «По вышение эффективности при передаче зон».

Настройка IXFR в BIND Настройка IXFR для основного DNS-сервера BIND 9 еще проще, по скольку делать вообще ничего не надо: механизм включен по умолча нию. Если существует необходимость отключить механизм для опре деленного вторичного узла (что маловероятно, поскольку вторичный сервер должен запросить инкрементальную передачу зоны), восполь зуйтесь предписанием provide-ixfr оператора server, для которого по умолчанию устанавливается значение yes:

В версиях до BIND 8.2.3 размер может указываться только в байтах (вмес то «1М») из-за существующей ошибки в коде.

Ретрансляция provide-ixfr можно использовать также в качестве предписания опера тора options, в этом случае оно относится ко всем вторичным DNS-cep верам, для которых не существует частных предписаний provide-ixfr в операторах server.

Поскольку основные DNS-серверы BIND 9 выполняют передачу зоны в формате many-answers по умолчанию, нет необходимости дополни тельно настраивать этот аспект с помощью transfer-format.

Представляет интерес предписание request-ixfr, которое можно указы вать в операторах options и server. Для смешанного набора IXFR-ори ентированных и HeIXFR-ориентированных DNS-мастер-серверов мож но настроить вторичные DNS-серверы на использование существую щих способностей основных серверов:

В BIND 9 не реализована поддержка предписания max-ixfr-log-size.

Ретрансляция В определенных случаях крупные объемы внешнего трафика нежела тельны либо из-за значительной суммы оплаты канала, напрямую свя занной с этими объемами, либо из-за медленного канала связи с боль шими задержками, например, при использовании удаленным офисом компании спутникового канала для подключения к корпоративной се ти. В таких случаях внешний DNS-трафик желательно свести к мини муму. В BIND существует механизм, позволяющий это сделать: for warders (ретрансляторы).

Ретрансляторы могут также использоваться при необходимости возло жить ответственность за разрешение имен на конкретный сервер. К примеру, если только один узел сети подключен к Интернету, и на этом узле работает DNS-сервер, все прочие DNS-серверы можно настроить на использование этого узла в качестве ретранслятора при поиске дан ных для доменных имен. (Более подробно такое применение ретранс ляторов мы обсудим в главе 11, когда речь пойдет о брандмауэрах.) Если сделать один или несколько серверов площадки ретранслятора ми, DNS-серверы будут посылать внешние запросы прежде всего этим серверам. Идея состоит в том, что ретранслятор обрабатывает все внешние запросы для площадки, параллельно занимаясь накоплени 322 Глава 10. Дополнительные возможности ем кэшированной информации. Для произвольного запроса данных из внешней зоны существует высокая вероятность того, что ретранслятор в состоянии ответить на запрос данными из кэша, что избавляет про чие серверы от необходимости посылать внешние запросы. Чтобы сде лать конкретный DNS-сервер ретранслятором, не нужны какие-либо специальные действия - настраивать следует все прочие серверы пло щадки, чтобы они направляли свои запросы ретрансляторам.

Рабочий процесс несколько изменяется для первичного или вторичного DNS-сервера, который настроен на использование ретранслятора. Если клиент запрашивает записи, которые входят в авторитативность DNS сервера, либо содержатся в кэшированных данных, DNS-сервер возвра щает информацию самостоятельно: в этой части ничего не изменилось.

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

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

Ниже приводится предписание forwarders для BIND 8 и 9, а также эк вивалентная инструкция загрузочного файла BIND 4 - для DNS-серве ров зоны movie.edu. wormhole.movie.edu и terminator.movie.edu являют ся ретрансляторами площадки. Следующее предписание forwarders добавляется в файлы настройки всех DNS-серверов, за исключением тех, которые являются ретрансляторами:

Соответствующая инструкция BIND 4:

При использовании ретрансляторов старайтесь максимально упро щать настройки, иначе можно очень сильно запутаться в полученной структуре.

Избегайте объединения ретрансляторов в цепочки. Не сто ит делать так, чтобы DNS-сервер А передавал запросы сер веру В, а сервер В - серверу С (или, того хуже, обратно А).

Это может привести к длительным паузам в процессе раз решения имен, а также делает хрупкой всю структуру: ес ли произойдет сбой на любом из ретрансляторов цепи, раз решение имен будет затруднено либо станет попросту не возможным.

Ретрансляция Более ограниченный DNS-сервер Можно ограничить DNS-серверы еще более - запретив даже пытать ся посылать запросы внешним DNS-серверам, если ретрансляторы не работают или не отвечают. Это можно сделать, настроив DNS-серверы на работу в режиме forward-only. DNS-сервер в режиме forward-only это вариация на тему DNS-сервера, использующего ретрансляторы. Он по-прежнему отвечает на запросы, исходя из авторитативных и кэши рованных данных, но во всем остальном полностью полагается на ре трансляторы, не пытаясь связаться с другими DNS-серверами в поис ках ответа. Вот пример файла настройки для DNS-сервера, работаю щего в режиме эксклюзивной ретрансляции:

То же для DNS-сервера BIND 4:

DNS-серверы BIND до версии 4.9 предоставляют ту же функциональ ность с помощью инструкции slave (вместо options forward-only):

Не следует путать старое значение термина «slave» с имеющим хожде ние в наше время. В DNS-серверах BIND 4 слово «slave» являлось си нонимом для «forward-only». Сегодня «slave» - это вторичный DNS сервер, получающий данные зоны от первичного мастер-сервера.

В случае использования режима forward-only должно присутствовать предписание forwarders. Иначе нет смысла устанавливать режим for ward-only. Если настроить DNS-сервер BIND версии более ранней, чем 8.2.3, на работу в режиме forward-only, возможно, имеет смысл ука зать IP-адреса ретрансляторов по несколько раз. Для DNS-сервера BIND 8 это будет выглядеть так:

Для DNS-сервера BIND 4 так:

324 Глава 10. Дополнительные возможности Этот DNS-сервер вступает в контакт с каждым из ретрансляторов лишь единожды и в течение короткого промежутка времени ожидает ответа. Повторное включение ретрансляторов в список позволяет DNS-серверу повторно посылать запросы ретрансляторам и увеличи вает суммарное время ожидания ответа.

Однако следует задуматься, действительно ли использование DNS-cep вера в режиме forward-only имеет какой-то смысл. Такой DNS-сервер полностью зависим от ретрансляторов. Практически такого же ре зультата можно добиться и не используя DNS-сервера вовсе: создайте файл resolv.conf, содержащий инструкции nameserver для используе мых ретрансляторов. В этом случае зависимость от ретрансляторов со храняется, но теперь приложения посылают запросы ретрансляторам напрямую, и нет необходимости содержать DNS-сервер, который бу дет передавать эти запросы по поручению приложений. При этом теря ется локальное кэширование и сортировка адресов, но уменьшается суммарная сложность настройки структуры DNS-площадки в резуль тате сокращения числа DNS-серверов.

Зоны ретрансляции Традиционно использование ретрансляторов работало по формуле «все или ничего»: либо следовало использовать ретрансляторы для разрешения всех запросов, которые не могут быть разрешены отдель ным DNS-сервером, либо не использовать ретрансляторы вовсе. Одна ко существуют случаи, когда было бы удобно иметь более тонкое уп равление ретрансляцией. К примеру, можно было бы производить раз решение определенных доменных имен с помощью определенного ре транслятора, а для всех прочих имен - итеративное.

В BIND 8.2 появился новый механизм - зоны ретрансляции, который позволяет настроить DNS-сервер на использование ретрансляторов только при поиске для определенных доменных имен. (Поддержка зон ретрансляции в BIND 9 появилась в версии 9.1.0.) К примеру, DNS сервер может быть настроен на передачу всех запросов для доменных имен с суффиксом pixar.com паре DNS-серверов компании Pixar:

Почему возникает необходимость явным образом указывать DNS-cep веры, когда настраиваемый DNS-сервер мог бы самостоятельно найти DNS-серверы зоны pixar.com, пользуясь информацией о делегирова нии из зоны сот? Представьте себе, что у нас есть прямой канал в ком панию Pixar и необходимо использовать специальный набор DNS-сер веров, доступных только в пределах нашей сети, которые будут зани маться разрешением доменных имен зоны pixar.com.

Ретрансляция Правила ретрансляции содержатся в операторе zone, но выполняются для всех доменных имен, которые заканчиваются именем указанной зоны. Вне зависимости от того, входит ли доменное имя, foo.bar.pi xar.com, в зону pixar.com, для него выполняется правило ретрансля ции, поскольку имя заканчивается на pixar.com (или входит в домен pixar.com - кому что больше нравится).

Существует еще одна разновидность зоны ретрансляции, в некотором смысле противоположная только что описанной. Эта разновидность позволяет указывать, какие запросы не передаются ретранслятору.

Следовательно, правило применимо только для DNS-серверов, ретран сляторы для которых указаны в операторе, options, то есть распростра няется на все запросы.

Такие зоны ретрансляции настраиваются с помощью оператора zone, но не типа forward. Вместо этого используются предписания forwar ders для обычных зон - основных, вторичных или зон-заглушек. Что бы произвести отказ от ретрансляции, настройка которой произведена в операторе options, можно указать пустой список ретрансляторов:

Минуточку - но зачем отключать ретрансляцию в зоне, для которой сервер является авторитативным? Разве DNS-сервер не ответит на за прос без использования ретранслятора?

Вспомним, что правила ретрансляции применяются ко всем запросам для всех доменных имен, которые заканчиваются доменным именем зоны. Так что данное правило ретрансляции касается только запросов для доменных имен из делегированных поддоменов movie.edu, напри мер fx.movie.edu. Без такого правила ретрансляции данный DNS-сер вер просто передал бы запрос для имени matrix.fx.movie.edu DNS-cep веру 192.249.249.3 или 192.249.249.1. В присутствии такого правила используются NS-записи поддомена из зоны movie.edu, и запросы на правляются DNS-серверам зоны fx.movie.edu.

Зоны ретрансляции невероятно полезны при работе с брандмауэрами Интернета, как мы увидим в следующей главе.

326 Глава 10. Дополнительные возможности Выбор ретранслятора Выбор ретранслятора В случае использования DNS-серверов BIND 8.2.3 нет необходи В случае использования DNS-серверов BIND 8.2.3 нет необходи мости упоминать ретрансляторы более одного раза. Эти DNS мости упоминать ретрансляторы более одного раза. Эти DNS серверы необязательно опрашивают ретрансляторы в порядке серверы необязательно опрашивают ретрансляторы в порядке их перечисления;

они считают DNS-серверы из списка «канди их перечисления;

они считают DNS-серверы из списка «канди датами» для ретрансляции и выбирают сервер на основе времени датами» для ретрансляции и выбирают сервер на основе времени передачи сигнала, то есть времени получения ответов на пред передачи сигнала, то есть времени получения ответов на пред шествующие запросы.

шествующие запросы.

Это является преимуществом для случаев, когда один из ретранс Это является преимуществом для случаев, когда один из ретранс ляторов выходит из строя, особенно если он первый в списке. Бо ляторов выходит из строя, особенно если он первый в списке. Бо лее старые версии BIND продолжали попытки получить ответ от лее старые версии BIND продолжали попытки получить ответ от неработающего ретранслятора, делая паузу, прежде чем перейти неработающего ретранслятора, делая паузу, прежде чем перейти к следующему ретранслятору из списка. BIND 8.2.3 очень быст к следующему ретранслятору из списка. BIND 8.2.3 очень быст ро понимает, что ретранслятор не отвечает, и в следующий раз в ро понимает, что ретранслятор не отвечает, и в следующий раз в качестве первого выбирает другой DNS-сервер.

качестве первого выбирает другой DNS-сервер.

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

дит переключение между ретрансляторами при необходимости.

Виды В BIND 9 появились виды (views), еще один механизм, исключительно полезный в сетях, защищенных брандмауэрами. Виды позволяют ис пользовать различные настройки DNS-сервера при общении с различ ными наборами узлов. Это в особенности удобно, если DNS-сервер рабо тает на узле, получающем запросы как от внутренних узлов, так и от уз лов сети Интернет (этот вариант будет рассмотрен в следующей главе).

Если отсутствует явная настройка видов, BIND 9 автоматически создает единственный неявный вид, который и доступен всем клиентам, посы лающим запросы. Чтобы создать вид явным образом, следует восполь зоваться оператором view, аргументом которого является имя вида:

Имя вида может быть практически любым, но хорошей практикой яв ляется использование описательных имен. Кавычки, заключающие в себя имя вида, не являются обязательными, но полезно их использо вать в целях предотвращения конфликтов имен видов с зарезервиро ванными ключевыми словами BIND (такими как «internal», напри мер). Оператор view может следовать за любым оператором options, хо тя и необязательно непосредственно за таковым.

Перечисление узлов, которые могут «видеть» конкретный вид, произ водится с помощью предписания match-clients view, принимающего Виды список отбора адресов в качестве аргумента. Если набор узлов не ука зан с помощью match-clients, вид доступен для всех узлов.

Предположим, мы создаем специальный вид зоны fx.movie.edu, кото рый будет доступен только факультету Special Effects. Мы можем со здать вид, доступный только узлам нашей подсети:

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

Однако следует убедиться, что ACL-список определен вне вида, посколь ку оператор acl пока еще не может использоваться в операторе view.

Что же может использоваться в операторе view? Практически все ос тальные операторы. Можно определять зоны с помощью операторов zone, описывать DNS-серверы с помощью операторов server, а также настраивать ключи TSIG с помощью операторов key. В пределах вида можно использовать большинство предписаний оператора options, не заключая их в этот оператор:

Значения параметров настройки, указываемые в пределах вида, заме щают глобально определенные значения с идентичными именами (скажем, определенные в операторе options) - для узлов из списка match-clients.

Полный перечень инструкций, допустимых в пределах оператора view для используемой версии BIND 9 (перечень меняется от версии к вер сии), содержится в файле doc/misc/options дистрибутива BIND.

Вот полный файл named.conf лаборатории специальных эффектов, ко торый даст читателям представления о потенциале видов:

328 Глава 10. Дополнительные возможности Обратите внимание, что в каждом виде существуют зоны fx.movie.edu и 254.253.192.in-addr.arpa, но файлы данных зон для «внутреннего» и «внешнего» видов используются различные. Это позволяет показы вать внешнему миру не то «лицо», которое доступно нам.

Порядок следования операторов view важен, поскольку клиент с опре деленным IP-адресом будет наблюдать первый вид, разрешенный к на блюдению для этого адреса. Если бы «external» предшествовал виду «internal», вид «internal» никогда бы не использовался, поскольку внешний вид разрешен к наблюдению всеми адресами.

И последнее замечание по видам (до того, как мы снова к ним вернемся в следующей главе): если создан хотя бы один оператор view, все опе раторы zone должны быть явно включены в один из видов.

Round Robin: распределение нагрузки DNS-серверы, появившиеся после BIND 4.9, официально включают функциональность, связанную с распределением нагрузки, которая прежде существовала только в виде заплат к BIND. Брайан Бичер (Bryan Beecher) создал заплаты к BIND 4.8.3, реализующие - как он это назвал - «перетасовку адресных записей». Речь шла об адресных Round Robin: распределение нагрузки записях специального типа, которые DNS-сервер возвращал в различ ном порядке в различных ответных сообщениях. К примеру, доменное имя foo.bar.baz имело три «тасуемых» IP-адреса, 192.168.1.1, 192.168.1.2 и 192.1.168.3, и соответствующим образом обновленный DNS-сервер мог возвращать их сначала в таком порядке:

затем в таком:

и наконец - в таком:

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

Такая функциональность невероятно полезна в случаях, когда су ществует набор эквивалентных сетевых ресурсов, например, зеркаль ных FTP-серверов, веб-серверов, терминальных серверов, а также не обходимость в распределении нагрузки между этими серверами. Одно доменное имя является указателем на группу ресурсов: клиенты полу чают доступ к ресурсу по этому доменному имени, а DNS-сервер рас пределяет запросы между несколькими перечисленными IP-адресами.

Начиная с BIND 4.9 тасуемые адресные записи прекратили существо вание в виде самостоятельного типа данных, требующего специальной обработки. Вместо этого современный DNS-сервер производит переста новку адресов для любого доменного имени, с которым связано более одной А-записи. (Вообще говоря, DNS-сервер производит перестанов ки для записей любого типа, если таких записей для доменного имени существует больше одной.1) Поэтому существование записей:

приводит для DNS-сервера версии 4.9 или более поздней к такому же результату, как в случае обновленного для работы с тасуемыми адрес ными записями сервера версии 4.8.3. В документации BIND процесс перестановки записей носит название round robin.

Хорошей идеей будет уменьшить время жизни для записей, как мы сделали в последнем примере. В этом случае, если адреса будут кэши рованы промежуточным DNS-сервером, который не поддерживает пе рестановку адресов, они быстро устареют. Промежуточный DNS-cep До появления BIND 9 PTR-записи не подвергались перестановке. В BIND выполняется перестановка для всех типов записей.

330 Глава 10. Дополнительные возможности вер будет вынужден снова запросить адрес для имени, и снова получит адресные записи в другом порядке.

Заметим, речь идет именно о распределении нагрузки, а не о ее балан сировке, поскольку DNS-серверы выдают адреса в совершенно пред сказуемом порядке, вне зависимости от реально существующей на грузки или мощности серверов, обслуживающих запросы. В нашем примере сервер по адресу 192.168.1.3 может быть машиной 486DX33, работающей под управлением системы Linux, а два других сервера суперкомпьютерами НР9000;

но Linux-машина все равно будет полу чать треть всех запросов. Многократное перечисление адресов более мощных серверов ни к чему не приведет, поскольку BIND удаляет дуб лирующиеся записи.

Множественные CNAME-записи Во времена расцвета DNS-серверов BIND 4 некоторым приходила в го лову мысль обеспечивать перестановку с помощью множественных CNAME-записей (вместо множественных адресных):

Вероятно, читателям это покажется странным, ведь мы постоянно твердим, что не следует использовать CNAME-записи не по назначе нию. DNS-серверы BIND 4 не считали такие данные ошибочными (а они таковыми являются) и просто возвращали CNAME-записи для foo.bar.baz в порядке перестановки round robin.

С другой стороны, DNS-серверы BIND 8 более бдительны и немедленно сообщают об ошибке. Тем не менее, их можно явным образом настро ить, разрешив использование множественных CNAME-записей для одного доменного имени с помощью следующей конструкции:

DNS-серверы BIND 9 не замечают этой CNAME-ошибки вплоть до вер сии 9.1.0. BIND 9.1.0 способен обнаружить ошибку, но не поддержи вает предписание multiple-cnames.

Предписание rrset-order В определенных ситуациях предпочтительнее, чтобы DNS-сервер не ис пользовал механизм round robin. К примеру, существует необходимость сделать один веб-сервер резервным для второго. В таком случае DNS Round Robin: распределение нагрузки сервер должен всегда возвращать адрес резервного веб-сервера после адреса основного. Но в случае перестановки адресов это невозможно, порядок адресов в различных ответах будет постоянно меняться.

DNS-серверы, начиная с BIND 8.2 (но не BIND 9 на момент существо вания версии 9.1.0), позволяют отключать действие механизма round robin для отдельных доменных имен и типов записей. Так, если необ ходимо обеспечить стабильный порядок возвращаемых адресных за писей для www.movie.edu, можно воспользоваться предписанием rrset order:

В этом случае, вероятно, следует понизить значение TTL для адресных записей www.movie.edu, чтобы DNS-сервер, кэшировавший эти запи си, не слишком долго возвращал их в различном порядке.

Параметры class, type и пате определяют записи, для которых ис пользуется указанный порядок. Класс по умолчанию принимает зна чение IN, тип - значение ANY, а имя - *, другими словами речь идет о произвольных записях. Поэтому оператор:

предписывает использовать случайный порядок для всех записей, воз вращаемых DNS-сервером. Параметр имени может содержать маску вместо самой первой метки:

Допускается использование только одного предписания rrset-order, но оно может содержать несколько спецификаций порядка. Имеет силу первая спецификация для наборов записей в ответах.

rrset-order позволяет выбрать один из трех (сосчитайте-ка, из трех!) ва риантов порядка:

fixed Результаты поиска записей всегда возвращаются в одном и том же порядке.

332 Глава 10. Дополнительные возможности random Результаты поиска записей возвращаются в случайном порядке.

cyclic Результаты поиска записей возвращаются в циклическом порядке (round robin).

Поведение по умолчанию определяется следующим образом:

К сожалению, настройка с помощью rrset-order не является оконча тельным решением, поскольку ее работе могут мешать клиенты и кэ ширование DNS-серверов. Более правильным и удачным решением является использование SRV-записей, которые мы изучим в главе 16.

Сортировка адресов DNS-сервером Иногда администратора не устраивает ни порядок перестановки round robin, ни какой-либо иной. При необходимости связаться с узлом, имеющим многочисленные сетевые интерфейсы, выбор определенного адреса на основе адреса вашего узла может привести к повышению производительности. Но добиться этого с помощью предписания rrset order невозможно.

Если узел, смотрящий в несколько сетей, является локальным, и вхо дит в сеть или подсеть исходного узла, один из его адресов является «более близким». Если узел удаленный, при выборе различных интер фейсов производительность также будет меняться, но часто нет разни цы, какой именно интерфейс использовать. В давние времена сеть (бывшая основа ARPAnet) всегда была ближе любого другого удален ного адреса. С тех пор Интернет значительно усовершенствовался, по этому выбор той или иной сети при контакте с внешними узлами не приводит к особенному повышению производительности, хотя мы все равно рассмотрим этот случай.

Прежде чем мы начнем говорить о сортировке адресов DNS-сервером, читателям следует взглянуть на главу 6, а именно на раздел «Инструк ция sortlist», и подумать - возможно, сортировка адресов с помощью клиента более соответствует вашим нуждам. Поскольку клиент и DNS-сервер могут находиться в разных сетях, зачастую имеет боль ший смысл выполнять сортировку адресов с помощью клиента кон кретного узла - способом, для этого узла оптимальным. Сортировка адресов DNS-сервером работает достаточно хорошо, но ее бывает труд но оптимизировать для всех обслуживаемых клиентов. Сортировка ад Сортировка адресов DNS-сервером ресов клиентом появилась в BIND 4.9, поэтому если используется кли ент (не DNS-сервер) версии более ранней, чем 4.9, либо не клиент BIND, выбирать особо не приходится. Придется обойтись сортировкой адресов DNS-сервером, которая появилась в версии 4.8.3.

В результате невероятного поворота событий механизм сортировки ад ресов не был включен в более поздние версии BIND, в основном потому, что разработчики утверждали «Этому механизму не место в DNS-cep вере». Статус-кво был восстановлен - даже с некоторыми улучшени ями - в BIND 8.2. BIND 9.1.0 - первая версия BIND 9, поддерживаю щая сортировку адресов.

Сортировка адресов в BIND Сортировка адресов BIND 4 проще в настройке, чем аналогичный ме ханизм BIND 8, но сложнее для описания, поскольку довольно многое происходит автоматически, безо всяких настроек. Оставим BIND 8 на потом.

Локальные мультиинтерфейсные узлы Рассмотрим сначала локальные мультиинтерфейсные узлы. Предпо ложим, у нас есть узел исходных текстов, на котором хранятся их мас тер-копии;

этот узел входит в две сети, которые носят весьма ориги нальные названия - сеть А и сеть В. На узле применяется NFS для экс порта файловых систем для узлов в обеих сетях. Узлы сети А получа ют большую производительность, если используют сетевой интерфейс этого узла с сетью А. Аналогично узлы сети В получают большую про изводительность, используя интерфейс этого узла с сетью В - при по иске адреса NFS-сервера.

В главе 4 «Установка BIND» мы упоминали, что BIND возвращает все адреса для мультиинтерфейсного узла. Для возвращаемых адресов не гарантирован какой-либо заданный порядок, поэтому нам пришлось создать псевдонимы (wh249.movie.edu и wh253.movie.edu для wormho le.movie.edu) отдельных интерфейсов. Если какой-либо из интерфейсов являлся более предпочтительным, мы (вернее, клиент DNS) могли вы брать соответствующий псевдоним и получить нужный адрес. Можно использовать псевдонимы для выбора «более близких» интерфейсов (скажем, для работы с NFS), но это не всегда имеет смысл, поскольку существует сортировка адресов.

DNS-серверы BIND 4 по умолчанию производят сортировку адресов в случае выполнения следующего условия: узел, являющийся автором запроса к DNS-серверу, находится в одной сети с узлом DNS-сервера (скажем, оба узла принадлежат сети А). Как BIND определяет, что на ходится в одной сети с клиентом? При запуске BIND находит все адре са интерфейсов узла, на котором работает. Из этих адресов BIND из влекает номера сетей и использует их для создания списка сортировки 334 Глава 10. Дополнительные возможности по умолчанию. При получении запроса BIND проверяет, не входит ли адрес отправителя в одну из сетей, перечисленных в списке поиска по умолчанию. Если это так, запрос является локальным и BIND произ водит сортировку адресов в ответе.

Предположим (рис. 10.3), что на узле notorious работает DNS-сервер под управлением BIND 4. Список поиска этого DNS-сервера по умолча нию содержит сеть А и сеть В. Когда узел spellbound посылает DNS серверу запрос для адресов notorious, то получает ответ, в котором ад рес notorious в сети А представлен первым. Это происходит потому, что notorious и spellbound принадлежат одной сети, А. Когда узел cha rade посылает DNS-серверу запрос для адресов notorious, то получает ответ, в котором первым представлен адрес узла notorious в сети В, по скольку в данном случае оба узла принадлежат сети В. В обоих случа ях DNS-сервер производит сортировку адресов в запросе, потому что узел разделяет сеть с узлом DNS-сервера. В сортированном списке ад ресов «более близкий» интерфейс приводится первым.

Теперь немного изменим условия. Допустим, DNS-сервер работает на узле gaslight. Когда spellbound посылает DNS-серверу gaslight запрос адреса notorious, то получает тот же ответ, что в предыдущем случае, поскольку spellbound и gaslight находятся в одной сети, А, что и при водит к сортировке адресов DNS-сервером. Однако узел charade может получить ответ с другим порядком адресов, поскольку не входит в од Рис. 10.3. Связь с локальным мультиинтерфейсным узлом Сортировка адресов DNS-сервером ну сеть с узлом gaslight. Более близкий адрес notorious при этом может оказаться первым в ответе для charade, но только по случайности, а не из-за сортировки адресов DNS-сервером. В данном случае, чтобы вос пользоваться преимуществами сортировки адресов имен BIND 4 на уз ле charade, должен существовать вторичный DNS-сервер в сети В.

Как можно видеть, в существовании DNS-сервера для каждой отдель ной сети есть определенные преимущества: DNS-сервер доступен, если маршрутизатор не работает, да при этом еще и выполняет сортировку адресов мультиинтерфейсных узлов. Поскольку сортировка адресов выполняется DNS-сервером, отпадает необходимость указывать псев донимы при монтировании NFS или для прочих сетевых соединений, чтобы получить лучшую скорость работы.

Удаленные мультиинтерфейсные узлы Предположим, наша площадка часто вступает в контакт с определен ной удаленной площадкой либо «далекой» локальной площадкой, а лучшая производительность получается при выборе тех или иных ад ресов удаленной сети. К примеру, зона movie.edu охватывает сети 192.249.249/24 и 192.253.253/24. Добавим подключение к сети 10/ (старая ARPAnet). Удаленный узел, с которым происходит общение, имеет два сетевых подключения - в сети 10/8 и в сети 26/8. Узел не производит маршрутизацию в сеть 26/8, но по какой-то особой причи не связан с ней. Поскольку маршрутизатор для 26/8 постоянно пере гружен, более высокая производительность получается при использо вании адреса сети 10/8 для удаленного узла (рис. 10.4).

Рис. 10.4. Связь с удаленным мультиинтерфейсным узлом 336 Глава 10. Дополнительные возможности Если пользователь узла terminator.movie.edu устанавливает связь с уз лом reanimator.movie.edu, предпочтительно воспользоваться адресом в сети 10/8, поскольку доступ через шлюз В к адресу 26/8 будет более медленным, чем при использовании прямого маршрута. К сожале нию, DNS-сервер terminator.movie.edu не станет специально возвра щать адрес 10/8 первым в списке адресов reanimator.movie.edu;

дело в том, что terminator.movie.edu входит только в сеть 192.249.249/24, со ответственно ничего не знает о «расстояниях» до адресов 10/8 и 26/8.

На сцене появляется инструкция sortlist. Предпочтительность адресов сети 10/8 определяется следующей строкой файла named.boot:

Аргументы sortlist добавляются к списку поиска по умолчанию. При применении приведенной инструкции sortlist список поиска сервера terminator.movie.edu содержит сети с номерами 192.249.249/24 и 10/8.

Теперь, когда пользователь узла terminator.movie.edu делает запрос к DNS-серверу terminator.movie.edu, а DNS-сервер производит сортиров ку запроса, поскольку запрос локальный, первыми в ответе будут сле довать адреса сети 192.249.249/24. Если в ответе нет адресов сети 192.249.249/24, первыми будут адреса сети 10/8. Это решает описан ную проблему;

теперь при поиске адреса reanimator.movie.edu первым в ответе будет следовать адрес узла в сети 10/8.

Сортировка адресов для подсетей Подсети не сильно влияют на сортировку адресов. Когда DNS-сервер создает список поиска по умолчанию, в него добавляется номер подсе ти, а также номер сети этой подсети. Как и прежде, если запрос явля ется локальным, DNS-сервер производит сортировку адресов, и адрес в общей подсети приводится в ответе первым. К сожалению, не все здесь идеально: нет возможности добавлять в список sortlist элементы для прочих подсетей сети. И вот почему. DNS-сервер предполагает, что элементы списка sortlist представляют номера сетей (а не подсетей), а номер сети уже входит в список сортировки. Поскольку номер сети уже входит в список сортировки, явно определенные элементы sort list, соответствующие той же сети, просто удаляются.

Элементы sortlist И последнее - чтобы добавить несколько элементов в список sortlist, следует перечислить их все в одной строке, следующим образом:

Сортировка адресов в BIND 8 и DNS-серверы BIND 8.2 и более поздних версий (а также 9.1.0 и более поздних версий) также умеют производить сортировку адресов. Одна ко особой автоматизации процесса не наблюдается, а настройка меха Сортировка адресов DNS-сервером низма не особенно проста. Соответствующее предписание оператора options, само собой, носит имя sortlist.

Предписание sortlist в качестве аргумента принимает список отбора адресов. Однако sortlist особым образом интерпретирует списки. Каж дый элемент списка отбора адресов считается списком, который содер жит один, либо два элемента.

Если список содержит один элемент, он используется для проверки IP адреса клиента. Если адрес клиента соответствует элементу, происхо дит сортировка адресов в ответе клиенту, причем адреса, соответству ющие элементу, возвращаются первыми. Запутались? Вот пример:

Единственная запись в списке сортировки состоит из одного элемента.

Этот список сортировки производит сортировку адресов сети 192.249.249/24 для запросов, поступивших также из этой сети.

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

Этот список сортировки применяется для клиентов с адресами 192.249.249/24 и возвращает адреса, отдавая предпочтение адресам из той же сети и из сети 192.253.253/24.

Элементы в списке поиска могут определять как подсети, так и отдель ные узлы:

338 Глава 10. Дополнительные возможности DNS-серверы: предпочтения Механизм топологии в BIND 8 несколько схож с механизмом sortlist, но используется в процессе выбора DNS-серверов. (Топология не под держивается в BIND 9 на момент существования версии 9.1.0.) Ранее мы описывали процесс выбора из серверов, являющихся авторитатив ными для одной зоны, при котором выбирается DNS-сервер с мини мальным временем передачи сигнала (RTT). Но мы слукавили - сов сем чуть-чуть. В действительности BIND 8 помещает удаленные DNS серверы в интервалы длительностью 64 миллисекунды при сравнении показателей RTT. Первый интервал - на самом деле - имеет ширину всего в 32 миллисекунды (ну вот! опять мы обманули читателей!), от нулевой до 32 миллисекунды. Следующий интервал охватывает мил лисекунды с 33 по 96, и т. д. Построение интервалов гарантирует, что DNS-серверы, расположенные на различных континентах, попадают в разные интервалы.

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

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

предписывает локальному DNS-серверу отдавать предпочтение серве рам сети 15/8, а затем серверам сети 172.88/16. Если DNS-сервер вы бирает между DNS-сервером сети 15/8, DNS-сервером сети 172.88/ и DNS-сервером сети 192.168.1/24, в ситуации, когда значения RTT для всех трех попадают в один интервал, будет сделан выбор в пользу DNS-сервера сети 15/8.

Можно указывать отрицание для элементов списка отбора адресов то пологии, штрафуя таким образом DNS-серверы в определенных сетях.

Чем раньше в списке поиска будет найдено соответствие с отрицанием, тем выше штраф. Можно использовать подобный механизм, чтобы Нерекурсивный DNS-сервер удержать DNS-сервер от посылки запросов удаленным DNS-серверам, расположенным, к примеру, в сетях, подверженных частым сбоям.

Нерекурсивный DNS-сервер По умолчанию клиенты BIND посылают рекурсивные запросы, a DNS серверы по умолчанию выполняют работу, которая требуется, чтобы ответить на эти запросы. (Если вы уже подзабыли, как работает рекур сия, загляните в главу 2 «Как работает DNS».) В процессе поиска отве тов на рекурсивные запросы DNS-сервер создает кэш неавторитатив ной информации из других зон.

В некоторых случаях нежелательно, чтобы DNS-серверы выполняли лишнюю работу, связанную с выполнением рекурсивных запросов на полнением кэша данными. Такова, например, ситуация с корневыми DNS-серверами. Корневые DNS-серверы настолько загружены, что не могут позволить себе тратить силы на разрешение рекурсивных запро сов. Вместо этого они возвращают ответы, исходя исключительно из данных, которые лежат в пределах их авторитативности. Ответное со общение может содержать готовый ответ, но чаще всего содержит ссылки на другие DNS-серверы. И, поскольку корневые DNS-серверы не поддерживают рекурсивные запросы, на них не происходит запол нение кэша неавторитативными данными, что очень правильно, по скольку в ином случае кэши разрастались бы до гигантских размеров. С помощью следующего оператора файла настройки можно предпи сать DNS-серверу BIND работать в нерекурсивном режиме:

Для случая DNS-сервера BIND 4.9 следует использовать инструкцию:

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

Чтобы предотвратить заполнение кэша, совместно с предписанием re cursion по следует использовать еще одну дополнительную настройку:

Заметим, что корневой сервер имен в обычной ситуации не получает рекур сивных запросов, если только администратор определенного сервера имен не настроил его на использование корневого сервера в качестве ретрансля тора. Варианты: администратор настроил анализатор на использование корневого сервера имен, пользователь указал корневой сервер имен в ка честве рабочего для nslookup. Такие вещи случаются гораздо чаще, чем можно подумать.

340 Глава 10. Дополнительные возможности Либо, для BIND 4.9:

Данная конструкция запрещает DNS-серверу производить поиск свя зующих записей при создании дополнительного раздела ответа. DNS серверы BIND 9 не производят поиск связующих записей, поэтому предписание fetch-glue в BIND 9 не используется.

Не следует упоминать нерекурсивный DNS-сервер в файле resolv.conf.

DNS-сервер можно сделать нерекурсивным, но не существует настрой ки, которая позволяла бы клиенту работать с таким сервером.1 Если DNS-сервер должен продолжать обслуживать один или несколько клиентов, можно воспользоваться предписанием allow-recursion, кото рое появилось в BIND 8.2.1 (и существует в BIND 9). allow-recursion в качестве аргумента принимает список отбора адресов;

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

По умолчанию allow-recursion разрешает рекурсию для всех IP-адресов.

Кроме того, не следует упоминать нерекурсивный DNS-сервер в ка честве ретранслятора. Когда DNS-сервер использует другой сервер в качестве ретранслятора, то передает ретранслятору рекурсивные за просы. Чтобы разрешить авторизованным DNS-серверам передавать ре курсивные запросы нерекурсивному ретранслятору, воспользуйтесь предписанием allow-recursion.

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

Борьба с фальшивыми DNS-серверами Администратор зоны в процессе работы может обнаружить удаленный DNS-сервер, возвращающий неправильную информацию - устарев шую, несоответствующую действительности, некорректно форматиро Это верно в общем случае. Разумеется, программы, посылающие нерекур сивные запросы, либо программы, которые могут быть настроены таким образом, скажем, nslookup, по-прежнему будут работать.

Борьба с фальшивыми DNS-серверами ванную либо преднамеренно ложную. Можно попытаться связаться с администратором этого сервера и решить проблему. А можно поберечь свои нервы и настроить собственный DNS-сервер таким образом, что бы он не посылал запросы фальшивому;

это можно сделать в DNS-cep верах BIND 4.9, BIND 8, а также BIND 9, начиная с версии 9.1.0. Вот так выглядит оператор настройки:

Или инструкция для сервера BIND 4.9:

Разумеется, следует указывать IP-адрес фальшивого сервера.

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

Наиболее эффективный способ перекрыть взаимодействие с удален ным DNS-сервером - поместить его в список blackhole. DNS-сервер не посылает запросы DNS-серверам из этого списка и не отвечает на за просы, получаемые от этих серверов.1 blackhole - это предписание опе ратора options, аргументом которого является список отбора адресов:

Эта конструкция запретит DNS-серверу отвечать на запросы, получа емые с внутренних адресов (см. документ RFC 1918). В сети Интернет отсутствуют маршруты к этим адресам, и попытка отвечать - пустая трата процессорного времени и излишняя загрузка канала.

Предписание blackhole поддерживается версиями BIND 8 начиная с 8.2, а также версиями BIND 9 после 9.1.0.

И мы действительно имеем в виду отсутствие ответа. Для запросов, за прещенных списком allow-query, будет сгенерирован ответ, сообщающий, что в выполнении запроса отказано. Запросы, запрещенные списком black hole, не получат никакого ответа. Вообще.

342 Глава 10. Дополнительные возможности Настройка системы Для большинства DNS-серверов стандартные настройки BIND вполне подходят для работы, но иногда необходимо внести дополнительные коррективы. В этом разделе мы обсудим разнообразные ручки и перек лючатели, позволяющие настраивать DNS-сервер.

Передача зон Передача зон может быть связана с большой нагрузкой на DNS-сервер.

В DNS-серверах BIND 4 для исходящих передач зон (в случае, когда сервер является основным для зоны) требуется fork( ) процесса named, а значит - значительные объемы памяти. В BIND 4.9 появились спосо бы ограничивать нагрузку, связанную с передачей зон основными сер верами. В BIND 8 и 9 помимо этих механизмов существуют дополни тельные возможности.

Ограничение числа запросов для отдельных DNS-серверов Начиная с BIND 4.9 существует возможность ограничить число пере дач зон, одновременно запрашиваемых DNS-сервером с конкретного удаленного сервера. Это счастье для администратора удаленного сер вера, поскольку в случае изменения всех зон его сервер не будет зава лен запросами на передачу - а это немаловажно, если речь идет о сот нях зон.

В BIND 8 и 9 соответствующий оператор настройки выглядит так:

Эквивалентная инструкция загрузочного файла BIND 4:

В BIND 9 предел может быть определен либо частным образом для от дельных DNS-серверов, либо глобально. Частное определение произ водится с помощью предписания transfers оператора server:

Частное предписание имеет более высокий приоритет, чем глобальное, которое присутствует в операторе options. По умолчанию предел уста новлен в два активных процесса передачи зоны на DNS-сервер. Может показаться, что ограничение слишком суровое, но такая настройка ра ботает. Происходит следующее. Предположим, DNS-серверу нужно Настройка системы произвести загрузку четырех зон с удаленного сервера. DNS-сервер на чинает получение первых двух зон, оставляя третью и четвертую в очереди. После завершения одного из первых двух процессов, DNS сервер начинает получение третьей зоны. После завершения еще одно го процесса, DNS-сервер инициирует процесс получения четвертой зо ны. Конечный результат такой же, как и до появления ограничений, все зоны получены;

но при этом процесс длился чуть дольше.

Когда может возникнуть необходимость увеличить это ограничение?

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

Ограничение общего числа запросов на передачу зон Последнее ограничение было связано с получением зон с удаленного DNS-сервера. Описываемое в данном разделе позволяет установить ог раничение для нескольких удаленных DNS-серверов. Начиная с вер сии 4.9 BIND позволяет ограничивать общее число параллельно запра шиваемых DNS-сервером зон. По умолчанию установлен предел в 10 зон. Как мы только что говорили, DNS-сервер по умолчанию парал лельно может получать только две зоны от каждого из удаленных DNS-серверов. Если DNS-сервер производит получение пар зон с пяти удаленных DNS-серверов, значит он достиг предела и отложит все про чие запросы, пока не будет завершен один из текущих процессов.

Оператор настройки для BIND 8 и 9:

Эквивалентная инструкция загрузочного файла BIND 4:

Если узел или сеть не справляется с десятью параллельными процесса ми передачи зон, следует уменьшить это число. Когда же речь идет о сервере, обслуживающем сотни и тысячи зон, возможно, имеет смысл увеличить предел, если узел и сеть способны справиться с такой на грузкой. При увеличении этого предела возможно понадобится увели чить и число разрешенных параллельных процессов на каждый DNS сервер. (К примеру, если DNS-сервер производит получение данных от всего лишь четырех удаленных серверов, то по умолчанию сможет па раллельно производить получение лишь восьми зон. Увеличение пре 344 Глава 10. Дополнительные возможности дела общего числа процессов в таком случае не имеет смысла, если не ослабляются ограничения для отдельных DNS-серверов.) Ограничение общего числа исходящих передач зон В DNS-серверах BIND 9 существует возможность ограничивать число параллельных процессов для передачи зон другим серверам. Это едва ли не более полезно, чем ограничение числа запрашиваемых передач, поскольку последнее заставляет полагаться на доброту администрато ров вторичных DNS-серверов и на то, что они не будут перегружать наш основной сервер. Оператор BIND 9:

По умолчанию принимается значение 10.

Ограничение длительности передачи зоны DNS-серверы BIND 8 и 9 позволяют ограничить продолжительность про цесса получения зоны. По умолчанию устанавливается порог в 120 ми нут (два часа). Смысл заключается в том, что процесс передачи зоны, который длится более двух часов, вероятнее всего, просто «повис» и уже никогда не завершится, потребляя, между тем, драгоценные ре сурсы. Уменьшить или увеличить этот временной интервал (скажем, если DNS-сервер является вторичным для зоны, получение копии ко торой обычно занимает больше двух часов) можно с помощью операто ра следующего вида:

Ограничить время получения для отдельной зоны можно с помощью предписания max-transfer-time-in в операторе zone. К примеру, если известно, что получение зоны rinhydink.com всегда занимает много времени (допустим, три часа) из-за размеров зоны либо из-за медлен ного канала связи с основным сервером, но для всех прочих зон нужно установить более низкий порог (в районе часа), можно использовать такие операторы:

Настройка системы В BIND 9 существует предписание max-transfer-time-out, которое мо жет использоваться таким же образом (в операторе options или zone).

Оно позволяет определить максимальную длительность исходящей пе редачи зоны (то есть передачи данных вторичному DNS-серверу);

по умолчанию принимается такое же, как и для max-transfer-time-in, по роговое значение - 120 минут.

BIND 9 позволяет также определять максимально допустимую длину интервала времени простоя при передаче зоны. Два предписания на стройки, max-transfer-idle-in и max-transfer-idle-out, позволяют опре делять этот параметр для входящих и исходящих передач зон, соот ветственно. Оба предписания могут быть использованы в операторах options и zone. По умолчанию принимается пороговое значение в минут.

Ограничение частоты передачи зон Интервал обновления для зоны может быть установлен в столь малое значение, что вторичные DNS-серверы зоны будут выполнять ненуж ную работу. К примеру, если DNS-сервер является вторичным для многих тысяч зон, а администраторы некоторых из этих зон устанав ливают значения интервалов обновления в очень низкие значения, DNS-сервер может просто не успевать выполнять синхронизацию для всех зон. (Если речь идет о DNS-сервере, который является вторичным для действительно большого числа зон, обязательно прочтите раздел «Ограничение числа SOA-запросов»;

может появиться необходимость в ограничении числа выполняемых SOA-запросов.) С другой стороны, неопытный администратор может установить слишком большой ин тервал обновления, который будет приводить к рассинхронизации первичного DNS-мастер-сервера зоны и вторичных DNS-серверов на длительные промежутки времени.

Начиная с версии 9.1.0, в BIND появилась возможность ограничивать интервалы обновления с помощью предписаний max-refresh-time и min-refresh-time. Эти предписания определяют множество допусти мых значений для всех основных и вторичных зон и зон-заглушек при использовании в операторе options либо для конкретной зоны - при ис пользовании в операторе zone. В качестве аргументов выступает коли чество секунд:

Помимо этого, начиная с версии 9.1.0, DNS-серверы позволяют огра ничивать допустимые значения для интервала повторения с помощью предписаний max-retry-time и min-retry-time, которые имеют тот же синтаксис.

346 Глава 10. Дополнительные возможности Повышение эффективности при передаче зон Передача зоны, как мы уже говорили, состоит из многочисленных со общений, которыми стороны обмениваются через ТСР-соединение.

При традиционной передаче зоны каждое сообщение DNS содержит только одну запись. Это очень неэффективно: каждое сообщение долж но содержать полный заголовок, даже если оно инкапсулирует единст венную запись. Это все равно что возить одного человека в пассажир ском автобусе. DNS-сообщение, передаваемое через ТСР-соединение, может содержать гораздо больше записей, поскольку его размер огра ничен порогом в 64 килобайта!

DNS-серверы BIND 8 и 9 понимают новый формат передачи данных зо ны, который носит название many-answers. В формате many-answers в одно сообщение DNS помещается максимальное число записей. В ре зультате передача зоны в формате many answers намного меньше за гружает канал, за счет сокращения издержек транспортировки, и про цессор, за счет сокращения времени, уходящего на разбор сообщений DNS.

Формат, используемый DNS-сервером для передачи зон, для которых он является первичным мастером, может быть определен с помощью предписания transfer-format. To есть это предписание определяет фор мат, используемый для передачи зоны вторичным DNS-серверам.

transfer-format может являться предписанием оператора options или server;

в качестве предписания options transfer-format определяет гло бально используемый формат передачи зон. В BIND 8 по умолчанию используется старый формат передачи зон, one-answer, который обес печивает совместимость с DNS-серверами BIND 4. В BIND 9 по умол чанию используется формат many-answers. Оператор:

предписывает DNS-серверу использовать для передачи зон всем вто ричным DNS-серверам формат many-answers, за исключением случа ев, когда оператор server, подобный приводимому ниже, предписывает обратное:

У формата many-answers есть один недостаток - передача зоны может на деле занимать больше времени, чем при применении старого фор мата, несмотря на повышение эффективности загрузки канала и ис пользования процессора.

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

Настройка системы • Установите глобальный формат передачи зон в many-answers (либо не делайте этого, если используется BIND 9), если большинство вто ричных DNS-серверов работает под управлением BIND 8, BIND или сервера Microsoft DNS, который также реализует поддержку нового формата.

• Установите глобальный формат передачи зон в one-answer, если большинство вторичных DNS-серверов работает под управлением BIND 4. Затем воспользуйтесь предписанием transfer-format опера тора server, чтобы частным образом произвести настройку для сер веров, которые представляют собой исключения.

Помните, что при использовании BIND 9 потребуется добавить явный оператор server в файлы настройки всех вторичных DNS-серверов BIND 4 с целью выбора для них формата one-answer.

Ограничение ресурсов Иногда просто требуется сказать DNS-серверу, чтобы он не жадничал:

использовал меньше памяти, открывал меньше файлов. Возможности определения подобных ограничений появились в BIND 4.9, а в BIND и 9 — как и для многих других новых возможностей - существуют ва риации на тему таких настроек.

Изменение ограничения размера сегмента данных Некоторые операционные системы ограничивают объем памяти, до ступный отдельному процессу. Если операционная система не позволя ет DNS-серверу получить дополнительную память, это может привести к останову или завершению работы DNS-сервера. Предел доступной для использования памяти может быть достигнут, если сервер работа ет с очень большими объемами данных, либо если установлено низкое ограничение. Для таких случаев в BIND 4.9, BIND 8 и BIND 9, начи ная с версии 9.1.0, предусмотрено несколько параметров, которые позволяют изменять умолчание системного ограничения для размера сегмента данных. С помощью этих настроек можно установить для па med большее пороговое значение, чем предлагается системой.

В BIND 8 и 9 оператор выглядит так:

Эквивалентная инструкция BIND 4:

size (размер) - целочисленное значение, по умолчанию в байтах. Мож но указывать альтернативные единицы измерения, добавляя к разме ру соответствующую букву: к - килобайты, m - мегабайты, g - гига байты. К примеру, «64m» - это 64 мегабайта.

348 Глава 10. Дополнительные возможности Не во всех операционных системах реализована поддержка увеличения размера сегментов данных для отдельных про цессов. В случае отсутствия такой поддержки DNS-сервер записывает сообщение syslog с приоритетом LOG_WAR NING, чтобы уведомить администратора о проблеме.

Изменение ограничения размера стека DNS-серверы BIND 8 и BIND 9, начиная с версии 9.1.0, позволяют из менять не только ограничение размера сегмента данных, но и произво дить подстройку объема памяти, выделяемого операционной системой под стек процесса named. Синтаксис оператора следующий:

Размер size имеет тот же формат, что и аргумент предписания datasi ze. Как и datasize, stacksize работает только в системах, которые поз воляют процессам изменять размер стека.

Изменение ограничения размера файла образа Если вам не нравится, что named оставляет за собой гигантские файлы образов (core files), можно сократить их размер с помощью предписа ния coresize. И наоборот, если процесс named не смог создать полный файл образа из-за слишком жестких ограничений, накладываемых операционной системой, предел можно увеличить с помощью все того же предписания. Синтаксис coresize:

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

Изменение ограничения для числа открытых файлов Если DNS-сервер является авторитативным для большого числа зон, процесс named при запуске открывает большое число файлов - по од ному на авторитативную зону;

предполагается, что существуют ре зервные копии файлов зон, для которых DNS-сервер является вторич ным. Аналогично, если на узле DNS-сервера существует большое чис ло виртуальных сетевых интерфейсов1, named требует наличия одного В главе 14 «Разрешение проблем DNS и BIND» описаны более разумные ре шения для проблемы слишком большого числа открытых файлов.

Настройка системы файлового дескриптора на каждый интерфейс. В большинстве опера ционных систем Unix существуют ограничения для числа файлов, ко торые единовременно могут быть открыты одним процессом. Если DNS-сервер попытается открыть больше файлов, чем разрешено, в вы воде syslog появится следующее сообщение:

Если операционная система позволяет изменять это ограничение для отдельных процессов, можно увеличить соответствующее значение с помощью предписания files:

По умолчанию используется (вполне допустимое) значение unlimited (без ограничений), хотя оно просто означает, что DNS-сервер не огра ничивает число одновременно открытых файлов, хотя это число мо жет ограничивать операционная система. Мы знаем, что читателей уже тошнит от этой фразы, но - в BIND 9 это предписание не поддер живается до версии 9.1.0.

Ограничение числа клиентов BIND 9 предоставляет администратору возможность ограничить число клиентов, параллельно обслуживаемых DNS-сервером. Число рекур сивных клиентов (это клиенты и DNS-серверы, одновременно исполь зующие данный сервер в качестве ретранслятора) можно ограничить с помощью предписания recursive-clients:

По умолчанию принимается значение 1000. Если окажется, что DNS сервер отказывается выполнять рекурсивные запросы и заносит в log файл ошибок сообщения следующего рода:

можно увеличить пороговое значение. И наоборот, если DNS-сервер с трудом успевает выполнять все получаемые рекурсивные запросы, следует это значение уменьшить.

Помимо этого, существует возможность ограничить число параллель но существующих TCP-соединений (для передачи зон и ТСР-запросов) с помощью предписания tcp-clients. TCP-соединения потребляют го раздо больше ресурсов, чем UDP-соединения, поскольку узел должен отслеживать состояние каждого TCP-соединения. Значение по умол чанию - 100.

350 Глава 10. Дополнительные возможности Ограничение числа SOA-запросов Начиная с BIND 8.2.2, DNS-серверы позволяют ограничивать число ожидающих обработки SOA-запросов. Если сервер является вторич ным для многих тысяч зон, в каждый отдельный момент времени в очереди запросов может находиться большое число запросов SOA-за писей. Отслеживание каждого такого запроса требует небольшого, но фиксированного количества памяти, которая имеет обыкновение кон чаться, поэтому в DNS-серверах BIND 8 число таких запросов ограни чено до четырех. Если DNS-сервер не успевает в таком темпе выпол нять свои обязанности вторичного, предел можно увеличить с помо щью предписания serial-queries:

Предписание serial-queries вышло из употребления в BIND 9. BIND ограничивает скорость посылки SOA-запросов (не более 20 в секунду), но не число ожидающих обработки.

Интервалы служебных операций DNS-серверы BIND традиционно выполняли периодические хозяйст венные работы, такие как обновление зон, для которых являются вто ричными. В BIND 8 и 9 появилась возможность управления частотой выполнения таких работ.

Интервал чистки DNS-серверы BIND до версии 4.9 удаляют старые записи из кэша в пассивном режиме. Прежде чем вернуть запись клиенту, DNS-сервер проверяет, не истекло ли время жизни этой записи. Если значение TTL обнулилось, DNS-сервер начинает процесс разрешения, чтобы найти более актуальные данные. Это означает, что DNS-сервер BIND может кэшировать множество записей в суматохе разрешения имен, после чего эти записи будут спокойно портиться в кэше, занимая дра гоценную память даже в случае устаревания.

DNS-серверы BIND 8 и 9 производят активное исследование кэша и удаление устаревших записей каждый интервал чистки. Это означает, что DNS-серверы BIND 8 и 9 обычно занимают меньше памяти под кэ шируемые данные, чем аналогичный DNS-сервер BIND 4. С другой стороны, процесс чистки приводит к потреблению процессорного вре мени, так что на медленных или сильно загруженных DNS-серверах не очень эффективно производить чистку каждый час.

Интервал чистки по умолчанию устанавливается в 60 минут. Изме нить его можно с помощью предписания cleaning-interval оператора options. Следующая конструкция:

Настройка системы устанавливает интервал чистки в 120 минут. Чтобы полностью отклю чить чистку кэша, следует воспользоваться нулевым значением для интервала.

Интервал сканирования интерфейсов Мы уже говорили, что по умолчанию BIND производит прослушива ние всех сетевых интерфейсов узла. DNS-серверы BIND 8 и 9 достаточ но интеллектуальны, чтобы заметить, когда один из сетевых интер фейсов узла перестает работать или вновь включается. С этой целью они периодически сканируют сетевые интерфейсы узла. Сканирова ние производится один раз за интервал сканирования, который по умолчанию длится 60 минут. Если известно, что на узле отсутствуют динамические сетевые интерфейсы, сканирование новых интерфейсов можно отключить, чтобы избежать ненужных издержек - установив нулевое значение интервала сканирования интерфейсов:

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

Pages:     | 1 |   ...   | 3 | 4 || 6 | 7 |   ...   | 9 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.