Адресная запись "Address". Балансировка нагрузки. Round Robin. Учет топологии сетей.
В этом материале подробно разбирается формат, назначение и способы применения адресной записи описания ресурсов системы DNS. Особое внимание уделено также вопросам перебора адресных записей с целью баланс нагрузки на сервисы Internet.
Основное назначение адресной записи - установить соответствие между доменным именем машины и IP-адресом. Собственно, это главная задача всей системы доменных имен. По этой причине адресная запись описания ресурса является одной из ключевых записей описания зоны.
Вообще говоря, перед прикладным программным обеспечением, которое работает с DNS, всегда стоит две основных задачи. Во-первых, зная доменное имя хоста, найти его IP-адрес, а, во-вторых, зная IP-адрес, установить доменное имя. Первую задачу будем называть "прямой", а вторую "обратной".
При описании зон используется та же терминология. "Прямая" зона служит для решения "прямой задачи", а "обратная" зона - для решения "обратной" задачи. Решение как прямой, так и обратной задачи не являются тривиальными, т.к. каждому доменному имени можно поставить в соответствие несколько IP-адресов и, наоборот, каждому IP-адресу можно поставить в соответствие несколько доменных имен.
Обе задачи система DNS решает посредством так называемых стандартных запросов (standard queries), в которых указывается доменное имя (QNAME), тип записи описания ресурсов(QTYPE) и класс записи описания ресурсов (QCLASS).
Как при помощи этих трех параметров решается "обратная" задача мы рассмотрим в материале, посвященном записи описания ресурсов типа PTR (Pointer, указатель). "Прямую" задачу решают при помощи адресной записи описания ресурсов, которая имеет тип "A".
Адресная запись - это основа файла описания "прямой" зоны. Запись имеет следующий формат:
[host][ttl] IN A [address]
Поле
Авторитативный отклик (authoritative response)
возвращают серверы, которые являются ответственными за зону, в которой описана информация, необходимая resolver-у (клиент DNS).
BIND
- это одна из реализаций идеи и спецификаций DNS. Самая популярная, одна из самых совершенных на данный момент, но не единственная. BIND обеспечивает поиск доменных имен и IP адресов для любого узла Сети, взаимодействие с системой электронной почты, поддержку программного обеспечения динамической настройки хостов и т.п. Именно BIND установлен на серверах обеспечивающих поддержку корневой зоны.
Пакет Berkeley Internet Name Domain был первоначально разработан в университете Беркли (Калифорния) в качестве работы на соискания ученой степени доктора философии (graduate student project) по гранту DARPA. Авторами первоначальной версии пакета были Дуглас Терри (Douglas Terry), Марк Пайтер (Mark Painter), Давид Райгл (David Riggle) и Сонгниан Зоу(Songnian Zhou).
В Беркли BIND "прожил" до версии 4.8.3. Версии 4.9 и 4.9.1 были разработаны в DEC, которая волшебным образом превратилась с некоторых пор в COMPAQ. В настоящее время пакет поддерживает Internet Software Consortium.
Существует множество версий пакета. До самого недавнего времени наиболее распространенной была версия 4 и ее модификации. В настоящее время все работы по ней приостановлены. Рекомендуемой к использованию является версия 9, которая существует в своей наиболее свежей ипостаси, как BIND 9.2.1. Часто используются и 8-ые версии пакета.
Автор BIND Paul Vixie рекомендует пользоваться 9-ой версией программы, которая является абсолютно новым продуктом, разработанным для функционирования в агрессивной среде современного Интернета. По его утверждению все версии BIND до 8-ой включительно опирались на код, который написали аспиранты Berkeley. Последние выпуски 8-ой версии исчерпали все возможности по улучшению кода, что и привело к появлению 9-ой версии программы, которая была полностью переписана профессионалами с применением методов "контрактного" проектирования.
BIND состоит из трех компонентов:
сервера доменных имен (Domain Name System Server) named; библиотеки ПО revolver; средств обеспечивающих правильную настройку и работу сервера.
Первые две позиции из этого списка обеспечивают заложенную в DNS архитектуру "клиент-сервер", последняя позиция позволяет упростить настройку сервера и управление его функционированием.
Обычно, модули resolver-а находятся в библиотеке libc.a, если речь идет о системе UNIX, и редактируются вместе с программой, использующей вызовы gethostbyname и gethostbyaddr. BIND работает как со стандартной библиотекой resolver, которая поставляется с операционной системой, так и с собственной библиотекой.
Работа с его собственной библиотекой дает дополнительные преимущества, т.к., во-первых, можно будет работать с "умным" resolver, а, во-вторых, можно будет использовать новые относительно RFC-1034 и RFC-1035 возможности DNS.
BIND адаптирован для большинства современных компьютерных платформ, в том числе и для Windows. Практическая работа с системой доменных имен (администрирование серверов) тесно связана с практикой применения BIND.
Наиболее существенные отличия BIND 9.2.1 (последняя версия на момент написания этого материала) от предыдущих версий:
Безопасность DNS (DNSSEC, TSIG) IPV6 Улучшения в протоколе DNS (IXFR, DDNS, Notify, EDNSO) Более полное соответствие процедурам, описанным в протоколах Мультипроцессорная поддержка Улучшенная переносимость Поддержка подсхем пространства доменных имен
Дистрибутив BIND можно получить с сайта разработчиков - ftp://ftp.isc.org/isc/bind9/9.2.1/bind-9.2.1.tar.gz , либо с одного из официальных зеркал - http://www.isc.org/ISC/MIRRORS.html.
Выше указан дистрибутив пакета, который содержит исходный код. Его нужно предварительно собрать. Для Windows и Linux можно воспользоваться собранным кодом.
Впрочем, собрать BIND несложно. Для этого его нужно распаковать:
>tar -zxvf bind-9.2.1.tar.gz
После этого в каталоге, где размещен архив BIND, будет создан каталог bind-9.2.1. Следует перейти в этот каталог и выполнить команды:
>./configure >make
Для установки BIND следует выполнить:
>make install
По умолчанию все будет установлено в /usr/local с соответствующей разбивкой по подкаталогам.Если нужна какая-то нестандартная установка, то лучше посмотреть внимательнее документацию, которая также содержится в дистрибутиве.
Для запуска сервера нужно создать файлы настройки и описания зон, если это необходимо, но об этом мы поговорим в разделе "Настройка сервера. Файлы конфигурации Named".
BIND (Berkeley Internet Name Domain). Общие сведения
В этом материале речь пойдет о том, что такое BIND, в чем его отличие от DNS, из каких компонентов он состоит, и как его получить и установить.
BIND или Berkeley Internet Name Domain - это пакет программного обеспечения для поддержки DNS, реализованный в университете Беркли. Он широко применяется в Сети. Основная масса серверов DNS - это серверы различных версий BIND.
Иногда название BIND (Berkeley Internet Name Domain) вводит новичков в заблуждение. Им кажется, что речь идет не о программе, а некой альтернативе другой системе доменных имен. Для того чтобы этого избежать, иногда вместо слова "domain" используют слово "daemon", обычно употребляющиеся для обозначения программ-демонов в системах Unix, которые находятся в памяти компьютера и выполняют служебные операции. Для того чтобы потом не повторяться, сразу поясним различия между DNS и BIND.
Class
определяет класс записи описания ресурса. В Internet используется только один класс записей - класс IN. В принципе существуют еще классы HS(Hessiod) и CH(Chaos), но в рамках нашего контекста - системы доменных имен Internet - они не рассматриваются.
Некоторые авторы, например, Ronny H.Kavli, который написал комментарии к FAQ Kaig Richmond-а, считают, что наличие этого поля только "замутняет чистый лик" базы данных описания ресурсов DNS. В любом случае все записи из базы данных named имеют вид:
IN
Поле type определяет тип записи описания ресурсов. К таким типам относятся: SOA (Start Of Authority), NS( Name Server), A(Address), MX(Mail eXchanger) CNAME(Canonical NAME), WKS(Well Known Services), PTR(PoinTeR), HINFO(Host INFOrmation) и др.
Перечисленные выше типы записей составляют набор стандартных записей, которые могут встретиться в базе данных описания домена. Кроме этих типов существуют еще и экспериментальные типы.
Следует заметить, что не все стандартные записи используются в базах данных описания доменов. Так администраторы редко пользуются записями типа HINFO и WKS. Некоторые администраторы считают, что вместо CNAME лучше назначить еще один адрес через запись типа A, существуют и другие предпочтения.
В поле data указываются данные для каждой записи описания ресурсов. Для различных типов записей формат данных также различный и соответствует назначению записи описания ресурсов.
При описании элементов записи описания ресурса можно применять маскирование символов. Маскирование символов применяется в том, случае, если необходимо использовать символ, который имеет особое значение для записей описания ресурсов. Например, символ "@". Для этого используется символ обратного слэша "\". Аналогично языку программирования С символ можно указывать и цифрами. Только в этом случае используется десятичное число, которое соответствует коду ASCII, например, "\040" также обозначает символ "@".
Настоятельно рекомендуем не использовать маскирования символов в файлах описания зон.
Contact
определяет почтовый адрес лица, осуществляющего администрирование зоны. Данный адрес должен совпадать со значением адреса указанным в заявке на домен. Есть, однако, одна особенность при указании этого адреса. Так как символ "@" имеет особый смысл при описании зоны, то вместо этого символа в почтовом адресе используется символ ".".
Например, если ваш администратор домена имеет почтовый адрес adm@kyky.ru, то в поле contact следует писать не adm@kyky.ru, а adm.kyky.ru.
Если в имени пользователя есть какие-либо особые символы, имеющие специальные значения при описании зоны, то они должны маскироваться символом обратного слэша - "\".
Типичный пример - почтовый адрес типа user.name@kuku.ru. В этом случае точку следует замаскировать и написать в поле contact: user\.name.kuku.ru. Поступая таким образом, мы исключили особое значение точки как разделителя поддоменов и обеспечили интерпретацию имени как единой символьной строки.
Вообще говоря, почтовые адреса приведенного выше типа не являются редкостью, но у администраторов компьютерных систем встречаются очень редко. Кроме того, если следовать рекомендациям (RFC 2142), то лучше всего, чтобы администратор DNS сервера имел адрес hostmaster@kuku.ru.
Поле данных в записи SOA разбито на аргументы, которые определяют порядок работы сервера с записями описания зоны. Как правило, все аргументы располагают на другой строке или, для лучшего отображения, каждый на своей строке, что заставляет записывать их внутри скобок. Напомним, что скобки позволяют продлить запись описания ресурса на несколько строк, а символы табуляции и пробелы разделяют поля записи описания ресурса между собой.
Атрибут
Cредства и методы тестирования работы системы доменных имен, отличные от nslookup, host и dig
В этом материале речь пойдет о программах, которые нечасто используются при работе с системой доменных имен, в том числе и о тех, которые имеют преданных и активных сторонников. Всех их можно подразделить на конкурентов BIND, программы тестирования серверов, программы тестирования DNS. Альтернативные BIND серверы доменных имен мы здесь рассматривать не будем.
Было бы странно, если при обсуждении проблем системы доменных имен мы не упомянули об авторе qmail профессоре Бернштейне (D J Bernstein aka DJB). Почтовый транспортный агент (в современной терминологии, после выхода в свет RFC - 2821, почтовый сервер) qmail имел и имеет до сих довольно много приверженцев и стойко удерживает второе место по числу установок в Сети.
Qmail - это не единственное детище DJB. В контексте нашей проблемы нас больше всего будут интересовать djbdns - набор средств работы с системой доменных имен. Будучи настоящим математиком, DJB сконцентрировал свои усилия при разработке djbdns на вопросе точного соблюдения спецификаций, безопасности и надежности кода.
В отличии от BIND djbdns состоит из нескольких независимых компонентов, которые запускаются в системе как независимые процессы. Более того, каждый процесс (демон) должен быть запущен с правами уникального пользователя.
DNScache - это кэширующий сервер, который выполняет рекурсивные запросы локальных клиентов. Tynidns - это сервер, который отвечает только на udp запросы к своей зоне. Axfrdns и axfr-get используются при обмене данными зоны по TCP.
При работе с djbdns не нужно самому руками править зону. Для этого есть несколько специальных утилит. Кроме самого djbdns на ваш Unix-клон придется поставить еще парочку продуктов: daemonstools, ucspi-tcp. Эти продукты необходимы для работы djbdns и обеспечивают пакету приемлемую безопасность и быстродействие.
Вообще говоря, если решиться на замену BIND и прочего программного обеспечения на gjbdns, то следует приготовиться к маленькой революции в вашей Unix-системе, а также научиться без ошибок набирать тексты в командной строке.
Из всего множества программ djbdns мы остановимся только на программах получения информации из системы доменных имен, а также на программах тестирования работы серверов. При описании этих программ мы будем опираться только на описание DJB и свой собственный опыт, т.к. установленный нами пакет не содержал более подробной документации, чем так, которая приведена в списке полезных ссылок к данному материалу.
И так, для получения информации из системы DNS в djbdns используются: dnsip, dnsipq, dnsname, dnsmx, dnstxt.
Dnsip позволяет получать IP-адрес хоста, если задано полное (FQDN) доменное имя этого хоста. Если имя задано частично, то получаем пустую строку. Перебор имен доменов в данном случае не осуществляется.
generate# ./dnsip quest.polyn.kiae.su. 144.206.192.2 generate#
Мы попросили у dnsip IP-адрес хоста quest.polyn.kiae.su. Задавать символ точки на конце имени не обязательно. Имена можно перечислять в качестве аргументов командной строки. В последнем случае каждый ответ будет напечатан на отдельной строке:
generate# ./dnsip quest.polyn.kiae.su www.ru 144.206.192.2 194.87.0.50 generate#
Для того, чтобы получать адреса для имен, заданных частично, следует воспользоваться программой dnsipq:
generate# dnsipq quest cpuv1 quest.polyn.kiae.su 144.206.192.2 cpuv1.kiae.su 193.124.22.22 generate#
В первом случае произведена подстановка всего доменного имени, а во втором фрагмента доменного имени, состоящего из двух частей, что соответствует алгоритму подстановки resolver. Если теперь попросить более мелкий фрагмент доменного имени, то мы ничего не получим:
generate# dnsipq relarn relarn. generate#
Хоста relarn в доменах polyn.kiae.su и kiae.su нет, а просто ru не применяется в переборе resolver-а. Попутно заметим, что djbdns не использует resolver BIND или тот, который установлен по умолчанию.
Еще один интересный момент:
generate# dnsipq www www.polyn www.polyn.kiae.su 144.206.160.32 www.polyn generate#
Адрес для хоста www.polyn.kiae.su в принципе существует, но заданное частично начало имени не позволяет его найти.
Теперь от поиска IP-адресов по именам перейдем к поиску имен по IP-адресам. Для этого в djbdns служит программа dnsname:
generate# ./dnsname 144.206.192.55 generate.polyn.kiae.su generate#
Все так же лаконично, как и в случае поиска адресов - задаем адрес и получаем имя. Поиск, естественно, осуществляется по "обратным" зонам, но преобразовывать IP-адрес в формат зоны in-addr.arpa не нужно.
Точно так же, как и в случае dnsip, в dnsname можно задавать запрос на поиск нескольких имен:
generate# ./dnsname 144.206.192.55 144.206.160.32 generate.polyn.kiae.su polyn.net.kiae.su generate#
Каждый ответ будет печататься в этом случае на отдельной строке.
Вообще говоря, в djbdns есть программа-фильтр, которая прямо так и называется dnsfilter. Ее главное назначение принимать из потока стандартного ввода IP-адреса, и выдавать в поток стандартного вывода доменные имена:
generate# ./dnsfilter 144.206.192.1 144.206.192.1 144.206.192.2 144.206.192.2=quest.polyn.kiae.su 144.206.192.55 144.206.192.55=generate.polyn.kiae.su 144.206.160.32 144.206.160.32=polyn.net.kiae.su generate#
Как видно из примера, если соответствие существует, то выдается строка типа "IP-адрес=доменное_имя", если не существует, то просто на стандартный вывод копируется IP-адрес. В примере dnsfilter использовался как простая интерактивная команда, хотя основное ее назначение работать в связке с другими командами в качестве фильтра.
На самом деле есть еще один интересный момент:
generate# ./dnsname 127.0.0.1.
generate#
Мы пытаемся найти имя для адреса 127.0.0.1. Система его, естественно, не находит, потому, что не знает к кому обращаться за ним. Для этой сети в in-adrr.arpa зона не поддерживается.
А вот dig нам ответ дает совершенно запросто:
generate# ./dig @localhost -x 127.0.0.1 +short localhost.polyn.kiae.su. generate#
Мы запрашиваем локальный сервер, а на нем обратная зона 0.0.127.in-addr.arpa определена.
Мы сейчас оставим за скобками правомерность такого запроса вообще.
Пример нужен был нам для того, чтобы обратить внимание на аргумент, который в dnsname, dnsip и dnsipq мы не использовали - имя сервера, к которому мы обращаемся запросом. В конце концов, если не указывать имя сервера, то и dig ничего не вернет:
generate# ./dig -x 127.0.0.1 +short generate#
Следующая программа - это dnsmx. Она позволяет получить MX записи для заданного доменного имени:
generate# ./dnsmx polyn.kiae.su 10 polyn.kiae.su 20 relay1.relcom.ru generate#
Если для заданного имени нет MX записей, то возвращается искусственная несуществующая запись:
generate# ./dnsmx kuku.polyn.kiae.su 0 kuku.polyn.kiae.su generate#
Тем самым dnsmx моделирует работу MTA.
Такое внимание к MX записям объясняется наличием ошибок при описании зоны в части прописывания пересылки почты внутри зоны. Например, наличие петель пересылки.
Другая команда, dnstxt, написана, видимо, по причине использования TXT записей для совершенно разных функций. Например, для ограничения доступа к зоне (secure_zone TXT запись). Привести толковый пример использования TXT записи сложно. Перебирая провайдеров, мы наткнулись только на demos.ru:
generate# ./dnstxt demos.ru $Id: demos.ru,v 1.3 2002/05/13 08:14:45 rvp Exp $ generate#
В качестве отклика отображается та часть записи, которая относится к полю DATA (см. "Описание зоны. Формат записи описания ресурсов RR."):
demos.ru. 86361 IN TXT "$Id: demos.ru,v 1.3 2002/05/13 08:14:45 rvp Exp $"
Теперь рассмотрим программы для тестирования работы собственно серверов: dnsqr, dnsq, dnstrace. Программу tinydns-get мы опустим, т.к. это компонента сервера и требует установки дополнительного программного обеспечения в отличие от других команд.
Программа dnsqr посылает рекурсивные запросы на получение записей определенного типа для доменного имени, которое задается последним аргументом командной строки:
generate# ./dnsqr any polyn.kiae.su 255 polyn.kiae.su: 338 bytes, 1+7+3+5 records, response, authoritative, noerror query: 255 polyn.kiae.su answer: polyn.kiae.su 3600 NS polyn.net.kiae.su answer: polyn.kiae.su 3600 NS ns.spb.su answer: polyn.kiae.su 3600 NS ns.ussr.eu.net answer: polyn.kiae.su 3600 SOA polyn.net.kiae.su paul.kiae.su 233 3600 300 99999 99 3600 answer: polyn.kiae.su 3600 MX 10 polyn.kiae.su answer: polyn.kiae.su 3600 MX 20 relay1.relcom.ru answer: polyn.kiae.su 3600 A 144.206.160.32 authority: polyn.kiae.su 3600 NS polyn.net.kiae.su authority: polyn.kiae.su 3600 NS ns.spb.su authority: polyn.kiae.su 3600 NS ns.ussr.eu.net additional: polyn.net.kiae.su 70984 A 144.206.160.32 additional: ns.spb.su 135020 A 193.124.83.69 additional: ns.ussr.eu.net 136323 A 193.124.22.65 additional: polyn.kiae.su 3600 A 144.206.160.32 additional: relay1.relcom.ru 60516 A 193.125.152.57 generate#
В данном случае мы попросили все записи для имени Polyn.kiae.su.
Сразу следует оговориться, что получить зону целиком при помощи команд отладки пакета djbdns нельзя. Для этого следует пользоваться компонентой сервера этого пакета - tinydns-get. Возможность ввести в качестве аргумента тип axfr не должна вводить в заблуждение:
generate# ./dnsqr axfr polyn.kiae.su 252 polyn.kiae.su: temporary failure generate#
Если необходимо протестировать какой либо сервер на предмет обслуживания нерекурсивных запросов, то в этом случае следует воспользоваться программой dnsq:
generate# ./dnsq mx quest.polyn.kiae.su 144.206.160.32 15 quest.polyn.kiae.su: 251 bytes, 1+2+3+5 records, response, authoritative, weird ra, noerror query: 15 quest.polyn.kiae.su answer: quest.polyn.kiae.su 3600 MX 10 quest.polyn.kiae.su answer: quest.polyn.kiae.su 3600 MX 20 relay1.relcom.ru authority: polyn.kiae.su 3600 NS polyn.net.kiae.su authority: polyn.kiae.su 3600 NS ns.spb.su authority: polyn.kiae.su 3600 NS ns.ussr.eu.net additional: quest.polyn.kiae.su 3600 A 144.206.192.2 additional: relay1.relcom.ru 78029 A 193.125.152.57 additional: polyn.net.kiae.su 66089 A 144.206.160.32 additional: ns.spb.su 66066 A 193.124.83.69 additional: ns.ussr.eu.net 131676 A 193.124.22.65 generate#
В данном примере мы запрашиваем авторитативный сервер зоны polyn.kiae.su на предмет наличия MX записей для хоста quest.polyn.kiae.su. В качестве ответа получаем эти записи плюс информацию о серверах ответственных за зону polyn.kiae.su. Стоит отметить, что тип запроса (тип записи) был преобразован в цифровой код, который соответствует этому типу RR (число "15" перед именем хоста в первой строке отчета).
Теперь посмотрим, как работает программа трассировки поиска информации в системе DNS. Вообще говоря, это монстр, который может порождать тысячи запросов. Он позволяет проверить все пути в дереве DNS, которые приводят к получению ответа. При этом можно выявить медленные серверы, некорректное делегирование, неработающие серверы и другие проблемы.
Например, в отчете для зоны ru. есть такие строчки:
1 ns.ussr.eu.net 194.85.119.1 ALERT: lame server; refers to .
Саму программу запускают следующим образом:
generate# ./dnstrace soa ru ns.ripn.net . cache NS . . cache A 194.85.119.1 6 ru 194.85.119.1 ru cache NS ns.ripn.net ru cache NS ns1.relcom.ru ru cache NS ns.uu.net ru cache NS sunic.sunet.se ru cache NS ns2.nic.fr ru cache NS ns2.ripn.net ns.ripn.net cache A 194.85.119.1 ns1.relcom.ru cache A 193.125.152.3 ns2.ripn.net cache A 194.226.96.30 ru 86400 SOA ns.ripn.net hostmaster.ripn.net 400 5371 7200 900 2592000 345600 …
Мы обрезали отчет из-за его непомерной длины. Вместо ns.ripn.net можно указать любой сервер, с которого начинается обращение к системе доменных имен. На самом деле начинать, конечно, нужно с корневых серверов, но все работает и в случае нашего примера.
Собственно, на этом примере можно завершить рассмотрение творения DJB. Следует заметить, что довольно часто djbdns рассматривают в качестве альтернативы BIND. Вызвано это, скорее всего, не тем, что сервер Бернштейна действительно хорош по своим потребительским и прочим качествам, а тем, что реальной альтернативы BIND пока действительно не видно.
Рассмотрим еще несколько программ тестирования зон системы DNS. Первой из них будет dnswalk. Программа написана на Perl (первоначально она представляла фильтр программы dig) с использованием модуля Net::DNS. Основное назначение программы поиск ошибок в описании зон и поиск некорректного делегирования.
Если вызвать программу без дополнительных ключей командной строки, то получим:
generate# dnswalk bard.kiae.ru. Checking bard.kiae.ru. Getting zone transfer of bard.kiae.ru. from iris.polyn.kiae.su...done. SOA=ns.polyn.kiae.ru contact=paul.polyn.kiae.su BAD: bard.kiae.ru NS polyn.kiae.ru: unknown host WARN: bard.kiae.ru MX iris.polyn.kiae.ru: unknown host WARN: bard.kiae.ru A 144.206.192.32: no PTR record WARN: mail.bard.kiae.ru A 144.206.192.32: no PTR record WARN: www.bard.kiae.ru A 144.206.192.32: no PTR record 0 failures, 4 warnings, 1 errors.
generate#
Из отчета видно, что сначала найден авторитативный сервер зоны (iris.polyn.kiae.su), далее выявлено некорректное делегирование (unknown host для NS записи) и список нефатальных ошибок, который сводится к отсутствию записей в "обратной зоне".
У dnswalk существует несколько флагов командной строки, которые можно использовать при получении отчетов. Мы не будем останавливаться на всех. Посмотрим только некоторые:
generate# dnswalk -l webstatistics.ru.
В данном случае мы ищем некорректное делегирование. Если есть подозрение на то, что оно существует, то dnswalk выдаст строку типа:
FAIL: Cannot get SOA record for webstatistics.ru from ns4.nic.ru (lame?): no name servers
Можно попросить dnswalk рекурсивно просмотреть и все поддомены:
generate# dnswalk -r webstatistics.ru. Checking webstatistics.ru. Getting zone transfer of webstatistics.ru. from ns.webstatistics.ru...done. SOA=ns.webstatistics.ru contact=paul.webstatistics.ru BAD: webstatistics.ru NS ns.webstatistics.ru: CNAME (to webstatistics.ru) BAD: webstatistics.ru NS ns4.nic.ru: unknown host WARN: user1.webstatistics.ru CNAME user.webstatistics.ru: CNAME (to host.webstatistics.ru) BAD: zone.webstatistics.ru NS ns.webstatistics.ru: CNAME (to webstatistics.ru) Checking zone.webstatistics.ru BAD: SOA record not found for zone.webstatistics.ru BAD: zone.webstatistics.ru has NO authoritative nameservers! BAD: All zone transfer attempts of zone.webstatistics.ru failed! 0 failures, 6 warnings, 6 errors. generate#
В данном случае в зоне делегируется поддомен zone.webstatistics.ru, для которого не удается найти авторитативных серверов.
Кроме того, в отчете сообщается и о других ошибках описания зоны, например, о синонимах в NS записях.
К сожалению, в dnswalk нельзя указать сервер, который мы собираемся тестировать. Сервер берется из resolv.conf. В конце концов, нужный нам сервер можно указать первым в resolv.conf и тогда dnswalk будет работать с ним.
До сих пор мы работали с программами, которые позволяют анализировать описание зон путем использования DNS серверов.
Однако, проверить правильность описания зоны можно просто, прочитав файл зоны. Проверив его на типичные ошибки, можно сгенерировать соответствующий отчет. Для этой цели написана программа nslint:
generate# nslint nslint: "cname" referenced by other "cname" or "mx": ns.webstatistics.ru. nslint: name referenced without other records: generate.polyn.kiae.su. nslint: missing "ptr": paul.webstatistics.ru. -> 144.206.192.50 nslint: "cname" referenced by other "cname" or "mx": user.webstatistics.ru. nslint: missing "ptr": host.webstatistics.ru. -> 144.206.192.63 nslint: missing "a": localhost.polyn.kiae.su. -> 127.0.0.1 nslint: missing "ptr": webstatistics.ru. -> 144.206.192.60 nslint: name referenced without other records: ns4.nic.ru. nslint: missing "ptr": www.webstatistics.ru. -> 144.206.160.32 nslint: missing "ptr": www.webstatistics.ru. -> 144.206.192.60 nslint: missing "ptr": www.webstatistics.ru. -> 144.206.192.61 nslint: missing "ptr": www.webstatistics.ru. -> 144.206.192.62 nslint: 144.206.192.60 in use by www.webstatistics.ru. and webstatistics.ru. generate#
В данном случае вообще не нужно задавать никаких аргументов, хотя они у nslint есть. Программа читает файлы конфигурации BIND (распознает как новый так и старый форматы), находит описания зон на локальном сервере и проверяет их на наличие ошибок. Понятно, что nslint имеет смысл запускать только на том компьютере, где установлен BIND.
Кроме тестирования работы системы DNS и серверов доменных имен существуют еще утилиты генерации описания зон и проверки файлов конфигурации. В для этой цели можно, например, использовать пакет dnsutl от Peter Miller.
Существует еще одна возможность тестирования работы сервера доменных имен - анализ его log-файла. Для выполнения этих действий написан скрипт, который назывался lamers.sh. В последнее время его переписали и он работает с DOC, т.е.
кроме анализа log-файла еще и тестирует сервер путем вызова программ из DOC.
Ниже приведен основной кусочек скрипта, который, собственно, и ищет сообщения о неправильном делегировании:
#-------------------------------------------------------------------------- # See if there are any lamers #-------------------------------------------------------------------------- grep "Lame" $LOGFILE | tr A-Z a-z | grep -v "*" | awk '{ if (length($9) == 2) next print substr($9, 2, length($9) - 2), substr($11, 2, length($11) - 2) }' | sort -u | awk '{ printf("%s %s\n", $1, $2) }' > $LAMERS
В BIND версии 9 можно настроить сервер таким образом, чтобы он сам собирал сообщения о некорректном делегировании:
channel "lammers_log" { file "lammers.log"; severity info; }; category "lame-servers" { "lammers_log"; };
Этот фрагмент нужно вставить в опцию logging в файле настройки named.conf.
Тогда при обнаружении некорректного делегирования в этом файле будут появляться строчки типа:
lame server resolving 'www.ietf.net' (in 'ietf.NET'?): 218.145.29.146#53
Мы уже упоминали DOC (domain obscenity control) в контексте lamers. На самом деле этот продукт можно использовать совершенно самостоятельно. К написанию первоначальной версии DOC приложил руку Paul Moskapetris (отец DNS). Одно время DOC входило в состав дистрибутива BIND. Сейчас программу можно найти среди дополнительного программного обеспечения (ports) для большинства Unix-клонов.
Краткий отчет программы DOC будет выглядеть следующим образом:
generate# /usr/local/bin/doc alpha.ru. Doc-2.1.4: doc alpha.ru. Doc-2.1.4: Starting test of alpha.ru. parent is ru. Doc-2.1.4: Test date - Thu Nov 14 16:40:13 MSK 2002 ;; res_nsend to server ns2.nic.fr. 192.93.0.4: Operation timed out DIGERR (UNKNOWN): dig @ns2.nic.fr. for SOA of parent (ru.) failed Summary: ERRORS found for alpha.ru. (count: 2) Done testing alpha.ru. Thu Nov 14 16:40:24 MSK 2002
generate#
На самом деле интересно, что же за ошибки существуют в описании зоны.
Для этого следует обратиться к файлу log.alpha.ru., который генерирует программа. Информацию об ошибках можно получить и на стандартный вывод:
generate# /usr/local/bin/doc -e alpha.ru. Doc-2.1.4: doc -e alpha.ru. Doc-2.1.4: Starting test of alpha.ru. parent is ru. Doc-2.1.4: Test date - Thu Nov 14 16:45:33 MSK 2002 ERROR: NS list from alpha.ru. authoritative servers does not === match NS list from parent (ru.) servers ERROR: ns.alpha.ru. claims to be authoritative, but does not appear in NS list from authoritative servers Summary: ERRORS found for alpha.ru. (count: 2) Done testing alpha.ru. Thu Nov 14 16:45:35 MSK 2002
generate#
Файловый отчет гораздо подробнее. Он кроме всего прочего содержит сами записи, в которых была обнаружена ошибка.
DOC использует dig Для получения содержания зоны, поэтому просто так без dig он работать не будет.
Есть еще одна любопытная программа - nsping. Ее не следует путать с "тезкой", которая применяется для Lotus Notes и Domino. Nsping тестирует серверы методом "случайного тыка". Основная идея заключается в том, чтобы обойти кэширование записей описания ресурсов и таким образом получить правдоподобную информацию о работоспособности сервера.
Отчет nsping выглядит следующим образом:
generate# /usr/local/sbin/nsping -z kiae.ru localhost NSPING localhost (127.0.0.1): Domain = "kiae.ru", Type = "IN A" + [ 0 ] 159 bytes from 127.0.0.1: 0.471 ms [ 0.000 san-avg ] + [ 1 ] 158 bytes from 127.0.0.1: 0.433 ms [ 0.452 san-avg ] + [ 2 ] 159 bytes from 127.0.0.1: 0.492 ms [ 0.465 san-avg ] + [ 3 ] 159 bytes from 127.0.0.1: 0.474 ms [ 0.467 san-avg ] + [ 4 ] 159 bytes from 127.0.0.1: 0.443 ms [ 0.463 san-avg ] + [ 5 ] 158 bytes from 127.0.0.1: 0.426 ms [ 0.456 san-avg ] ^C Total Sent: [ 6 ] Total Received: [ 6 ] Missed: [ 0 ] Lagged [ 0 ] Ave/Max/Min: 0.456 / 0.492 / 0.426 generate#
В качестве первого параметра мы заказали зону, из которой хотели бы получать адреса, а в качестве второго параметра сервер (в данном случае localhost), который обрабатывал бы наши рекурсивные запросы.
Можно попросить оценить время получения и другого типа записей, например MX-записей:
generate# /usr/local/sbin/nsping -z rambler -T mx localhost NSPING localhost (127.0.0.1): Domain = "rambler", Type = "IN MX" + [ 0 ] 455 bytes from 127.0.0.1: 0.712 ms [ 0.000 san-avg ] + [ 1 ] 454 bytes from 127.0.0.1: 0.625 ms [ 0.668 san-avg ] + [ 2 ] 455 bytes from 127.0.0.1: 0.770 ms [ 0.702 san-avg ] + [ 3 ] 455 bytes from 127.0.0.1: 0.841 ms [ 0.737 san-avg ] + [ 4 ] 455 bytes from 127.0.0.1: 0.761 ms [ 0.742 san-avg ] + [ 5 ] 454 bytes from 127.0.0.1: 0.626 ms [ 0.723 san-avg ] ^C Total Sent: [ 6 ] Total Received: [ 6 ] Missed: [ 0 ] Lagged [ 0 ] Ave/Max/Min: 0.723 / 0.841 / 0.625 generate#
Любопытно сравнить время получения информации с различных серверов. Например, с локального и с авторитативного сервера домена Microsoft:
generate# /usr/local/sbin/nsping -c 1 -z microsoft.com. -T ns dns1.dc.msft.net. NSPING dns1.dc.msft.net. (207.68.128.151): Domain = "microsoft.com.", Type = "IN NS" - [ 0 ] 113 bytes from 207.68.128.151: 126.201 ms [ 0.000 san-avg ]
Total Sent: [ 2 ] Total Received: [ 1 ] Missed: [ 1 ] Lagged [ 0 ] Ave/Max/Min: 126.201 / 126.201 / 126.201 generate# /usr/local/sbin/nsping -c 1 -z microsoft.com. -T ns localhost NSPING localhost (127.0.0.1): Domain = "microsoft.com.", Type = "IN NS" + [ 0 ] 266 bytes from 127.0.0.1: 0.610 ms [ 0.000 san-avg ]
Total Sent: [ 2 ] Total Received: [ 1 ] Missed: [ 1 ] Lagged [ 0 ] Ave/Max/Min: 0.610 / 0.610 / 0.610 generate#
Из отчета ясно, что с авторитативного сервера оно на два порядка больше.
Если появилось желание попробовать nsping, то программку можно установить из набора готового программного обеспечения ports. Однако нужно быть готовым к тому, что этот пустячок потянет за собой установку компилятора ADA и много другой сопутствующей мелочевки, которая, по большому счету, никому на вашей машине не нужна.
В заключении оговоримся, что перечисленные и описанные нами программы - это далеко не полный перечень средств, которые существуют в природе для решения проблем, которые возникают при работе системы доменных имен.В реальной жизни далеко не все администраторы даже догадываются о существовании этого программного обеспечения, обходясь стандартным набором из дистрибутива BIND.
Динамического обновления описания зоны (Dynamic Updates или DNS UPDATE)
. Изначально описание зоны было, да и до сих пор в большинстве случаев остается, статическим. Это значит, что есть на Primary master файл описания зоны, в который администратор вручную или при помощи скриптов изменения содержания файла вносит изменения. Для того чтобы они стали актуальными, т.е. их увидели resolver-ы, необходима перезагрузка сервера. Идея динамического обновления описания зоны состоит в том, чтобы, во-первых, вносить изменения в описание зоны без перезагрузки сервера, а, во-вторых, делать это удаленно, т.е. администратору не нужно получать доступ к файлам описания зон ни для ручного редактирования, ни для скриптов. Тем самым класс клиентов в модели "клиент-сервер" в рамках DNS обмена расширяется на группу клиентов администрирования.
Когда актуально динамическое обновление зоны? Чаще всего необходимость динамического обновления связывают с работой по протоколу DHCP (Dynamic Host Configuration Protocol, RFC-1541). DHCP Позволяет динамически назначать компьютерам IP-адреса, маски, IP-адреса шлюзов, доменные имена и т.п., т.е. передавать хостам данные без которых невозможна работа в сетях TCP/IP.
DHCP существенно облегчает работу сетевого администратора, которому не нужно настраивать каждый компьютер, подключенный к сети, вручную. Динамическое именование влечет за собой постоянное изменение информации в описании зоны.
Динамическое обновление позволяет авторизованным клиентам посылать запросы на динамическое обновление описания зоны серверам, которые являются авторитативными для соответствующей зоны. Обратите внимание, что запросы могут направляться как master-серверам, т.к. slave-серверам.
Если сервер не является Primary master-сервером зоны, то он отправляет (ретранслирует) запрос на обновление своему master-серверу. Таким образом запрос на обнавление достигает Primary master-сервера зоны.
Как только Primary master-сервер совершит обновление описания зоны, он может по механизму DNS NOTIFY оповестить об этом slave-серверы, которые, в свою очередь, обновят свои описания зоны.
В рамках динамического обновления можно удалять и добавлять отдельные записи описания ресурсов в описания зоны, наборы записей описания ресурсов, выделенных по определенному признаку, скажем записи определенного типа, или записи связанные с определенным доменом. Возможно редактирование описания зоны по условию.
Для того, чтобы успешно выполнялись обмены со slave-серверами, при каждом изменении зоны изменяется и номер ее версии. Это позволяет slave-серверам поддерживать свои описания зоны в актуальном, согласованном с Primary master-сервером состоянии.
Динамическое обновление описания зоны порождает другую проблему - многократную передачу по сети описания зоны между master-серверами и slave-серверами. Если описание зоны большое, то и объем трафика, который передается по сети, будет немаленький.
При этом стоит отметить, что собственно сами изменения описания зоны не столь и велики, т.к., например, при DHCP при каждом изменении добавляется/удаляется одна-две записи описания ресурсов. Каждое такое изменение будет порождать обмен описанием зоны.
При традиционном обмене описанием зоны (AXFR) Между master-сервером и slave-сервером передается полное описание зоны.
Для того, чтобы не передавать всю зону, а передавать только изменения предназначен механизм
DNS
- это совокупность понятий, архитектуры, спецификаций и протоколов, реализующих эти спецификации. Это изложение и детализация идеи иерархического именования всех хостов в Интернет и правил установки соответствия между именем и IP-адресом хоста.
Expire
определяет интервал времени, после которого slave должен прекратить обслуживание запросов к зоне, если он не смог в течение этого времени верифицировать описание зоны, используя информацию с master сервера.
Обычно это интервал делают достаточно большим. Если сделать маленький интервал, то какой смысл в slave сервере? Он просто скоропостижно скончается после отключения master сервера.
В течение всего этого времени, т.е. до достижения конца интервала expire, slave сервер будет пытаться установить контакт c master сервером и обслуживать запросы к зоне.
Правда все эти соображения хороши для случая, когда просто отключится или ломается машина, на которой стоит master сервер. Если же отключится вся сеть, которая описана в зоне, а для большинства организаций так оно и есть, то slave сервер становится подобным космическому аппарату "Пионер", который путешествует во Вселенной, давно потеряв всякую связь с Землей.
Тем не менее, существует несколько причин, по которым его наличие полезно. Во-первых, различные приложения по разному реагируют на ситуацию отсутствия соединения или невозможности найти соответствие доменному имени. Во-вторых, если зона доступна, а хост в ней недоступен, то приложение гораздо быстрее прерывает свою работу. В-третьих, время положительно кэширования гораздо больше времени негативного кэширования, а это ускоряет процесс прекращения попыток соединения с неработающим хостом, т.к. не нужно находить его адрес. В-четвертых, в отключенной сети все хосты не доступны, а они принадлежат, как правило, к одному домену, а адрес его slave сервера доменных имен закэширован и сам сервер доступен, что ускоряет, по крайней мере не замедляет, проверку доступности хостов домена (подробнее см. RFC 2182).
Последний атрибут из поля данных записи SOA - minimum. В разных версиях BIND он определяет совершенно разные понятия. До 8.2 этот параметр определял время кэширования по умолчанию ответов на запросы к DNS. Еще раньше он определял время кэширования по умолчанию только положительных ответов, т.е.
тех, которые устанавливали наличие соответствия между IP-адресом и доменным именем. Теперь этот параметр обозначает время негативного кэширования (negative caching), т.е. время кэширования ответов, которые утверждают, что установить соответствие между доменным именем и IP-адресом нельзя.
Последнее обстоятельство заставило ввести в описание зоны новую директиву управления $TTL, которая и определяет время кэширования по умолчанию положительных ответов от системы DNS.
Существуют рекомендации по установки параметров записи SOA. Например, RFC 1537 рекомендует следующие установки для серверов, отличных от тех, которые поддерживают домены верхнего уровня:
28800 ; Refresh 8 hours 7200 ; Retry 2 hours 604800; Expire 7 days 86400 ; Minimum TTL 1 day
На самом деле установить в современных серверах minimum больше 3 часов нельзя (в том смысле, что написать-то можно, работать параметр не будет). Это максимальное время негативного кэширования, согласно документации на BIND 9.
Для TLD в том же документе рекомендованы:
86400 ; Refresh 24 hours 7200 ; Retry 2 hours 2592000; Expire 30 days 345600 ; Minimum TTL 4 days
Конечно, это не догма. В этом легко убедиться, посмотрев соответствующие параметры в SOA для зоны ru программой nslookup:
> set type=soa > ru. Server: ns.ripn.net Address: 194.85.119.1
ru origin = ns.ripn.net mail addr = hostmaster.ripn.net serial = 4005176 refresh = 7200 (2H) retry = 900 (15M) expire = 2592000 (4w2d) minimum ttl = 345600 (4D) ru nameserver = ns.ripn.net ru nameserver = ns1.relcom.ru ru nameserver = ns.uu.net ru nameserver = sunic.sunet.se ru nameserver = ns2.nic.fr ru nameserver = ns2.ripn.net ns.ripn.net internet address = 194.85.119.1 ns1.relcom.ru internet address = 193.125.152.3 ns2.ripn.net internet address = 194.226.96.30 >
Для зоны com информация несколько иная:
> com. Server: [192.5.6.30] Address: 192.5.6.30
com origin = A.GTLD-SERVERS.NET mail addr = NSTLD.VERISIGN-GRS.com serial = 2002092401 refresh = 1800 (30M) retry = 900 (15M) expire = 604800 (1W) minimum ttl = 86400 (1D)
Для полноты картины укажем и на более поздние рекомендации. Так, например, для небольших стабильных зон в 1999 году (ripe-203) рекомендовались следующие параметры SOA:
example.com. 3600 SOA dns.example.com. hostmaster.example.com. ( 1999022301 ; serial YYYYMMDDnn 86400 ; refresh ( 24 hours) 7200 ; retry ( 2 hours) 3600000 ; expire (1000 hours) 172800 ) ; minimum ( 2 days)
При этом автор (Peter Koch) подробно описывает причины, по которым установлены эти значения.
Например, для refresh интервал в сутки выставлен потому, что существует динамическое обновление зоны и оповещение slave серверов о произошедших изменениях. По этой причине нет смысла ставить маленький интервал обновления базы данных slave сервера. Если оповещение отключено или используются старые версии BIND, то, видимо, нужно спуститься с небес на землю и поставить интервал поменьше, скажем часов 8 (RFC 1537) или еще меньше.
Для атрибута expire обычно указывают одну или две недели. Однако считается, что за это время серьезные проблемы с primary master не решить, следовательно, период должен быть большим, что-то порядка месяца-двух.
Peter Koch написал в 2001 году более свежие рекомендации по установке значений в записи SOA (RIPE DNS GUIDE). По факту (значениям, перечисленным в примере записи SOA) они ничем не отличаются от приведенного выше примера.
В новых рекомендациях существует важное замечание относительно значения параметра minimum. Интерпретация его значения зависит от того, поддерживает ли конкретная реализация BIND негативное кэширование. Если поддерживает и mininum - это время негативного кэширования, то следует указывать значение 3600, если не поддерживает, то - 172800.
Обратите внимание на то, что все атрибуты записи SOA определяют порядок взаимодействия master сервера и slave серверов. Исключение составляет только атрибут minimum. В данном случае речь идет о кэшировании адресов не только сервером, но системой "умного" resolver.
Дело в том, что в качестве resolver на локальной вычислительной установке выступают функции из стандартной библиотеки, которые направляют рекурсивные запросы к локальному серверу доменных имен и сами не осуществляют кэширования соответствий между именами и IP-адресами.
В этом случае кэширование осуществляется локальным сервером доменных имен.
Если на машине запускается свой кэширующий сервер, который не описывает никакой зоны, а используется только для обслуживания запросов к сервису доменных имен, то именно он и является той частью resolver, которая кэширует соответствия.
Таким образом, когда речь идет об атрибуте minimum, то чаще всего его описывают в контексте программы named, которая может использоваться не только как master или slave сервер, но и как кэширующий сервер. В этом случае поле ttl записи описания ресурса, директива управления $TTL и атрибут minimum задают время хранения записи описания ресурса в кэше.
Приведем еще один пример записи типа SOA:
example.com. 3600 SOA dns.example.com. hostmaster.example.com. ( 1999022301 ; serial YYYYMMDDnn 1d ; refresh 2h ; retry 30d ; expire 1H ) ; minimum
В данном примере имя зоны указано непосредственно - example.com. Время ttl для самой записи указано равным часу, хотя записи SOA и не хранятся в кэше. Primary master зоны указан как dns.example.com, и его имя отличается от имени домена. Адрес электронной почты администратора соответствует всем существующим рекомендациям - hostmaster@example.com. Серийный номер версии описания зоны занимает 10 позиций и соответствует шаблону даты. Время обновления базы данных описания зоны на slave серверах установлено равным 1 суткам, время повторения попыток обновления установлено равным 2 часам, период "умирания" зоны равен одному месяцу, а время негативного кэширования установлен равным одному часу.
Обратите внимание, что интервалы заданы не в секундах, а в более понятной нотации (минутах (m), часах (h), днях (d), неделях (w)).
И еще одно замечание в завершении этого материала. Мы много говорили о параметрах негативного кэширования, но вопроса о необходимости этого самого кэширования не обсудили. Мы сделаем это отдельно, т.к. кэширование отрицательных ответов вызвано не только теоретическими соображениями, но и суровой прозой жизни.
Всего существует три типа файлов,
Всего существует три типа файлов, которые использует named 4-ой версии. К ним относятся:
файл начальной загрузки буфера (cache) конфигурации named (named.boot) файлы описания "прямых" и "обратных" зон
В литературе по named принято начинать с файла описания базы данных named - named.boot. Еще раз напомним, что более свежие версии named настраиваются при помощи файла конфигурации, имеющего другое имя и другой формат директив.
Файл named.boot в 4-ой версии используется программой named для своей настройки и первичной загрузки базы данных домена. Это первое, что ищет named при своем запуске.
Терминология при работе с named из BIND 4 отличается от той, которая принята в настоящее время. Master сервер зоны в данном случае будет называться primary сервером зоны, slave сервер зоны будет называться secondary сервером зоны.
В файле named.boot для описания настроек named используются следующие команды:
directory - адрес директории в файловой системе компьютера, на котором запускается named. primary - определяет зону, для которой данный сервер является primary server, и имя файла базы данных этой зоны. Файл размещается в директории, которая указана в команде directory. secondary - определяет зону, для которой данный сервер является secondary server, а также определяет адреса других серверов для этой зоны, обычно primary server, и имя файла где будет вестись копия базы данных этой зоны. Файл размещается в директории, указанной в команде directory. cache - определяет имя кэш-файла. Обычно в кэш-файле описаны адреса и имена корневых серверов, которые данный сервер будет использовать для получения адресов удаленных серверов доменных имен. forwarders - данная команда определяет адреса серверов доменных имен куда следует отправлять рекурсивные запросы. Естественно, что на этих серверах для хоста, на котором установлен named, должна быть разрешена обработка рекурсивных запросов с этого хоста. slave - заставляет сервер отправлять все запросы на серверы, которые определены командой forwarders.
Прежде, чем рассматривать примеры файлов named. boot для различных типов серверов, хотелось бы обратить внимание читателя на две последние команды.
Фактически, именно они и определяют какая из процедур разрешения запроса (рекурсивная или нерекурсивная будут применяться на вашем сервере в каждом конкретном случае). Если в файле named.boot есть команда slave, то определена рекурсивная процедура разрешения запроса, т.к. в этом случае named будет отсылать все запросы на серверы указанные в команде forwarders и от них получать адреса или имена удаленных хостов. В этом случае серверы из forwarders будут опрашивать корневые серверы и удаленные серверы доменов. Если эти серверы также содержат команду slave, то поиск адреса или имени будут осуществлять серверы, которые определены в их файлах named.boot как forwarders.
Когда такая конфигурация сервера полезна? Обычно так настраивают кэширующие серверы подразделений внутри одной организации. В качестве сервера, на который осуществляется пересылка всех запросов, используется центральный сервер организации. При этом с корневыми серверами общается только этот сервер, серверы зон самостоятельно на корневые серверы запросов не отправляют. Если число машин за пределами данного домена, с которыми общаются пользователи этого домена, не очень велико, и все они компактно расположены в других доменах, то центральный сервер домена быстро заполнит свой кэш необходимой для разрешения запросов информацией. При этом такой кэш будет только один, а работать он будет с той же скоростью, как если бы каждый из серверов зон создавал его у себя.
Приведем теперь пример файла named.boot, в котором проиллюстрируем использование указанных выше команд:
;An Example of the named.boot ; directory namedb primary 0.0.127.in-addr.arpa localhost primary vega.ru vega primary 43.226.194.in-addr.arpa vega.rev secondary polyn.kiae.su 144.206.130.137 144.206.192.34 polyn secondary 160.206.144.in-addr.arpa 144.206.130.137 144.206.192.34 polyn.rev cache . named.root
Пример 1. Содержание файла named.boot.
Обычно, файл named.boot размещается в директории /etc. От этой директории затем идет отсчет места компонентов базы данных named. В нашем случае эту базу данных можно представить в виде графа (рис.1), у которого в качестве корня выступает директория /etc. В /etc существует поддиректория namedb, в которой располагаются все остальные файлы.
Рис.1. Структура размещения файлов базы данных named из примера 1.
Сопоставив рисунок 1 и описание из примера 1, легко догадаться, что последняя колонка в каждой из команд описания настроек named заканчивается именем соответствующего файла или директории. Рассмотрим формат каждой команды более подробно.
Команда directory определяет директорию namedb как директорию размещения файлов базы данных named (файлов описания зон). Вообще говоря, вовсе не так уж обязательно размещать все файлы в одной директории. Можно создать несколько директорий, например, по количеству зон. Например, для каждой зоны можно использовать отдельную поддиректорию в корневой директории named. Если придерживаться этой логики размещения файлов, то
;An Example of the named.boot ; directory namedb primary 0.0.127.in-addr.arpa localhost primary vega.ru v/vega primary 43.226.194.in-addr.arpa v/vega.rev secondary polyn.kiae.su 144.206.130.137 144.206.192.34 p/polyn secondary 160.206.144.in-addr.arpa 144.206.130.137 144.206.192.34 p/polyn.rev cache . named.root
Пример 2. Содержание файла named.boot при размещении файлов описания зон для primary и secondary серворов по разным директориям.
В примере 2 в директории namedb определены две поддиректории v и p. В директории v размещаются файлы зон vega.ru и 43.226.194.in-addr.arpa, для которых данный сервер является primary. В свою очередь в директории p размещаются файлы описания зон polyn.kiae.su и 160.206.144.in-addr.arpa, для которых данный сервер является secondary сервером. Если представить структуру файлов в виде графа, то получится граф с рисунка 2.
Рис.2. Дерево файлов описания базы данных named из примера 2.
Вообще говоря, корнем описания файлов базы данных named может быть директория отличная от /etc. если программу named запустить с флагом "-f", то в качестве параметра можно указать полный путь к файлу named.boot или к другому файлу, который используется вместо named.boot:
/usr/paul>named -f /usr/paul/named.par
В этом случае в качестве корневой директории для файлов описания базы данных named будет использоваться директория /usr/paul, а в качестве файла named.boot файл named.par из этой директории.
Кроме того, в команде directory, как это определено в наших примерах, используется, так называемый, неполный путь к директории, где расположены файлы базы данных named. Однако можно указывать и полный путь, что дает возможность расположить эти файлы где угодно в файловой системе сервера. Например, если файлы расположены в директории /usr/local/etc/namedb, то в файле named.boot следует указать следующую команду directory:
directory /usr/local/etc/namedb
Команда primary используется для указания зоны, которую данный сервер обслуживает в качестве master сервера, и указания имени файла, где она (зона) описана. Формат команды primary можно описать следующим образом:
primary
В примерах 2 и 3 используется три команды primary. Первая описывает "обратную" зону 0.0.127.in-addr.arpa, вторая команда описывает "прямую" зону vega.ru и третья команда описывает "обратную" зону 43.226.194.in-addr.arpa. Наличие двух "обратных" зон вызвано тем, что прямая зона определена на двух сетях - 194.226.43.0 и 127.0.0.0.
Сеть 127.0.0.0 - это особая сеть, поэтому первая команда должна быть на любом сервере доменных имен, т.к. она служит для определения обратной зоны 0.0.127.in-addr.arpa, которая закреплена за любой машиной, на которой установлен стек протоколов TCP/IP.
Особое назначение этого домена следует из особого значение IP-адресов, которые закреплены за ним. Они обозначают "петлю", т.е. при отправке пакетов по адресу, например, 127.0.0.1 пакеты не выходят за пределы одного компьютера и таким образом не попадают в реальную сеть.
В некоторых реализациях стека определенное значение имеют и другие адреса сети 127, например, 127.0.0.2 и 127.0.0.3 в HP-UX.
Очень часто в примерах описания файла named.boot можно встретить повторение имени зоны в названии файла:
primary 0.0.127.in-addr.arpa 0.0.127.in-addr.arpa
Это повторение означает только то, что в директории файлов описания базы данных named должен быть файл с таким именем. Для тех, кто привык к тому, что в файловой системе MS-DOS были разрешены только трехбуквенные расширения имени файла, подобное имя выглядит довольно странно, но у энтузиастов Unix и пользователей современных версий Windows это не должно вызывать затруднений. Использование имен зон в качестве имен файлов - это общепринятая практика. Так гораздо проще ориентироваться среди файлов описания базы данных named.
Часто вместо 0.0.127.in-addr.arpa указывают 127.in-addr.arpa. Сеть 127 - это сеть класса А (Для тех, кто привык к нотациям CIDR рекомендуем прочитать RFC-790 и 791). Для этой сети что 127, что 127.0, что 127.0.0 - суть одно и тоже. Так как при указании обратной зоны числа в IP-адресах указываются в обратной последовательности, то 0.0.127.in-addr.arpa и 127.in-addr.arpa также означают одно и тоже. Вообще говоря, обработка этой обратной зоны согласно RFC-1035 производится особым способом.
Среди специалистов по named нет единства мнений о стиле определения прямых и обратных зон, в том числе, и о зоны 0.0.127.in-addr.arpa. Некоторые предлагали ввести "прямую" зону, которая бы соответствовала "обратной" зоне 0.0.127.in-addr.arpa. Связано это с доменным именем, которое ставится в соответствие адресу 127.0.0.1.
Команда secondary используется для описания зон, где данный сервер выполняет функции slave сервера, и имеет следующий формат:
secondary
В наших примерах описано две зоны, для которых данный сервер является secondary сервером - polyn.kiae.su и 160.206.144.in-addr.arpa. В примерах для каждой из этих зон указано по два IP-адреса серверов, поддерживающих зону.
Вообще говоря, достаточно указывать адрес только primary сервера зоны. С точки зрения актуальности состояния базы данных зоны, для которой создается secondary сервер, указание одного только primary наиболее правильное решение, т.к. только primary сервер содержит наиболее актуальную базу данных зоны. Однако в ряде случаев, имеет смысл указать несколько серверов, primary и secondary, например. В случае указания нескольких серверов, база копируется с того, который указан первым, если он доступен. Если сервер не доступен, то опрашивается следующий в списке, до первого доступного сервера.
Файл, который указан последним аргументом в команде secondary, создается named при запуске и постоянно обновляется в соответствии с описанием взаимодействия master и slave серверов. Редактировать вручную этот файл не имеет смысла, т.к. это калька с master сервера, и через постоянные промежутки времени этот файл обновляется программой named. Таким образом, если кто-либо и внесет в него изменения, то named, создавая новую копию базы данных зоны, затрет эти изменения.
В отличии от master сервера slave сервер не способен поддерживать разрешение запросов сколь угодно долго. Как только истечет время актуальности данных в его базе данных, он пытается создать новую копию базы с базы данных master сервера. Если это не удается, то сервер через некоторое время перестанет обслуживать зону (см. описание записи описания ресурсов SOA).
Главное назначение slave сервера - это повышение надежности службы доменных имен. Описание зоны named копирует с серверов, указанных в качестве аргумента команды secondary. Там указаны не только primary master сервер, но и другие серверы, которые относительно primary master являются slave серверами.
Зона копируется с того сервера, который доступен. Это значит, что на данном сервере может оказаться копия с другого slave сервера.
Команда cache служит для определения файла с начальными данными для запуска named. Для того, чтобы начать отвечать на запросы named должна знать адреса других серверов доменных имен, к которым можно было бы обратиться с запросами на разрешение IP-адреса по имени или имени по IP-адресу.
Формат команды выглядит следующим образом:
cache
Обычно обсуждение cache сводится к обсуждению того, какие корневые серверы, должны быть указаны в файле cache и как поддерживать актуальность этого файла. Прежде, чем обратиться к формату команды, заметим, что не только корневые серверы могут указываться в файле cache, но также и другие серверы, которые часто используются для разрешения запросов в вашем домене.
Согласно Крегу Ричмонду (Craig Richmond) различные версии named по разному используют файл, указанный в команде named. Одни программы загрузив данные из этого файла больше его не используют, другие наоборот постоянно вносят в него изменения.
В случае стабильного файла администратор системы должен сам заботится о его актуальности. Для этого он должен регулярно проверять соответствие между его файлом и файлом, который поддерживается в ns.internic.net. Получить копию файла можно либо, с ftp-сервера ftp.rs.internic.net, либо по команде:
/usr/paul>dig @ns.internic.net.ns > root.cache
Том Ягер (Tom Yager) рекомендует другой источник получения cache - ftp://nic.ddn.mil/netinfo/root-servers.txt.
На самом деле cache - это описание корневой зоны доменных имен, которую, собственно, и обслуживают root серверы. А куда еще прикажите обращаться при запуске named?
Если в файл cache необходимо внести другую информацию, то это делается аналогично описанию корневых серверов. В новых версиях named (8-9ая) нет кэш-файла, но есть описание корневой зоны. По этой причине не стоит вносить в него изменения, которые не сделали на primary master корневой зоны.
Команда forwarders определяет IP-адреса серверов, на которые следует отправлять рекурсивные запросы. Команда имеет следующий вид:
forwarders
Случай организации рекурсивной процедуры разрешения имени с использованием этой команды был рассмотрен ранее. Однако этим случаем не ограничивается круг использования команды forwarders. При регистрации домена некоторое время внешний относительно этого домена мир не подозревает о существовании домена.
Должно пройти некоторое время, прежде чем будет закончена процедура регистрации домена и обновления баз данных вышестоящего в иерархии DNS домена на всех серверах как master, так и slave. Однако внутри домена все работает нормально, т.к. локальный сервер запускается до официальной регистрации и способен обслуживать машины домена. Однако, он может и не знать информации о всех доменах Internet. Для этого нужно самому запрашивать root-серверы. Но можно ведь воспользоваться и чужим кэшем. По этой причине всегда полезно указать команду forwarders на сервер домена вышестоящего относительно данного домена. Как правило, на нем разрешено обслуживать рекурсивные запросы хостов из поддоменов.
Обычно указывают не один, а несколько IP-адресов серверов, которые в состоянии ответить на запросы клиентов. Например, для сервера зоны vega.ru, который запущен, но еще не зарегистрирован, можно указать два сервера:
forwarders 144.206.136.1 144.206.130.137
Команда slave указывается тогда, когда сервер общается с внешним миром чрез серверы, указанные в команде forwarders. Параметров у данной команды нет. Файл named.boot для того сервера, если он еще и primary сервер для зон vega.ru и 43.226.194.in-addr.arpa будет выглядеть следующим образом:
;An Example of the named.boot ; directory namedb primary 0.0.127.in-addr.arpa localhost primary vega.ru vega primary 43.226.194.in-addr.arpa vega.rev cache . named.root forwarders 144.206.130.137 144.206.136.1 slave
Пример 3. Подчиненный сервер, работающий по рекурсивной процедуре разрешения запросов от resolver.
Фактически, команда slave позволяет организовать, в некотором смысле, "интеллектуальный" resolver.
Файлы описания зоны. Директивы управления.
В этом материале мы разберем особенности применения директив управления при описании зон в master файлах. Кроме стандартных директив $ORIGIN и $INCLUDE будут также рассмотрены $TTL и $GENERATE.
Наиболее используемая директива управления -
Формат записи описания ресурса
.
Записи типа RR в master файле (файле описания зоны) имеют формат описанный в RFC-1033 и уточненный в RFC-1035. Приведем его по RFC-1033 как более простому, а отличия от RFC-1035 обсудим дополнительно ниже:
[] []
Как и прежде "[ ]" - это опционный, т.е. необязательный, параметр, а "< >" обозначают сущность. Отличие этой формы определения от RFC-1035 заключается в том, что тоже может быть опционным параметром, т.е. его можно опускать в RR, а также и можно менять местами. Более того, если первые три параметра опущены, то действует значение параметра, определенное в предыдущих записях файла, например:
kyky.ru. IN NS kyky.ru. A 192.168.0.1 MX 10 192.168.0.1
В данном случае значение поля name (kyky.ru), значение поля ttl, которое в данном контексте не определено, значение поля class (IN, что означает Интернет) наследуются из записи определения сервера доменных имен(NS RR) адресной записью (A RR) и записью определения почтового посредника (MX RR).
Определим поля записи описания ресурса:
Поле
ГГГГММДДВВ
Итого получается 10 символов. В старых руководствах по BIND указывают максимальное значение длины этого поля 8 символов.
Важность серийного номера определяется тем, что когда вторичный(secondary) сервер обращается к первичному(primary) серверу для обновления информации о зоне, то он сравнивает серийный номер из своего кэша с серийным номером из базы данных первичного сервера. Если серийный номер из primary сервер больше, то secondary сервер обращается к primary и копирует описание всей зоны целиком, если нет, то он не вносит изменений в свою базу данных. Таким образом, когда производятся изменения в базе данных primary сервера, то значение атрибута serial в поле данных записи SOA для зоны, описание которой было изменено, должно быть увеличено. Неизменение номера - это типичная ошибка, которую совершают администраторы зон. По этой причине лучше пользоваться средствами автоматического обновления зоны.
А что делать при достижении максимально возможного порядкового номера? Вопрос гипотетический, т.к., если даже использовать в качестве серийного номера приведенную выше нотацию, то мы достигнем предельных значений серийного номера только в 4294 году (цитируем по man named для FreeBSD 4.2 -RELEASE), но все же?
На самом деле все просто: нужно начинать сначала. До BIND 9 можно было просто указать 0-ую версию описания зоны в любой момент, и потом снова начать ее увеличивать.
Любителям математики следует прочитать раздел "Цикл порядкового номера" в книге Пола Альбитца и Крикета Ли "DNS и BIND" на странице 194 (Альбитц П., Ли К.. DNS и BIND. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 696 с.). Там подробно объяснена концепция непрерывного арифметического пространства и способ перехода к младшим целым номерам от старших за два шага изменения серийного номера описания зоны. Кроме того, арифметике серийного номера посвящен отдельный документ - RFC 1982.
Атрибут
Host
определяет доменное имя хоста (например, компьютера, на котором установлена и производит обслуживание программа, реализующая один из сетевых сервисов, например, web-сервер).
Чаще всего, это имя указывается относительно имени текущей зоны, поэтому на конце имени не проставляется символ ".", т.е. задается неполное имя хоста.
Если же надо описать машину из другой зоны, то следует указать ее полное доменное имя (fully qualified name) и не забыть в конце этого имени символ ".". Например, "quest.polyn.kiae.su.", указанное в поле host ссылается на машину с именем quest.polyn.kiae.su. Можно также применить директиву управления $ORIGIN и переопределить имя текущей зоны.
Поле ttl обычно оставляют пустым. Поле ttl определяет время хранения адресной записи в кэше сервера доменных имен или кэше "умного" resolver-а. Если значение поле ttl не задано, то оно берется из директивы управления $TTL для BIND 8 и 9 версий, или из поля minimum записи SOA для старых версий BIND.
Приемлемым временем кэширования можно принять значение "3 часа", что обычно записывается в виде числа секунд - 10800:
My-host 10800 IN A 192.168.0.1
В поле address указывают IP-адрес машины. В этом адресе точку на конце ставить не надо.
При делегировании доменов и в самом начале описания зоны (поле primary master сервера записи SOA и NS) возникает проблема описания серверов, поддерживающих описания зоны и описания поддоменов. В этих записях указываются доменные имена серверов, но не указывается их IP-адресов.
DNS - это только информационный сервис, который сам опирается на TCP/IP. При маршрутизации пакетов по сети нужно знать IP-адреса, а их-то как раз и не хватает для обращения к серверам поддоменов и к серверу зоны, если он расположен в той же зоне.
Для решения этой проблемы используются "приклеенные" (буквально "glue") записи типа "А". При этом нет разницы что будет указано в описании зоны раньше - использование доменного имени или определение соответствия этого имени IP-адресу.
Теперь приведем пример записи типа A и использование "приклеенных" адресных записей. Во-первых, рассмотрим простую запись типа A:
$ORIGIN vega.ru. vega-gw IN A 194.226.43.1
В данном случае в зоне vega.ru определяется доменное имя для машины с IP-адресом 194.226.43.1. Для каждой машины зоны будет указана такая же запись. Таким образом мы назначаем каждому хосту в локальной сети доменное имя.
Теперь рассмотрим использование "приклеенной" записи для сервера зоны, который указан в записи SOA:
$ORIGIN vega.ru. @ IN SOA vega-gw.vega.ru paul.kiae.su ( 101 ; serial number 86400 ; refresh within a day 3600 ; retry every hour 3888000 ; expire after 45 days 10800 ) ; negative caching IN NS vega-gw.vega.ru. IN A 194.226.43.1 ; vega-gw IN A 194.226.43.1
В данном примере при назначении сервера зоны в записи NS IP-адрес этого сервера еще не определен, но это и не суть важно, главное, чтобы он был определен далее в одной из адресных записей описания зоны.
Кроме этого, для обслуживания почтовых адресов типа:
/usr/paul>mail paul@vega.ru
"приклеена" еще одна адресная запись, которая назначает текущему домену IP-арес 194.226.43.1.
Формально эта запись определяет адрес для запросов по неполному имени. В данном случае для всех запросов, которые используют имя зоны, определен адрес шлюза, на котором установлено обслуживание всех сервисов, например, http://vega.ru/ или gopher://vega.ru/. Обычно такой подход используют в маленьких сетях для упрощения работы с сервисами этих сетей.
На самом деле, адресная запись для доменного имени зоны и доменного имени сервера vega-gw.vega.ru "приклеенными" не являются. "Приклеенными" называют только те записи, которые необходимы для поиска IP-адреса, который в контексте запроса невозможно найти путем обращения к авторитативному серверу соответствующей зоны. В нашем же случае мы уже добрались до описания нашей зоны, а в ней есть адресная запись соответствия имени зоны некоторому IP-адресу. Скорее всего, это произошло благодаря настоящей "приклеенной" записи адреса нашего сервера в родительской зоне.
Вообще говоря, правильнее проблему "приклеенных" записей рассматривать с точки зрения выполнения запросов к DNS. В откликах на запросы эти записи помещаются в специальную дополнительную секцию, откуда и извлекаются resolver-ом. Собственно, по этой причине их и называют "приклеенными", т.е. дополнительными.
Примером настоящей "приклеенной" записи может служить делегирование зон внутри домена. Если сервер поддомена будет находиться в самом этом поддомене, то кроме как через приклеенную адресную запись мы не сможем узнать его IP-адрес. Он является авторитативным за зону и в описании зоны, которая хранится у него, задано соответствие его собственного доменного имени и IP-адреса. Но как до него добраться? При помощи "приклеенных записей" в описании родительской зоны!
Пусть мы создаем два поддомена zone1 и zone2, серверы которых также расположены в этих же поддоменах:
$ORIGIN vega.ru. @ IN SOA vega-gw.vega.ru paul.kiae.su ( 101 ; serial number 86400 ; refresh within a day 3600 ; retry every hour 3888000 ; expire after 45 days 10800 ) ; negative caching IN NS vega-gw.vega.ru. IN A 194.226.43.1 ; vega-gw IN A 194.226.43.1 ......... ; Glue address records. zone1-gw.zone1 IN A 194.226.43.2 zone2-gw.zone2 IN A 194.226.43.3 ; Subdomain delegation. zone1 IN NS zone1-gw.zone1.vega.ru. zone2 IN NS zone2-gw.zone2.vega.ru.
Сначала мы определили IP-адреса хостов в рамках текущего домена, а потом определили их в качестве серверов соответствующих зон нашего домена. Записи, определяющие IP-адреса хостов и будут "приклеенными".
Всегда существует соблазн задать лишние "приклеенные" записи. Например, адресную запись для сервера доменных имен провайдера, на котором поддерживается slave для вашей зоны. Такая практика встречалась раньше довольно часто, встречается она и сейчас. На самом деле, такая запись лишняя. Соответствие имени адресу можно получить непосредственно из зоны провайдера.
Размещать ненужные "приклеенные" записи в своей зоне не стоит по целому ряду причин.
Во-первых, IP- адрес сервера провайдера может измениться, а Вы этого не узнаете, соответственно, возникнет коллизия некорректного делегирования зоны, и отвечать на запросы будет только один ваш сервер. Во-вторых, современные версии BIND все равно проигнорируют ваши некорректно "приклеенные" записи J.
Рассмотрим пример описания зоны с некорректно "приклеенной" записью:
$ORIGIN ru. webstatistics 3600 IN SOA ns.webstatistics.ru. hostmaster.webstatistics.ru. ( 1 3600 600 86400 3600 ) 3600 IN NS ns.webstatistics.ru. 3600 IN NS ns4.nic.ru. IN A 144.206.192.60 $ORIGIN webstatistics.ru. ns 3600 IN A 144.206.192.60 $ORIGIN nic.ru. ns4 IN A 194.226.96.8 ; некорекктно "приклеенная" запись
Запись сообщения named при запуске сервера об игнорировании некорректных приклеенных записей будет выглядеть следующим образом:
Oct 7 12:15:34 generate named[136]: dns_master_load: webstatistics.ru:10: ignoring out-of-zone data (ns4.nic.ru)
Некорректное "приклеивание" адресных записей приведет к увеличению трафика DNS на вашем сегменте сети и нагрузке на ваш сервер доменных имен. С точки зрения пользователей это тоже может вызвать определенные неудобства. Обычно сервер провайдера располагается на канале с большей пропускной способностью, т.е. время отклика у пользователя из-за некорректно приклеенной адресной записи может увеличиться.
Если у вас возникнут проблемы с доступностью сети, то ваша зона вообще может лишиться авторитативных серверов, что тоже является нежелательным, т.к. приводит к увеличению трафика в системе доменных имен, а также к негативному кэшированию отказов.
Рассмотрим теперь случай, когда одному и тому же доменному имени присваивается несколько IP-адресов. Ситуация эта не такая уж и редкая. Пример, который лежит на поверхности - это корневые серверы доменных имен, т.е. серверы, которые обслуживают корневую зону.
Мы знаем, что их 13 и, что за каждым именем корневого сервера скрывается много машинный комплекс. У каждого из этих хостов свой собственный IP-адрес, следовательно, доменное имя соответствует нескольким IP-адресам.
Другой пример - хост выполняет функции шлюза. У него одно доменное имя, но каждый из интерфейсов имеет свой собственный IP-адрес, следовательно, одному имени будет соответствовать несколько IP-адресов.
Еще один пример - балансировка нагрузки на Web-серверах. Балансировка нагрузки через DNS - это, видимо, не самое оптимальное решение, но в качестве первого приближения решения проблемы оно проходит.
Предыдущее замечание относится главным образом к тому, что называют Round Robin алгоритмом. Существуют более оптимальные решения, построенные на основе DNS, например, RFC 1794, но они не реализованы в виде стандартных опций BIND.
Смысл Round Robin алгоритма в DNS легко понять, опираясь на содержание сообщения отклика сервера доменных имен. Дело в том, что в ответ на стандартный запрос сервер отправляет список записей описания ресурсов, которые отвечают требованиям запроса.
Когда запрашиваются записи адресного типа, то клиенту (resolver или локальный сервер) возвращается список записей в том порядке, как они встретились в описании зоны. Именно в этом порядке прикладная программа и начинает проверять адреса с целью установки соединения.
Понятно, что в этом случае первый адрес будет использоваться наиболее часто. Если реализовать циклическую перестановку адресов в отклике сервера доменных имен, то тогда все IP-адреса будут задействованы относительно равномерно.
Рассмотрим пример:
$ORIGIN ru. Webstatistics 3600 IN SOA ns.webstatistics.ru. hostmaster.webstatistics.ru. ( 1 3600 600 86400 3600 ) 3600 IN NS ns.webstatistics.ru. 3600 IN NS ns4.nic.ru. IN A 144.206.192.60 $ORIGIN webstatistics.ru. ns 3600 IN A 144.206.192.60 ; www 3 IN A 144.206.192.60 3 IN A 144.206.192.61 3 IN A 144.206.192.62
Мы задали три адреса для одного и того же доменного имени. Теперь посмотрим при помощи nslookup, как будет сервер реагировать на наши запросы:
> www.webstatistics.ru Server: [144.206.192.60] Address: 144.206.192.60
Name: www.webstatistics.ru Addresses: 144.206.192.62, 144.206.192.60, 144.206.192.61
> www.webstatistics.ru Server: [144.206.192.60] Address: 144.206.192.60
Name: www.webstatistics.ru Addresses: 144.206.192.61, 144.206.192.62, 144.206.192.60
> www.webstatistics.ru Server: [144.206.192.60] Address: 144.206.192.60
Name: www.webstatistics.ru Addresses: 144.206.192.60, 144.206.192.61, 144.206.192.62
>
и далее по кругу. Вот это и есть Round Robin алгоритм.
Когда время обработки запросов одинаковое, то нагрузка на все адреса будет тоже примерно одинаковая, но если запросы осуществляются к разнородным ресурсам, то равномерной балансировки нагрузки на серверы, которым назначены соответствующие IP-адреса, добиться не удастся.
Впервые "тасовать" адреса (Shuffle Addresses) предложил Брайн Бичер, но его идея требовала введения дополнительных записей описания ресурсов, поэтому прошло решение Маршала Розе, которое, собственно, и называется Round Robin код.
Round Robin код разрабатывался для кластеров, на которых функционировали серверы доменных имен. Именно это обстоятельство позволяло не заботится о реальной нагрузке на хост, т.к. ее (нагрузку) учитывала кластерная архитектура вычислительной установки и соответствующая операционная среда.
Следует заметить, что современные resolver-ы позволяют игнорировать при соответствующей настройке упорядочивание записей в отклике сервера и опираться на топологию сети, т.е. обращаться к наиболее предпочтительному с их точки зрения IP-адресу. Таким resolver-ом является, например, resolver операционной системы Windows2000.
В последних версиях сервера доменных имен компании Microsoft (для Windows 2000 и NT) Round Robin по умолчанию не используется, а используются предпочтения, основанные на так называемой эвристике LocalNetPriority. Это значит, что в локальной сети всегда предпочтение отдается локальным адресам.
Естественно, что при применении Round Robin алгоритма время кэширования адресных записей следует уменьшить. Встречаются рекомендации, которые советуют установить TTL в 300 секунд. В примере задан интервал в 3 секунды (фактически кэширование отменено) только для того, чтобы кэширование не влияло на сообщения nslookup.
Вообще говоря, 8- я версия BIND позволяет настраивать "тасование" записей. Записи в откликах могут переставляться не циклически, а случайным образом. Для этого в файл конфигурации named в директиву options следует включить нечто похожее на следующий блок:
rrset-order { class IN type A name "www.kyky.ru" order random; order cyclic; }
В данном случае адресные записи для хоста www.kyky.ru будут "тасоваться" случайным образом, а все остальные записи - циклически. При этом Round Robin будет применяться не только к адресным записям.
К сожалению, в 9-ой версии BIND заказать тип "тасования" нельзя. В этой версии применяется только random-cycling, т.е. начальная точка циклической перестановки выбирается случайным образом. Более того, он применяется по умолчанию, как только встретиться подходящий набор записей (RRset).
Если в вашей конфигурации встретиться опция rrset-order, а сервер эту опцию не поддерживает, то в логах появится запись вида:
Oct 7 12:44:47 generate named[136]: /etc/named.conf:7: option 'rrset-order' is not implemented
Мы написали "к сожалению", но на самом деле существуют веские причины, по которым случайный выбор порядка адресов тоже не является удачным решением. Обычно это происходит из-за короткого списка IP-адресов, что не позволяет реально балансировать нагрузку.
Перестановка адресов в купе с негативным кэшированием также не является приятной особенностью системы DNS. Если вдруг из списка IP-адресов один из адресов окажется не доступен, то закэшированный отклик будет постоянно мешать установке соединения с сервисом, у которого остальные IP-адреса функционируют нормально.
В BIND существуют и другие возможности сортировки отклика, состоящего из нескольких записей описания ресурсов - это директивы sortlist и topology. Первая принудительно задает порядок адресов в отклике, например для запросов из локальной сети на первое место в отклике будут ставиться адреса из локальной сети, если они существуют.
Такая ситуация может возникнуть, например, при обращении к удаленному ресурсу, чье зеркало находится в локальном сегменте сети.
Приведем пример использования директивы sortlist. Сначала посмотрим на файл конфигурации named.conf:
options { directory "/etc/namedb"; pid-file "named.pid"; allow-query {any;}; allow-recursion { "kiae"; }; sortlist { { 144.206.192/24; { 144.206.192/24; 144.206.160/24;};}; { 144.206.160/24; { 144.206.160/24; 144.206.192/24;};}; }; };
В нем мы добавили в директиву options опцию sortlist. Она задает порядок отображения записей описания ресурсов при доступе из подсетей 144.206.192/24 и 144.206.160/24. Суть его (порядка) заключается в том, чтобы в списке отклика первыми указывались записи, указывающие на ресурсы соответствующей подсети.
При этом сам файл описания зоны будет содержать следующую информацию:
$ORIGIN ru. Webstatistics 3600 IN SOA ns.webstatistics.ru. hostmaster.webstatistics.ru. ( 1 3600 600 86400 3600 ) 3600 IN NS ns.webstatistics.ru. 3600 IN NS ns4.nic.ru. IN A 144.206.192.60 $ORIGIN webstatistics.ru. ns 3600 IN A 144.206.192.60 $ORIGIN nic.ru. ns4 IN A 194.226.96.8 $ORIGIN webstatistics.ru. www 3 IN A 144.206.192.60 3 IN A 144.206.192.61 3 IN A 144.206.192.62 3 IN A 144.206.160.32
Для адреса www.webstatistics.ru определены адресные записи из двух перечисленных в файле конфигурации подсетей. Посмотрим с хостов, расположенных в каждой из этих подсетей, что увидит программа nslookup.
Для хоста из 144.206.160.32 получим:
> www.webstatistics.ru Server: [144.206.192.60] Address: 144.206.192.60
Name: www.webstatistics.ru Addresses: 144.206.160.32, 144.206.192.60, 144.206.192.61, 144.206.192.62
>
А для хоста 144.206.192.2 получим:
> www.webstatistics.ru Server: [144.206.192.60] Address: 144.206.192.60
Name: www.webstatistics.ru Addresses: 144.206.192.60, 144.206.192.61, 144.206.192.62, 144.206.160.32
> www.webstatistics.ru Server: [144.206.192.60] Address: 144.206.192.60
Name: www.webstatistics.ru Addresses: 144.206.192.60, 144.206.192.61, 144.206.192.62, 144.206.160.32
>
Из последнего примера видно, что алгоритм "тасования" записей при использовании sortlist не активируется.
Вторая директива (topology) имеет ограниченное применение, т.к. в BIND 9 не поддерживается.
Рассмотрим теперь обратную ситуацию, когда одному IP-адресу можно назначить несколько доменных имен. В принципе, в рамках DNS существует запись описания ресурса CNAME, которая позволяет поддерживать доменные имена синонимы для главного (канонического) имени, за которым и закреплен IP-адрес хоста.
Однако, использование CNAME, во-первых, порождает цикл обращений к серверу для получения сначала канонического имени, а потом уже IP-адреса, а, во-вторых, на использование CNAME наложен целый ряд ограничений.
Ни один документ не запрещает нам использовать несколько адресных записей, которые ставят разные доменные имена в соответствии с одним и тем же IP-адресом. При этом имена могут принадлежать совершенно разным доменам.
Примером такого сорта могут служить одна из разновидностей виртуальных web-серверов (software web server). В этом случае IP-адрес хоста остается постоянным, а вот доменное имя, по которому на сервер попадают запросы, может изменяться, при чем сам web-сервер, зная содержание URL, имеет возможность откликаться на запросы разными страницами.
$INCLUDE
используется для того, чтобы в файл описания зоны можно было включить содержание другого файла. Так рекомендуется поступать при описании больших зон, разбивая их на небольшие фрагменты. При этом имя включаемого файла должно быть описано либо полностью от корня файловой системы, либо оно будет привязано к директории, указанной в файле named.boot или named.conf.
$INCLUDE my_zone.dsc
В этом случае используется файл /etc/namedb/my_zone.dsc, т.к. обычно директивы directory (BIND 4) или directory (BIND 8-9) определяют именно эту директорию для хранения файлов базы данных named.
$INCLUDE /etc/my_zone
В данном случае указан полный путь, и именно он будет использоваться при доступе к файлу.
Рассмотрим теперь еще две директивы управления, которые сравнительно недавно появились в файлах описания зон: $TTL и $GENERATE.
Директива
Инкрементальной передачи описания зоны (IXFR, RFC-1995)
. В рамках обмена передаются номера версий описаний зон и записи, которые нужно добавить или удалить. Принцип простой - сначала идут номер старой версии и список записей, которые нужно удалить, а потом номер более свежей версии и записи, которые нужно добавить.
Мы более подробно остановимся на этом вопросе в разделе, посвященном настройкам BIND и файлам описания зон.
В контексте рассмотрения обмена описаниями зоны между master-серверами и slave-серверами следует упомянуть о
Изменениях описания зоны (DNS NOTIFY)
. Идея достаточно проста и проистекает из проблемы распространения изменений, внесенных в описание зоны при ее редактировании. Дело в том, что slave-серверы при традиционной работе опрашивают master-сервер (в данном контексте primary master) на предмет изменения в описании зоны через определенные промежутки времени, которые задаются в описании зоны. Возможна ситуация, когда изменения были внесены в зону сразу после ее копирования slave-сервером. В этом случае новая информация появится на всех slave-серверах только при следующем обновлении зоны.
Ситуация усугубляется еще и тем, что остальные не авторитативные серверы держат записи соответствия между именем домена и IP_адресом в своем кэше в течение времени TTL (Time To Live), которое также определяется в описании зоны. Обычно задержка между внесением изменений и стабильной работой с новым описанием зоны в российском сегменте Интернет составляет примерно 2 часа. Вот пример отчета программы nslookup для rambler.ru:
>set type=soa >rambler.ru Server: ns.rambler.ru Address: 217.73.192.49
rambler.ru origin = ns.rambler.ru mail addr = bindmaster.rambler-co.ru serial = 2002090601 refresh = 10800 (3H) retry = 1800 (30M) expire = 10800 (3H) minimum ttl = 3600 (1H) rambler.ru nameserver = ns.rambler.ru rambler.ru nameserver = ns.park.rambler.ru ns.rambler.ru internet address = 217.73.192.49 ns.park.rambler.ru internet address = 217.73.193.23 >
Позиция refresh говорит о том, что время опроса в стандартном режиме составляет 3 часа. А вот из другого отчета для зоны relarn.ru это время и того больше - сутки:
> relarn.ru Server: ns.relarn.ru Address: 194.226.65.3
relarn.ru origin = ns.relarn.ru mail addr = noc-dns.relarn.ru serial = 650127367 refresh = 86400 (1D) retry = 3600 (1H) expire = 604800 (1W) minimum ttl = 86400 (1D) relarn.ru nameserver = ns.relarn.ru relarn.ru nameserver = ns.ussr.EU.net relarn.ru nameserver = ns.spb.su relarn.ru nameserver = ns2.ripn.net ns.relarn.ru internet address = 194.226.65.3 ns.ussr.EU.net internet address = 193.124.22.65 ns.spb.su internet address = 193.124.83.69 ns2.ripn.net internet address = 194.226.96.30 >
О том, что обозначают другие позиции этих отчетов, мы поговорим тогда, когда будем обсуждать описание зоны (запись SOA), а пока только заметим, что внесение изменений в описание зоны не приводит к появлению возможности мгновенного их использования.
Таким образом, механизм уведомления об изменениях в описании зоны необходим для ускорения введения в жизнь сделанных изменений.
Принцип работы DNS NOTIFY следующий:
В базу данных primary master вносятся изменения (руками с последующей перезагрузкой сервера или динамически по протоколу динамического обновления зоны). Primary master оповещает свои slave о том, что произошли изменения, сообщая им номер версии описания зоны. Slave запрашивает с primary master описание зоны и, если номера версии описаний зоны не совпадают (на primary master номер больше), то инициирует процесс обновления описания зоны. Завершив обновление описания зоны, slave посылает оповещения на известные ему авторитативные сервера зоны.
На рисунке пояснется работы приведенной выше схемы:
Рис.2. Схема работы DNS NOTIFY
На рисунке 2 primary master является для обоих slave-серверов master-сервером c точки зрения процедуры передачи зоны. Но в принципе, для одного из серверов он может быть и не определен в качестве master-сервера. В этом случае появляется дополнительное звено в дереве зависимости обмена данными зоны. В этом случае изменения будут передаваться от сервера к серверу так, как это показано на рисунке 3:
Рис.3. Схема работы DNS NOTIFY при двухзвенном оповещении об изменении описания зоны.
Теперь поясним механизм
Как работает система доменных имен
В данном материале речь пойдет о схеме взаимодействия между различными компонентами системы доменных имен при выполнении ею своей основной функции, а именно обслуживания запросов на установление соответствия между доменными именами и IP-адресами.
Согласно руководящим материалам (RFC-1034, RFC-1035) система доменных имен состоит из трех основных частей:
Всего множества доменных имен (domain name space) Серверов доменных имен (domain name servers) Клиенты DNS (Resolver-ы)
Множество доменных имен было подробно рассмотрено в материале "Доменная адресация. Немного истории и принципы построения", поэтому сосредоточимся на двух оставшихся компонентах серверах и resolver-ах.
Сервис системы доменных имен строится по схеме "клиент-сервер". В качестве клиентской части выступает прикладной процесс, который запрашивает информацию о соответствии имени адресу (или наоборот адреса имени). Это программное обеспечение и называют resolver. В качестве сервера выступает прикладная программа-сервер.
Чаще всего, Resolver не является какой-либо программой или системной компонентой. Это набор процедур из библиотеки прикладного программного обеспечения (например, из библиотеки libc), которые позволяют программе, отредактированной с ними, выполнять запросы к системе доменных имен и получать ответы на них. Эти процедуры обращаются к серверу доменных имен и, таким образом, обслуживает запросы прикладных программ пользователя.
Ряд производителей операционных систем, например, Sun или SGI, предлагали решения, в которых resolver являлся отдельным процессом, и прикладные программы через него реализовывали взаимодействие с DNS.
Другой пример реализации resolver-а - это браузеры Nescape некоторых версий, где для ускорения процесса получения ответов на запросы к DNS запускался отдельный процесс resolver-a.
Самостоятельный resolver может быть собран и в BIND версии 9. Это так называемый lightweight resolver. Он состоит из resolver-демона и библиотеки взаимодействия с этим демоном, процедуры которой линкуются с прикладным ПО.
Данный resolver позволяет не только посылать запросы к серверу доменных имен, но кэшировать соответствия между доменным именем и IP-адресом.
В качестве серверов доменных имен чаще всего используются различные версии BIND (Berkeley Internet Name Domain). Если сервер реализован на платформе Windows, то тогда используют решение от Microsoft, хотя для этой платформы также существуют версии BIND.
Общую схему взаимодействия различных компонентов системы доменных имен можно изобразить так, как это представлено на следующем рисунке:
Рис1. Рекурсивный запрос resolver и нерекурсивная (итеративная) процедура на разрешение доменного имени сервером доменных имен.
Данная схема разрешения имени (установки соответствия между именем и IP-адресом) называют нерекурсивной (итеративной). Чем она отличается от рекурсивной мы обсудим позже.
Поясним приведенную схему нерекурсивной процедуры разрешения запроса:
Прикладная программа через resolver запрашивает IP-адрес по доменному имени у местного сервера (запрос resolver рекурсивный, т.е. resolver просит server найти ему адрес). Местный сервер сообщает прикладной программе IP-адрес запрошенного имени, выполняя при этом нерекурсивный опрос серверов доменных имен. При этом:
если адрес находится в зоне его (местного сервера) ответственности, сразу сообщает его resolver-у, если адрес находится в зоне ответственности другого сервера доменных имен, то обращается к корневому серверу системы доменных имен за адресом TLD-сервера (top-level domain server), обращается к TLD-серверу за адресом, получает от него адрес удаленного сервера, обращается к удаленному серверу за адресом, получает от удаленного сервера адрес,
В данном случае мы рассмотрели вложенность доменного имени второго порядка., т.е. хост имел имя похожее на quest.kuku.ru или даже kuku.ru.
Последнее важно понять, т.к. корпоративные почтовые адреса типа user@kuku.ru как раз и требуют от прикладного программного обеспечения обращения за IP-адресом хоста kuku.ru. TLD-сервер домена ru не обладает информацией о том, какому IP-адресу данное имя соответствует, но при этом он знает какой сервер отвечает за домен kuku.ru.
Если вложенность доменного имени будет большей, скажем третьего уровня (host.department.corp.ru), и этот уровень будет поддерживаться другим сервером доменных имен, отличным от того, который поддерживает второй уровень вложенности, то тогда нашему локальному серверу удаленный сервер доменных имен передаст не адрес хоста, а адрес нового сервера доменных имен, в зоне ответственности которого находится запрашиваемое имя.
Как видно из приведенной схемы, получение информации из системы доменных имен - это многоходовой процесс, который не реализуется мгновенно. В следующем примере показано как на практике ощущается работа DNS.
При входе в режиме удаленного терминала на компьютер polyn.net.kiae.su по команде:
/usr/paul>telnet polyn.net.kiae.su
Мы получаем в ответ:
/usr/paul>telnet polyn.net.kiae.su trying 144.206.130.137 ... login: .....
Строчка, в которой указан IP-адрес компьютера polyn.net.kiae.su, показывает, что к этому времени доменное имя было успешно разрешено сервером доменных имен и прикладная программа, в данном случае telnet получила на свой запрос IP-адрес. Таким образом, после ввода команды с консоли, и до появления IP-адреса на экране монитора прикладная программа осуществила запрос к серверу доменных имен и получила ответ на него.
Довольно часто можно столкнуться с ситуацией, когда после ввода команды довольно долго приходиться ждать ответа удаленной машины, но зато после первого ответа удаленный компьютер начинает реагировать на команды с такой же скоростью, как и ваш собственный персональный компьютер. В этом случае, скорее всего, в первоначальной задержке виноват сервис доменных имен.
Другой пример того же сорта - это программа traceroute. Здесь задержка на запросы к серверу доменных имен проявляется в том, что время ответов со шлюзов, на которых "умирают" ICMP пакеты, указанное в отчете, маленькое, а задержки с отображением каждой строчки отчета довольно большие.
Любопытно, что в системе Windows 3.1 некоторые программы трассировки, показывали сначала IP-адрес шлюза, а только потом, после разрешения "обратного" запроса, заменяли его на доменное имя шлюза.
Если сервис доменных имен работал быстро, то эта подмена была практически незаметна, но если сервис работал медленно, то промежутки бывали довольно значительными.
Проверить на сколько "чувствительны" запросы traceroute c точки зрения отображения трассы к использованию сервера доменных имен можно задав поиск трассы с использованием сервера:
>traceroute www.w3.org
и без использования сервера:
>traceroute -n www.w3.org
Если в примере с telnet и ftp мы рассматривали, только "прямые" (forward) запросы к серверу доменных имен, то в примере с traceroute мы впервые упомянули "обратные"(reverse) запросы. В "прямом" запросе прикладная программа запрашивает у сервера доменных имен IP-адрес, сообщая ему доменное имя. При "обратном" запросе прикладная программа запрашивает доменное имя, сообщая серверу доменных имен IP-адрес.
Следует заметить, что скорость разрешения "прямых" и "обратных" запросов в общем случае будет разная. Все зависит от того, где описаны "прямые"(forward) и "обратные"(reverse) зоны в базах данных серверов доменных имен, обслуживающих соответствующие домены (прямой и обратный).
Более подробно этого вопроса мы коснемся при обсуждении файлов конфигурации программы named.
Однако вернемся к обсуждению схемы работы системы доменных имен. Собственно нерекурсивным рассмотренный выше запрос является только с точки зрения сервера. С точки зрения resolver-а процедура разрешения запроса является рекурсивной, так как resolver перепоручил локальному серверу доменных имен заниматься поиском необходимой информации. Согласно RFC-1035, resolver и сам может опрашивать удаленные серверы доменных имен и получать от них ответы на свои запросы.
В этом случае resolver обращается к локальному серверу доменных имен, если не получает от него адреса, то опрашивает сервер корневого домена, получает от него адрес удаленного сервера TLD, опрашивает этот сервер, получает адрес удаленного сервера, опрашивает удаленный сервер и получает IP-адрес, если он посылал, так называемый "прямой" запрос.
Рис.2. Нерекурсивный запрос resolver-а.
Как видно из этой схемы, resolver сам нашел нужный IP-адрес. Однако общая практика такова, что resolver не порождает нерекурсивных запросов, а переадресовывает их локальному серверу доменных имен.
Локальный сервер и resolver не все запросы выполняют по указанной процедуре. Дело в том, что существует кэш, который используется для хранения в нем полученной от удаленного сервера информации.
Самые умные resolver-ы, такие, например, как resolver Windows 2000 Server и BIND 9 умеют поддерживать кэш, в котором сохранияют не только удачно установленные соответствия имени и адреса (positive response), но и так называемые "негативные" отклики (negative response results) на запросы. Кроме того, эти resolver-ы упорядочивают отклики об адресах серверов в соответствии с принятыми в них (resolver-ах) алгоритмами выставления предпочтений, которые базируются на времени отклика сервера.
Рис.3. Схема разрешения запросов с кэшированием ответов.
Если пользователь обращается в течение короткого времени к одному и тому же ресурсу сети, то запрос на удаленный сервер не отправляется, а информация ищется в кэше.
Вообще говоря, прядок обработки запросов можно описать следующим образом:
поиск ответа в локальном кэше поиск ответа на локальном сервере поиск информации в сети.
При этом кэш может быть как у resolver-а, так и у сервера.
Прежде, чем мы двинемся дальше в нашем понимании работы системы доменных имен введем еще одно понятие - зону.
Между доменом и зоной существует разница, которую бывает трудно найти, но всегда нужно иметь в виду. Домен - это все множество машин, которые относятся к одному и тому же доменному имени. Например, все машины, которые в своем имени имеют постфикс kiae.su относятся к домену kiae.su. Зона - это "зона ответственности" конкретного сервера доменных имен, т.е. понятие домена шире, чем понятие зоны. Если домен разбивается на поддомены, то у каждого из них может появиться свой сервер. При этом зоной ответственности сервера более высокого уровня будет только та часть описания домена, которая не делегирована другим серверам.
Разбиение домена на поддомены и организация сервера для каждого из них называется делегирование прав управления зоной соответствующему серверу доменных имен, или просто делегированием зоны.
При настройке сервера, в его файлах конфигурации можно непосредственно прописать адреса серверов зон. В этом случае обращения к корневому серверу не производятся, т.к. местный сервер сам знает адреса удаленных серверов зон, которым он же и делегировал права управления этими зонами.
Существует еще и другой вариант работы сервера, когда он не запрашивает корневой сервер на предмет адреса удаленного сервера доменных имен. Это происходит тогда, когда незадолго до этого сервер уже разрешал задачу получения IP-адреса из того же домена. Если требуется получить IP-адрес удаленного сервера доменных имен, отвечающего за домен, то он будет просто извлечен из буфера сервера (кеша), т.к. в течение определенного времени, заданного в конфигурации описания зоны (Time To Live - TTL), этот адрес будет храниться в кэше сервера. А попал он туда как результат выполнения предыдущего запроса.
Кроме нерекурсивной процедуры разрешения имен возможна еще и рекурсивная процедура разрешения имен. Ее отличие от описанной выше нерекурсивной процедуры состоит в том, что удаленный сервер сам опрашивает свои серверы зон, а не сообщает их адреса местному серверу доменных имен. Рассмотрим этот случай более подробно.
На рисунке 4 продемонстрирована нерекурсивная процедура разрешения IP-адреса по доменном имени. Основная нагрузка в этом случае ложится на местный сервер доменных имен, который осуществляет опрос всех остальных серверов. Для того, чтобы сократить число таких обменов, если позволяет объем оперативной памяти, можно разрешить буферизацию (кэширование) адресов. В этом случае число обменов с удаленными серверами сократится.
На рисунке 5 удаленный сервер домена сам разрешает запрос на получение IP-адреса хоста своего домена по рекурсивному запросу, используя при этом нерекурсивный опрос своих серверов поддоменов.
Рис 4. Нерекурсивная обработка запроса местным сервером доменных имен на получение IP-адреса по доменному имени.
Рис. 5. Рекурсивная (для местного сервера) и нерекурсивная (для удаленного сервера) процедуры разрешения адреса по IP-имени.
При этом локальный сервер сразу получает от удаленного адрес хоста, а не адреса серверов поддоменов. Удаленному серверу при этом должно быть разрешено обслуживание рекурсивных запрос с соответствующего IP-адреса, местный сервер должен обратиться к удаленному с рекурсивным запросом.
Представленные здесь варианты работы системы доменных имен не являются исчерпывающими. За более подробной информацией следует обращаться к RFC-1034 и RFC-1035.
Кеширующий сервер (Cache server)
Как уже отмечалось ранее (см. "Типы серверов доменных имен") это сервер, который не отвечает ни за одну из зон, но используется для исполнения запросов resolver-ов. Он выполняет функции локального сервера доменных имен, т.е. выполняет рекурсивные запросы от прикладных программ к системе DNS. При этом в его кэш накапливается информация о соответствиях между доменными именами и IP-адресами, что позволяет существенно повысить скорость обработки запросов и разгрузить другие серверы доменных имен.
В соответствии со своими функциями кэширующий сервер будет иметь всего три файла настройки: файл named.conf, файл с описанием серверов обслуживающих корневую зону и файл описания обратной зоны для зоны 0.0.127.in-addr.arpa.
Формат, структуру и содержание двух последних файлов обсудим позже, а сейчас сосредоточимся на named.conf. Возьмем вариант из руководства по администрированию BIND версии 9:
// Two corporate subnets we wish to allow queries from. acl "corpnets" {192.168.4.0/24; 192.168.7.0/24 }; options { directory "/etc/namedb"; // Working directory pid-file "named.pid"; // Put pid file in working allow-query {"corpnets";}; }; // Root server hints zone "." { type hint; file "root.hint"; }; // Provide a reverse mapping for the loopback address 127.0.0.1 zone "0.0.127.in-addr.arpa" { type master; file "0.0.127.in-addr.arpa"; notify no; };
В данном примере описана настройка кэширующего сервера для двух подсетей. Они перечислены в access control list (директива acl ) и названы как "corpnet". Теперь в любом месте файла настройки можно ссылаться на этот список просто как на "corpnet", что, собственно и сделано в директиве options.
В директиве "options" вначале указан рабочий каталог named (опция directory). В нем располагаются все файлы, которые программа использует при своей работе, в том числе и файлы описания зон. Эта опция аналогична команде directory из файла настроек bind версий 4.х.
Затем опция pid-file указывает имя файла в которые будет помещен идентификатор процесса named. Этот файл будет расположен в рабочем каталоге named (т.е. /etc/namedb)
Последняя опция директивы options - allow-query. Она определяет список IP-адресов, для которых разрешено обращаться с запросами к серверу. Другие хосты обслуживаться данным сервером доменных имен не будут. Еще раз обращаем внимание на то, что любые другие хосты с любыми запросами не будут обслуживаться, т.е. не будут обслуживаться как рекурсивные, так и нерекурсивные запросы.
Директива "zone" позволяет описать местоположение и опции для обслуживания зоны. Две зоны обычно всегда описывают. Это зона "." (корневая зона) и обратная зона для адреса 127.0.0.1.
Описание зоны "." (корня дерева доменных имен) необходимо для того, чтобы сервер мог обращаться к "корневым" серверам, с запросами на получение справки о том, где искать "ответственного" за зону, из которой клиент хочет получить информацию (IP-адрес или доменное имя). По этой причине тип зоны определен как "hint", т.е. в буквальном переводе - "справочный", "ссылочный", "наводка на", "намек на", "совет" и т.п..
Само описание "корневых" серверов находится в файле root.hint. Файл поставляется вместе с дистрибутивом, но администратор должен следить за обновлениями этого файла. О том, как это делать мы рассмотрели подробно при описании настроек BIND 4 (cache файл).
Описание обратной зоны для 127.0.0.1 необходимо для того, чтобы можно было локально разрешать (получать соответствие между IP-адресом и именем) при обращениях с реверсивными запросами к зоне 0.0.127.in-addr.arpa. О важности реверсивных запросов будет сказано в разделе посвященном описанию обратной зоны для маршрутизируемой сети (подсети). Здесь мы только укажем, что описать данную зону нужно в целях соблюдения единообразия, отладки и аккуратной работы сервиса DNS.
Для зоны 0.0.127.in-addr.arpa наш сервер будет первичным (primary), поэтому его тип опцией type будет определен как master.
В самом деле за эту зону отвечает только наш сервер. Адрес 127.0.0.1 за пределы хоста не маршрутизируется, поэтому у других серверов будет своя зона 0.0.127.in-addr.arpa.
Обратите внимание, что речь идет о кэширующем сервере, а определяем мы его и как master для одной из зон. В данном случае термин "кэширующий" говорит о том, что наш сервер не поддерживает ни одну из реально существующих зон, т.е. ему не делегировано прав на такое обслуживание.
Описание обратной зоны для 0.0.127.in-addr.arpa находится в файле "0.0.127.in-addr.arpa". Вообще говоря, файл может иметь любое имя, которое допускается файловой системой. На самом деле в документации по BIND 9.x для описания зоны используется имя "localhost.rev". Изменить имя в примере было нужно для того, чтобы отразить часто встречающуюся практику именования файлов описания зон именами самих зон. Еще раз подчеркнем, что имя может быть любым допустимым в контексте конкретной файловой системы именем.
Последняя опция "notify" позволяет реализовать режим оповещения об изменениях другие сервера, которые поддерживают данную зону, обычно, вторичные (резервные, secondary, slave). Для нашей обратной зоны это в принципе не нужно, поэтому опция установлена в значение "no". Если же говорить вообще, то не все серверы поддерживают этот режим. Общая практика заключается в том, что обновления "расползаются" по сети в соответствии с параметрами записи SOA из описания зоны.
Кэширующие (cache) серверы
. Этот тип серверов отличается от тех, что мы обсудили раньше, тем, что сервер данного типа не является авторитативным для какой-либо зоны.
Серверы данного вида используют для организации централизованного кеширования соответствий доменных имен и IP-адресов. Идея организации кэширующего сервера состоит в том, чтобы на искать соответствие доменного имени и IP-адреса в сети, а накапливать их в своем локальном кэше и обслуживать от туда запросы relover-ов.
Кэш-сервер не поддерживает описаний зон и, соответственно, не посылает resolver-ам авторитативных откликов:
> www.w3.org Server: [144.206.192.60] Address: 144.206.192.60
Non-authoritative answer: Name: www.w3.org Addresses: 18.29.1.35, 18.7.14.127, 18.29.1.34
>
Выше приведен типичный отклик кэширующего сервера на запрос nslookup об адресе www.w3.org. Если бы сервер был авторитативным, то строчки "Non-authoritative answer" в отклике мы бы не увидели.
Мы не обсудили еще один тип серверов - это
Master-сервер (primary, первичный)
доменных имен является ответственным (authoritative) за информацию о зоне в том смысле, что читает описание зоны с локального диска компьютера, на котором он функционирует и отвечает в соответствии с этим описанием на запросы resolver-ов. Описание зоны master-сервера является первичным, т.к. его создает вручную администратор зоны. Соответственно, вносить изменения в описание зоны может только администратор данного сервера. Все остальные серверы только копируют информацию с master-сервера. Вообще говоря, такое определение несколько устарело, и позже будет ясно почему. Но при настройках реальных серверов мы будем использовать именно это определение.
Для зоны можно определить только один master-сервер, т.к. первоисточник может и должен быть только один.
Name
- это имя объекта. Объектом может быть хост, домен и поддомен. Существуют специальные правила именования объектов, которые базируются на понятии текущего имени домена.
Если в качестве значения поля name указан символ "@", то текущим именем домена является имя, указанное в директивах primary, secondary или cache файла named.boot (BIND 4) или zone файла named.conf (BIND 8 или 9), в зависимости от того, о каком файле базы данных named идет речь. В противном случае для определения текущего имени должна быть указана директива $ORIGIN.
Если имя в записи описания ресурса опущено, то ресурс относится к текущему имени домена. Если имя указано без точки на конце, то оно расширяется текущим именем домена. Для изменения текущего имени домена следует ввести либо команду $ORIGIN, либо указать имя записи ресурса с точкой на конце. Например:
Файл конфигурации named:
zone "kyky.ru" in { type master; file "kyky.ru"; };
Файл "kyky.ru":
\@ IN SOA ns.kyky.ru. user.kuku.ru. ( 1 3h 1h 1w 1h ) IN NS ns.kyky.ru. ns IN A 192.168.0.1 $ORIGIN kuku.ru. ns IN A 192.168.0.1 www.kyky.ru. IN A 192.168.0.2
В выше приведенном пример мы предполагаем, что речь идет о master файле зоны kyky.ru. Именно она у казана в файле конфигурации named (версия BIND 9). Символ "@" в первой позиции первой строки (запись SOA) указывает на то, что текущим именем домена является имя kyky.ru. Для записи описания сервера доменных имен это имя наследуется из записи SOA. Запись описания сервера доменных имен (NS), следовательно относится к домену kyky.ru, т.е. авторитативный сервер доменных для домена kyky.ru называется ns.kyky.ru.
Далее определяется адрес хоста, который имеет имя ns.kuku.ru. При этом вовсе не обязательно указывать имя целиком, т.к. у ns на конце нет символа ".", и, следовательно, данное имя является не полным, и будет расширено до ns.kyky.ru.
Последняя строка определяет адрес для хоста с именем www.kyky.ru, т.к. доменное имя в этом случае заканчивается точкой, то оно не будет расширено значением текущего доменного имени.
Теперь мы переопределяем текущее имя домена при помощи директивы $ORIGIN. Текущее имя домена теперь - kuku.ru. Следовательно, следующая строка будет определять адрес машины ns.kuku.ru.
Если в качестве имени указана одна точка(".") или две точки("..") то такая запись описывает домен root, т.е. корневой домен.
Если в качестве имени указана одна точка(".") или две точки("..") то такая запись описывает домен root, т.е. корневой домен.
Если в имени записи встречается символ "*", то это он означает что вместо него можно подразумевать любую разрешенную последовательность символов. В англоязычных источниках это называют "wildcard character". Для пользователей любой операционной системы употредление этого символа хорошо знакомо по командам dir (MS-DOS) или ls (Unix). Например, при необходимости получить список файлов, оканчивающихся расширением "bak", и только их выдается команда:
/usr/paul>ls *.bak
Точно также используется этот символ и в имени записи базы данных описания домена. Если в поле имени указан только символ "*", то это предполагает "*.. Если за "звездочкой" следует имя, то оно ограничивает расширение имен "звездочкой". Например, "*.polyn.kiae.su." определяет все имена из домена polyn.kiae.su, в том числе и имена машин в поддоменах, а не только имена машин в корне домена и имена самих поддоменов. Наиболее часто "*" используется в записях MX, которые регулируют обмен электронной почтой между Интернет-почтой и другими почтовыми службами.
Не следует, однако, думать, что символ "*" может быть использован где угодно. Место использования маски строго определено - это может быть только первый символ в поле имени текущего домена, отделенный от остальных символом ".".
Если в поле имени указан только символ "*", то он маскирует доменные имена хостов текущего домена. Однако, если для какого либо хоста существуют RR записи, то маска на этот хост не распространяется:
*.kyky.ru. IN MX 10 mail.kyky.ru. first IN A 192.168.0.1 sub.kyky.ru. IN NS second.kyky.ru.
В приведенном выше примере, для всех хостов из зоны kyky.ru в качестве почтового посредника должен использоваться хост mail.kyky.ru. Однако, для first.kyky.ru это не так - в описании зоны есть запись описания ресурса для first.kyky.ru.
Кроме того, для делегированной зоны sub.kyky.ru хост mail.kyky.ru тоже не является почтовым посредником, т.к. для делегированных зон согласно RFC-1034 "делегирование прерывает действие маски".
При назначении имен следует иметь в виду, что не любой символ может быть использован в доменном имени. При этом существует некоторое рассогласование в документах регламентирующих DNS по поводу того, какие символы можно использовать в доменном имени, а какие использовать нельзя.
Так, например, в RFC-1033 прямо указано, что в имени можно использовать любые восьмибитовые отображаемые символы. При этом, правда сделана ссылка на то, что в других протоколах существуют ограничения, а потому рекомендованы символы "A-Z", "a-z", "0-9", а также символы "-" и "_".
Однако в RFC-1034 принято более жесткое определение того, что такое доменное имя. Из разрешенного списка исключили символ подчеркивания и постановили, что система не различает заглавные и прописные буквы, т.е. имена kuku, KUKU, KuKu - это одно и тоже имя.
Любопытно, что не во всех версиях BIND проверяется правильность доменного имени, а в последних версиях можно управлять проверкой правильности. Но уповать на то, что любые отображаемые символы будут правильно распознаны системой DNS, не стоит.
Кроме того, проблема именования доменов в настоящее время упирается в именование доменов не только символами английского алфавита. Но это уже совсем другая история.
Поле
Настройка BIND 4.x для поддержки небольшого корпоративного домена
Сначала мы рассмотрим случай, когда наш сервер должен будет только обслуживать запросы к зоне своей ответственности vega.ru. Это означает, что он не должен обрабатывать рекурсивные запросы.
Программа named, установленная на машине шлюзе будет иметь следующую конфигурацию, которая задается файлом named.boot:
; ; Zone vega.ru data base files. ; directory /etc/namedb
primary vega.ru vega.ru primary localhost localhost primary 127.in-addr.arpa localhost.rev primary 43.226.194.in-addr.arpa vega.rev cache . named.root
В этом файле директивой directory определено, что директория расположения описания файлов зоны vega.ru - /etc/namedb. Это стандартная директория для BIND. Первая директива primary определяет файл описания "прямой" зоны домена vega.ru - файл vega.ru, размещенный в директории /etc/namedb (/etc/namedb/vega.ru). Вторая директива primary определяет описание зоны localhost.
Кроме "прямых" зон описаны еще две обратных зоны 127.in-adrr.arpa и 43.226.194.in-addr.arpa. Первая определяет обратное соответствие между адресом 127.0.0.1 и именем localhost, а вторая множество обратных соответствий для сети 194.226.43.0.
Последней директивой указан файл начальной загрузки cache. Точка, символ "." в качестве первого аргумента указывает на описание корневой зоны.
Теперь нам нужно отключить рекурсию. Это делается при помощи директивы options:
; ; Zone vega.ru data base files. ; directory /etc/namedb
primary vega.ru vega.ru primary localhost localhost primary 127.in-addr.arpa localhost.rev primary 43.226.194.in-addr.arpa vega.rev cache . named.root options no-recursion
Вообще говоря, опция no-recursion обычно употребляется вместе с опцией no-fetch-glue. Это позволяет запретить серверу искать адреса серверов доменных имен при конструировании отклика с секцией дополнительных данных. Например, искать и заносить в эту секцию адресные записи для серверов доменных имен, которые посылаются в ответах (refferal) на запросы к зонам, для которых данный сервер не является авторитативным.
Это позволяет избежать лишнего трафика, а также "отравления" кэша нашего сервера.
; ; Zone vega.ru data base files. ; directory /etc/namedb
primary vega.ru vega.ru primary localhost localhost primary 127.in-addr.arpa localhost.rev primary 43.226.194.in-addr.arpa vega.rev cache . named.root options no-recursion no-fetch-glue fake-iquery
В примере кроме no-fetch-glue мы добавили еще одну опцию - fake-iquery. Она позволяет правильно обрабатывать инверсные запросы (не путать с запросами к обратным зонам). Инверсные запросы считаются атавизмом и не поддерживаются в современных версиях DNS серверов, но обрабатывать их нужно корректно. Если не указывать опцию обработки этих запросов, то сервер будет сообщать об ошибке, что неправильно.
На самом деле мы забыли еще об одной вещи. Для нашей зоны существует еще и slave сервер. В нашей конфигурации он никак не упомянут. Это никак его не ограничивает, и он может благополучно копировать описание зоны с нашего сервера. Но кроме него это могут делать и другие серверы и программы. При современных веяниях это нехорошо. Интернет слишком агрессивная среда для такой открытости.
Следует ограничить число хостов, которым дозволено копировать зону:
; ; Zone vega.ru data base files. ; directory /etc/namedb
primary vega.ru vega.ru primary localhost localhost primary 127.in-addr.arpa localhost.rev primary 43.226.194.in-addr.arpa vega.rev xfrnets 194.226.65.0 cache . named.root options no-recursion no-fetch-glue fake-iquery
В данном случае мы определили возможность копирования зоны только для хостов из сети, где расположен наш slave сервер. В принципе, можно определить хост точно. Для этого следует применить маску:
xfrnets 194.226.65.3&255.255.255.255
Сразу видно, что синтаксис "старый". Сейчас написали бы 194.226.65.3/32.
Когда мы говорили только об обслуживании запросов к зоне, то мы действовали в строгом соответствии с рекомендациями CERT, где указывается на желательность разнесения функций кэширующего сервера и сервера, отвечающего за зону.
В большинстве случаев применения BIND эти функции совмещают. Севрер является авторитативным сервером корпоративного домена и одновременно выполняет функции кэширующего сервера для хостов корпоративной сети.
Очевидным изменением файла настройки named в этом случае будет отказ от запрета на рекурсию:
; ; Zone vega.ru data base files. ; directory /etc/namedb
primary vega.ru vega.ru primary localhost localhost primary 127.in-addr.arpa localhost.rev primary 43.226.194.in-addr.arpa vega.rev xfrnets 194.226.65.0 cache . named.root forwarders 194.226.65.3 options fake-iquery
Кроме отказа от рекурсии в в этом файле конфигурации появилась еще одна директива - forwarders. Она инструктирует сервер в том смысле, чтобы он отправлял запросы, на которые не может ответить сам, на сервер 144.226.65.3.
Таким образом, наш сервер не только обрабатывает рекурсивные запросы, но и сам их порождает, пытаясь воспользоваться "знаниями" другого сервера доменных имен. Естественно, что на том сервере нам должны разрешить себя вести подобным образом.
Теперь рассмотрим как настраивается сервер версий BIND 8.x и 9.x для выполнения точно таких же функций.
Настройка BIND 8.x и BIND 9.x для поддержки небольшого корпоративного домена
Во-первых, здесь мы будем иметь дело с файлом named.conf, который располагается по умолчанию либо в каталоге /etc (BIND 9.x), либо /etc/namedb (BIND 8.x). Во-вторых, формат директив этого файла конфигурации совершенно иной, чем в BIND 4.х.
Сначала рассмотрим сервер, который не поддерживает рекурсивных запросов, но обслуживает запросы к зоне своей ответственности:
options { directory "/etc/namedb"; allow-query {any;}; recursion no; fake-iquery yes; fetch-glue no; use-id-pool yes; }; //Root server hints zone "." { type hint; file "named.root"; }; // Forward Loopback zone "localhost" { type master; file "localhost"; }; // Reverse Loopback zone "0.0.127.in-addr.arpa" { type master; file "localhosr.rev"; }; // Corporative domain zone "vega.ru" { type master; file "vega.ru"; allow-transfer { 194.226.65.3; }; }; // Reverse corporative domain zone "43.226.194.in-addr.arpa" { type master; file "43.226.194.in-addr.arpa"; allow-transfer { 194.226.65.3; }; };
Директива options задает опции, значение которых распространяется на все зоны, поддерживаемые данным сервером. Опция directory определяет место расположения файлов описания зон. Опция allow-query разрешает обслуживать запросы от всех клиентов Интернет. Такое значение в данном случае позволяет отвечать на запросы к зонам ответственности сервера. Опция recursion отменяет обслуживание любых рекурсивных запросов. Далее следуют опции имитации обслуживания инверсных запросов (fake-iquery), отмены поиска дополнительной информации для ответов рефералов (referrals, опция fetch-glue, в BIND 9.х не нужна, т.к. реализована по умолчанию), и опция противодействия спуфингу (use-id-pool в BIND 9.x не нужна, т.к. реализована по умолчанию).
Далее идет описание корневой зоны. Тип зоны указан как hint (буквально "подсказка"). Зона содержит информацию об именах и адресах серверов,обслуживающих корневую зону DNS.
За описанием корневой зоны следуют описания зон "петли" (localhost и 0.0.127.in-addr.arpa).
Сервер определен для этих зон как master зоны. Ни каких дополнительных опций в описании конфигурации этих зон нет.
За ними следует описание настроек named для управления корпоративной зоной (vega.ru). Здесь мы ограничили число хостов, которые могут копировать зону slave сервером зоны. Если необходимо, то здесь можно расположить и другие хосты, которым будет разрешено копировать зону из соображений разгрузки master сервера, например.
Последней указаны настройки named для работы с "обратной" корпоративной зоной. Эти настройки ничем не отличаются от настроек "прямой" зоны.
Теперь мы расширим функциональность нашего сервера и разрешим ему обслуживать рекурсивные запросы. Но только пусть эти запросы будут исходить из корпоративной сети. Если мы просто разрешим рекурсию в директиве options:
options { directory "/etc/namedb"; allow-query {any;}; recursion yes; fake-iquery yes; fetch-glue no; use-id-pool yes; };
то мы своей цели не добьемся. Сервер будет обрабатывать любые рекурсивные запросы, откуда бы они не исходили. В принципе для такого поведения вообще не нужно указывать опцию recursion. Рекурсия включается по умолчанию.
Для того, чтобы разрешить рекурсию только "своим" хостам, следует воспользоваться директивой allow-recursion:
options { directory "/etc/namedb"; allow-query {any;}; recursion no; fake-iquery yes; fetch-glue no; use-id-pool yes; allow-reqursion { 194.226.43/24;}; };
В данном случае рекурсия разрешена только хостам из сети 194.226.43.0. Для всех остальных она запрещена опцией recursion.
Вообще говоря, из всех зон, которыми управляет наш сервер, для всего остального мира интересны только корпоративные зоны: прямая зона vega.ru и "обратная" зона 43.226.194.in-addr.arpa. Поэтому, если строго следовать назначению нашего сервера - обслуживать по максимуму корпоративную сеть и по необходимому минимуму весь остальной мир, мы должны несколько изменить настройки.
В первую очередь разделим весь мир на "своих" и "чужих".
Это делается при помощи директивы acl (access control list):
acl "vega-net" { 194.226.43/24; }; acl "vega-friend" { 194.226.65/24; }; options { directory "/etc/namedb"; allow-query {vega-net;}; recursion no; fake-iquery yes; fetch-glue no; use-id-pool yes; };
Два списка контроля доступа содержат пулы адресов корпоративной сети и сети slave сервера. Первый список мы применяем в директиве options. Разрешаем серверу обрабатывать запросы только от "наших" хостов (allow-query).
Опции директивы options распространяются на все зоны нашего сервера, поэтому, если мы хотим какую-либо из них обслуживать иначе, то должны в ее конфигурацию ввести изменения. Иначе мы обслуживаем зоны vega.ru и 43.226.194.in-addr.arpa:
// Corporative domain zone "vega.ru" { type master; file "vega.ru"; allow-query {any; }; allow-transfer { vega-friend; }; }; // Reverse corporative domain zone "43.226.194.in-addr.arpa" { type master; file "43.226.194.in-addr.arpa"; allow-query {any; }; allow-transfer { vega-friend; }; };
В описании этих зон мы применили список доступа vega-friend и только для этих зон разрешили обслуживание любых нерекурсивных запросов.
В принципе, можно было обойтись и без списков доступа, но в данном случае мы просто преследовали цель продемонстрировать способ их применения. Корпоративная сеть может быть развернута не на одной сети класса C, для дружественных сетей можно разрешить не только копирование зоны, но и удаленное ее (зоны) обновление. В этом случае списки увеличатся в объеме, и их копирование в разные части файла конфигурации может привести к нежелательным ошибкам.
Кроме того, при изменениях корпоративной сети и дружественных сетей вносить изменения придется только в списки управления доступом, а не в разбросанные по всему файлу описания. Использование списков управления (контроля) доступа - это более правильный стиль.
В BIND 9.х есть еще один механизм для определения различного поведения сервера при обслуживании запросов - "views".В материалах CERT для управления рекурсией приведена, например, такая конфигурация:
// Corporative domain view "internalview" { match-clients { internal; }; recursion yes; }; // Internet view "externalview" { match-clients { any; }; recursion no; };
Слово "internal" - это имя списка доступа, а слово "any" обозначение любого хоста Интернет.
На этом, пожалуй, можно и остановиться. Дальнейшее усложнение конфигурации сервера будет связано с вопросами безопасности и управления обновлениями зоны, но эти вопросы логичнее рассмотреть в других материалах, специально посвященных этим проблемам.
Настройка BIND версий 8 и 9.
Named из пакета BIND 8-ой или 9-ой версий в своей настройке и управлении имеет ряд отличий от версии 4. Во-первых, файл конфигурации носит название named.conf и располагается по умолчанию либо в /etc (версия 9), либо в /etc/namedb (версия 8). Во-вторых, у named отсутствует хранимый на диске cache, описание корневой зоны вынесено в отдельный файл, и его нужно прописывать в настройках named. В-третьих, стало возможным дистанционно управлять named.
При запуске программа named читает файл named.conf и таким образом настраивается. Ранее были разобраны формат, структура и содержание файла настройки программы named версий 4.х. Учитывая тот факт, что "четверка" - это уже история, сосредоточимся теперь на файле настройки более свежих версий named.
Основные изменения, которые произошли с named, касаются повышения устойчивости сервера к различного рода атакам, что и отразилось в настройках. Администратор сервера получил возможность управлять копированием зон, обслуживанием запросов на разрешение имен ip-адресами (в данном случае слово "разрешение" употребляется в смысле "установка соответствия", а не в смысле "разрешить что-то делать"). Собственно, любая рекомендация перехода на новые версии named аргументируется более высокой защищенностью программы.
Внешним наиболее заметным отличием файла настройки версий 8.х и 9.х стал иной синтаксис. Он стал C-подобным (если бы новую версию программы начали делать сейчас, а не в 1997 году, то файл настройки получил бы наверное XML-синтаксис J).
Рассматривать все варианты конструкций в файле настройки named.conf, видимо не имеет смысла, а потому сосредоточимся только на наиболее часто встречающихся вариантах и наиболее привлекательных особенностях. При этом многие вопросы, связанные с безопасностью, динамическим обновлением и другими новыми возможностями оставим для отдельного обсуждения.
Прежде, чем приступить к обсуждению named.conf следует обратить внимание на место его расположения в файловой системе.
Это важно, т.к. при установке named из портов (ports, т.е. установки двоичных, откомпилированных под определенную платформу версий named утилитами (скриптами) установки) место расположения этого файла может отличаться от того, которое выбирается по умолчанию, при установке из исходных кодов.
По умолчанию named.conf (установка из исходных кодов) располагается в каталоге /etc/namedb/ (версия 8) или /etc (версия 9). Как любая прикладная программа, named позволяет переопределить место положение своего файла настройки при помощи флага b или c в командной строке при своем запуске:
>named -c /etc/named.conf
Если Вы работаете с Unix-системой, то нужно внимательно посмотреть файлы конфигурации скриптов начальной загрузки и сами скрипты (обычно что-то типа rc.*, в разных клонах могут быть расположены в различных местах, но корнем пути к которым (местам), обычно, является каталог /etc), чтобы убедиться, что установки умолчания для named не переопределены.
И последнее замечание прежде, чем приступить к описанию примеров. Во всех примерах BIND 8-9 используются адреса, так называемых, немаршрутизируемых сетей. По этой причине будьте внимательны при копировании отдельных фрагментов примеров, если, конечно, Вы сочтете такое копирование полезным J.
Настройка кеширующего сервера в BIND 4.х
Сначала следует прописать правильным образом информацию в файле настройки самого сервера - named.boot, который располагается в каталоге /etc:
directory /etc/namedb
primary 127.in-addr.arpa 127.in-addr.arpa cache . named.root
Первая строка этого файла определяет каталог, в котором хранятся описания зон. На первый взгляд нам эти описания не нужны, ведь мы настраиваем кэширующий сервер доменных имен, но при более детальном рассмотрении каталог нужен, т.к. наш сервер будет авторитативным для одной обратной зоны - 127.in-addr.arpa.
Именно этот факт и определяет вторая строка файла конфигурации сервера, в которой указана директива primary, определяющая, что сервер является master (в терминологии BIND 4.х - primary) для зоны 127.in-addr.arpa. Имя зоны задано вторым параметром директивы primary. Третий параметр этой директивы определяет имя файла в каталоге /etc/namedb, где описана соответствующая директиве зона.
Имя файла описания этой зоны может быть любым. Например, в последнее время модно называть его localhost.rev. Собственно, это имя генерирует скрипт make-localhost, который автоматически составляет описания зоны локального хоста.
Последняя директива (cache) определяет список серверов, обслуживающих корневой домен. В настоящее время никакой другой функции у этого файла нет, хотя по названию можно было бы предположить, что его назначение гораздо шире. В настоящее время этот файл используется только для получения адресов корневых серверов и загрузки с одного из них (обычно тот, что быстрее откликнется, а откликается первым а-сервер, т.к. его первым спрашивают) свежего списка серверов, ответственных за корневую зону.
Теперь посмотрим на содержание файлов описанных в named.boot и расположенных по умолчанию в каталоге /etc/namedb. Если они расположены в другом месте, то это указывается в директиве directory файла named.boot.
Содержание 127.in-addr.arpa:
; From: @(#)localhost.rev 5.1 (Berkeley) 6/30/90 ; $Id: PROTO.localhost.rev,v 1.1 1995/03/21 16:33:44 wollman Exp $ ; ; This file is automatically edited by the `make-localhost' script in ; the /etc/namedb directory. ;
ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ; ; formerly NS.NASA.GOV ; . 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ; ; formerly NS.ISC.ORG ; . 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 ; ; formerly NS.NIC.DDN.MIL ; . 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 ; ; formerly AOS.ARL.ARMY.MIL ; . 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 ; ; formerly NIC.NORDU.NET ; . 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 ; End of File
Мы специально включили именно эту версию файла named.root, которая шла с дистрибутивом BIND 4.9.6 для операционной системы IRIX 6.5. При реальной работе с BIND следует и версию named поставить поновее и файл описания корневой зоны получить "свежий".
Теперь мы имеем все необходимые файлы для запуска кэширующего сервера. Запускаем сервер:
>named
и все должно работать.
Настройка кэширующего сервера
В данном материале мы рассмотрим настройку сервера доменных имен, который выполняет рекурсивные запросы и функции кэширования записей описания ресурсов DNS для группы хостов. При этом данный сервер не будет поддерживать никакой зоны, т.е. он не будет авторитативным для какой-либо зоны пространства доменных имен Интернет.
Если рассматривать функции кэширующего сервера с точки зрения архитектуры DNS, описанной в RFC-1034, то это "умный" resolver. А точнее, "умный" независимый resolver, который выполняет рекурсивные запросы прикладных программ.
Очевидно, что при такой постановке вопроса ответственность за какую-либо зону на наш сервер не возлагается. Его главное назначение - принимать запросы от клиентов и опрашивать другие (авторитативные) серверы доменных имен на предмет поиска необходимой клиентам информации.
Второй основной задачей такого сервера является хранение найденной информации (записей описания ресурсов) к своем кэше в течение времени жизни этой информации. При этом в кэш в соответствии с RFC-1034 должна попадать не только информация о конечном соответствии IP-адреса и доменного имени, но и информация найденная в процессе поиска конечного соответствия, например, информация об авторитативных серверах зон доменных имен.
Мы будем рассматривать настройку такого типа сервера на примере программного обеспечения BIND, т.к. большинство серверов, которые в настоящее время установлены в сети - это серверы BIND, хотя эта точка зрения и горячо оспаривается профессором Бернштейном (автор djbdns) во всех конференциях и списках, касающихся системы DNS. По крайней мере, BIND поставляется в комплекте со свободно распространяемыми клонами Unix, что делает знакомство с ним необходимым для большинства сетевых администраторов.
Для того, чтобы настроить BIND в качестве кэширующего сервера необходимо создать и заполнить соответствующей информацией следующие файлы:
named.boot (для BIND 4.x); named.conf (для BIND 8.x и BIND 9.x); root.cache (для BIND 4.x); описание серверов корневой зоны (зона типа hint для BIND 8.x и BIND 9.х); описание зоны 127.in-addr.arpa.
Будем рассматривать эти настройки по версиям BIND, и начнем с BIND 4.x, хотя она и является очевидным атавизмом.
Настройка кэширующего сервера в BIND 8.х и BIND 9.х
Отличие данного случая от случая BIND 4.х, описанного выше, заключается в том, что вместо named.boot мы должны создать файл named.conf, который имеет совсем другой формат управляющих директив. Вот пример его содержания:
options { directory "/etc/namedb"; }; zone "." in { type hint; file "named.root"; }; zone "0.0.127.in-addr.arpa" in { type master; file "127.in-addr.arpa"; };
Это содержание файла named.conf полностью соответствует конфигурации BIND 4.х, которую мы разбирали выше.
Директива options определяет каталог, в котором хранятся файлы описания зон, директива zone определяет зоны, которые поддерживает сервер.
Зона "." сервером не поддерживается. Это корневая зона. Поэтому она имеет тип hint, т.е. "подсказка" на то, где описаны серверы корневой зоны.
Зона "0.0.127.in-addr.arpa" имеет тип master, т.к. данный сервер действительно является мастером для этой зоны.
Заметим, что по умолчанию в BIND 8.x и BIND 9.x файл named.conf расположен в разных каталогах. В BIND 8.x в каталоге /etc/namedb, а в BIND 9.х в каталоге /etc. Но, в принципе, используя параметры командной строки named этот порядок можно переиграть. Тем более его можно переиначить при сборке сервера из исходных текстов.
Теперь можно запускать named:
>named
Для BIND 8 сервер действительно запуститься, а вот для BIND 9.x этого скорее всего не произойдет. В файле системного журнала будет получено сообщение вида:
Nov 20 13:49:36 quest named[34123]: starting BIND 9.2.1 Nov 20 13:49:36 quest named[34123]: none:0: open: /etc/rndc.key: file not found Nov 20 13:49:36 quest named[34123]: couldn't add command channel 127.0.0.1#953: file not found
Для того, чтобы такое сообщение не появлялось нужно отменить удаленное управление сервером, которое обычно осуществляют через программу rndc:
options { directory "/etc/namedb"; }; controls {}; zone "." in { type hint; file "named.root"; }; zone "0.0.127.in-addr.arpa" in { type master; file "127.in-addr.arpa"; };
Мы просто вставили директиву controls с пустым содержанием.
Вообще говоря, лучше создать требуемые файлы ключей и работать через программу rndc, но в контексте данного материала, когда мы рассматриваем последовательно BIND 4.x - BIND 8.x - BIND 9.x, отмена контроля выглядит вполне логично.
На самом деле, конечно, такая простая конфигурация сервера не является хорошим стилем. Во-первых, мы создаем кэширующий сервер не для всех желающих, а только для хостов, которые мы обслуживаем, во-вторых, желательно не сообщать о том, что за версия сервера у нас установлена, в-третьих, существует еще несколько мелочей, которые желательно указать в файле настройки named.
Для того, чтобы отделить весь мир от "наших" хостов нужно создать список доступа:
acl "our_folks" { 192.168.1.0/24; }; options { directory "/etc/namedb"; allow-recursion { "our_folks"; }; allow-query {"our_folks"} version "unknown"; fake-iquery no; }; controls {}; zone "." in { type hint; file "named.root"; }; zone "0.0.127.in-addr.arpa" in { type master; file "127.in-addr.arpa"; };
В данном файле конфигурации мы разрешили рекурсию (рекурсивные запросы) с нашей локальной сети, кроме того, разрешили какие-либо запросы (не только рекурсивные) тоже только с нашей локальной сети, скрыли версию named и отменили явно инверсные запросы (fake-iquery).
Вообще говоря, в данном случае можно было не вводить ограничения рекурсию, а ограничить только саму возможность обработки запросов (allow-query). Рекурсивные запросы - это только одно из подмножеств запросов и оно автоматически попадает на наложенное на обработку запросов ограничение.
Запрет на инверсные запросы - это тоже избыточная директива. Современные серверы этот тип запросов не поддерживают, а только корректно сообщают о таком своем поведении.
На самом деле в рекомендациях CERT (Computer Emergency Responds Team) есть еще несколько моментов, которые позволяют ограничить себя от разного сорта неприятностей с кэширующим сервером доменных имен.
В первую очередь это касается спуфинга, т.е. подмены отклика авторитативного сервера доменных имен поддельными пакетами в ответ на реальный запрос. Для этого необходимо, чтобы идентификаторы пакетов генерировались случайным образом.
В BIND 9.x это реализовано по умолчанию, а в BIND 8.x для этой цели нужно вставить опцию use-id-pool:
acl "our_folks" { 192.168.1.0/24; }; options { directory "/etc/namedb"; allow-recursion { "our_folks"; }; allow-query {"our_folks"} version "unknown"; fake-iquery no; use-id-pool yes; }; controls {}; zone "." in { type hint; file "named.root"; }; zone "0.0.127.in-addr.arpa" in { type master; file "127.in-addr.arpa"; };
Ограничение на исполнение рекурсивных запросов также повышает безопасность работы, т.к. не позволяет провоцировать сервер на запросы к зонам, находящимся под контролем злоумышленников, которые могут пытаться проделывать всякие предосудительные действия, например, "отравление" кэша вашего сервера.
В пакете BIND 9.x в комплект поставки входит легковесный resolver. Его функциональность не соответствует функциональности кэширующего сервера. Легковесный resolver может выполнять только рекурсивные запросы программного обеспечения, которое функционирует на том же самом хосте, где этот resolver запущен. Он не может обслуживать группу хостов.
Настройка named (BIND/ name server). Кэширующий сервер, slave и master
В этом материале будут разобраны различные версии нотации файла конфигурации программы named. Мы опишем также назначение некоторых директив файлов конфигурации и разберем типовые примеры для кэширующего, master и slave серверов.
Named - это сервер доменных имен пакета BIND. Named может реализовывать функции серверов любого типа: master, slave, cache (см. материал "Типы серверов доменных имен).
Программа named в момент запуска или перезапуска считывает данные из своего файла конфигурации и файлов описания зон, если они существуют, и таким образом настраивается.
Формат файла конфигурации для 4-ой версии программы отличается от того, который применяется в 8-ой и 9-ой версиях BIND. В силу целого ряда причин имеет смысл рассмотреть оба формата файла конфигурации.
Настройка slave сервера в BIND 4.x.
Мы будем рассматривать настройку сервера в качестве slave сервера в контексте домена vega.ru, т.е. сервер этого домена будет одновременно выполнять функции slave сервера для другого домена:
directory /etc/namedb
primary vega.ru vega.ru secondary corp.ru 192.168.0.1 10.0.0.1 corp.ru primary localhost localhost primary 127.in-addr.arpa localhost.rev primary 43.226.194.in-addr.arpa vega.rev cache . named.root
В данном случае наш сервер размещает файлы описания зон в /etc/namedb. Именно там и появится файл зоны, которую этот сервер с копирует с одного из серверов домена corp.ru.
Сами master серверы прописаны в директиве secondary вслед за именем домена. Всего можно перечислить до 10 IP-адресов серверов, с которых наш сервер может скопировать зону.
Последний аргумент директивы secondary - это имя файла, куда записываются данные зоны. В нашем случае мы используем тот же принцип наименования файлов описания зон, что и в случае "прямых" зон: имя файла совпадает с именем зоны.
На самом деле, для slave сервера действуют все те же принципы ограничения доступа к описанию зоны и защите его от повреждения, что и для "прямой зоны".
Во-первых, можно ограничить обслуживание рекурсивных запросов:
directory /etc/namedb
primary vega.ru vega.ru secondary corp.ru 192.168.0.1 10.0.0.1 corp.ru primary localhost localhost primary 127.in-addr.arpa localhost.rev primary 43.226.194.in-addr.arpa vega.rev cache . named.root options no-recursion
Во-вторых, применить опции снижающие опасность спуфинга сервера:
directory /etc/namedb
primary vega.ru vega.ru secondary corp.ru 192.168.0.1 10.0.0.1 corp.ru primary localhost localhost primary 127.in-addr.arpa localhost.rev primary 43.226.194.in-addr.arpa vega.rev cache . named.root options no-recursion no-fetch-glue fake-iquery
В данном случае отменяется формирование дополнительной секции данных и объявляется корректная обработка инверсных запросов.
Теперь мы можем ограничить число хостов, которым сами разрешаем копировать зону:
directory /etc/namedb
primary vega.ru vega.ru secondary corp.ru 192.168.0.1 10.0.0.1 corp.ru primary localhost localhost primary 127.in-addr.arpa localhost.rev primary 43.226.194.in-addr.arpa vega.rev xfrnets 194.226.65.1&255.255.255.255 cache . named.root options no-recursion no-fetch-glue fake-iquery
В данном случае число таких хостов уменьшили до одного.
На самом деле, файл, который мы получаем при копировании зоны на slave сервер несколько отличается от исходного. Например, там нет "приклеенных" адресных записей, которые не относятся к нашей зоне.
Настройка slave сервера в BIND 8.x и 9.x.
Настройка BIND 8.x и 9.x отличается синтаксисом и более широкими возможностями по управлению конфигурацией сервера. Для того, чтобы поддерживать slave сервер нам нужно в файл конфигурации вставить код вида:
zone "corp.ru" { type slave; file "corp.ru"; masters { 192.168.0.1; 10.0.0.1;}; };
Многие настройки в BIND 8.х и 9.x в файле конфигурации собраны в директиве options. Поэтому их указание в описание зоны не требуется. А вот разрешить, или нет копирование зоны, лучше указывать внутри директивы zone:
zone "43.226.194.in-addr.arpa" { type master; file "43.226.194.in-addr.arpa"; allow-query {any; }; allow-transfer { none; }; };
В данном случае, с нашего сервера вообще никто не сможет скопировать зону, т.к. мы указали в списке разрешения на копирование ключевое слово "none". Такая настройка вполне оправдана, т.к. обычно slave является последним сервером в дереве серверов поддерживающих зону.
Вообще говоря, прежде, чем запускать сервер, желательно проверить сааму возможность копирования зоны с master сервера на slave сервер. Для этого можно воспользоваться программой dig, например,:
> dig @polyn.kiae.su bard.kiae.ru. axfr
P ; > DiG 8.3 > @polyn.kiae.su bard.kiae.ru. axfr ; (1 server found) $ORIGIN bard.kiae.ru. @ 1H IN SOA ns.polyn.kiae.ru. paul.polyn.kiae.su. ( 7 ; serial 1H ; refresh 5M ; retry 16w3d17h46m39s ; expiry 1H ) ; minimum
1H IN NS polyn.kiae.ru. 1H IN NS iris.polyn.kiae.su. 1H IN MX 10 mail 1H IN MX 20 iris.polyn.kiae.ru. 1H IN A 144.206.192.32 mail 1H IN MX 10 mail 1H IN A 144.206.192.32 www 1H IN A 144.206.192.32 @ 1H IN SOA ns.polyn.kiae.ru. paul.polyn.kiae.su. ( 7 ; serial 1H ; refresh 5M ; retry 16w3d17h46m39s ; expiry 1H ) ; minimum
;; Received 10 answers (10 records). ;; FROM: generate.polyn.kiae.su to SERVER: 144.206.160.32 ;; WHEN: Fri Dec 6 16:37:57 2002 >
Но более правильным было бы использовать саму программу named, а точнее компоненту пакета BIND named-xfer, которая отвечает за копирование зоны на slave сервер:
> /usr/libexec/named-xfer -z bard.kiae.ru -f polyn.db polyn.kiae.su named-xfer[8443]: send AXFR query 0 to 144.206.160.32 >
В данном случае мы копируем зону (ее описание) bard.kiae.ru в файл polyn.db c сервера polyn.kiae.su. По умолчанию программа использует запрос типа axfr.
Зона после копирования будет выглядеть примерно следующим образом:
; BIND version named 8.2.3-T6B Mon Nov 20 11:24:37 GMT 2000 ; BIND version jkh@bento.FreeBSD.org:/usr/obj/usr/src/libexec/named-xfer ; zone 'bard.kiae.ru' first transfer ; from 144.206.160.32:53 (local 144.206.192.55) using AXFR at ; Fri Dec 6 16:47:3 2 2002 $ORIGIN kiae.ru. bard 3600 IN SOA ns.polyn.kiae.ru. paul.polyn.kiae.su. ( 7 3600 300 9999999 3600 ) 3600 IN NS polyn.kiae.ru. 3600 IN NS iris.polyn.kiae.su. 3600 IN MX 10 mail.bard.kiae.ru. 3600 IN MX 20 iris.polyn.kiae.ru. 3600 IN A 144.206.192.32 $ORIGIN bard.kiae.ru. mail 3600 IN MX 10 mail.bard.kiae.ru. 3600 IN A 144.206.192.32 www 3600 IN A 144.206.192.32 >
В этом примере стоит обратить внимание на комментарий в начале описания зоны, который программа named-xfer прибавляет от себя. В конце комментария содержится дата копирования зоны.
Named-xfer - это вспомогательный агент (как написано в его документации), который используется в BIND до версии 9.х. В новых серверах этого агента нет. Сервер теперь многопоточный и сам может порождать нить копирования зоны, не мешая обслуживанию запросов к этой зоне.
Распараллеливание процедуры обслуживания обычных запросов к зоне и процедуры копирования зоны было той причиной, по которой появилась программа named-xfer. Речь в данном случае идет о slave сервере. Он при помощи named-xfer запрашивает описание зоны и сохраняет его в файле описания. В этот момент старая копия зоны остается в памяти самого сервера, и он благополучно обслуживает запросы к ней. После получения описания зоны сервер перезагружает описание зоны в своей памяти.
В BIND 9 named-xfer нет. Разработчики рекомендуют использовать dig, если очень нужно получить зону по axfr запросу.
Есть только один момент. Программы типа dig, например, host, в точности следуют спецификациям и копируют все что получают. А в качестве ответа на запрос типа axfr запись SOA передается в начале и в конце отклика. Естественно, что конечную запись желательно из файла удалить.
В принципе, slave сервер может не хранить копию зоны у себя в файловой системе. Эта копия нужна только в момент старта. Ее основное назначение - сокращение объем DNS трафика.
Копия не создается, если в директиве secondary BIND 4.х не задано имя файла, или в BIND 8.х и 9.х не задана опция file, которая выполняет аналогичное назначение.
Общие рекомендации, содержащиеся в документации по BIND, советуют все-таки копию описания зоны в файловой системе slave сервера создавать.
В заключении разберем вопрос о проверке работоспособности нашего сервера. Проверить это очень просто: после запуска сервера в рабочем каталоге named должен появиться соответствующий файл.
Можно, конечно, посмотреть работу сервера и при помощи программы dig - отклик должен быть авторитативный.
Неавторитативный отклик (non authoritative response)
возвращают серверы, которые не отвечают за зону, содержащую необходимую resolver информацию.
Это значит, что если наш сервер доменных имен поддерживает домен kuku.ru, и наш resolver настроен таким образом, что посылает рекурсивные запросы к системе доменных имен через наш сервер доменных имен, и при этом мы хотим получить доступ к сайту www.kuku.ru, то мы получим от нашего сервера доменных имен авторитативный отклик, т.к. именно наш сервер отвечает на все запросы к зоне kuku.ru.
Если же мы захотим получить информацию о домене lenta.ru, то в этом случае мы получим неавторитативный отклик с нашего сервера, т.к. он не отвечает за зону lenta.ru и, соответсвенно, либо будет проводить нерекурсивный опрос серверов доменных имен, либо выдаст нам соответствие из своего кэша, т.к. существует большая вероятность того, что кто-то из наших коллег уже обращался с таким запросом к нему.
Авторитативный отклик могут, в свою очередь, вернуть либо master-сервер зоны (primary server), либо slave-сервер (secondary server) зоны. В русскоязычной литературе их называют основным и дублирующим серверами (или первичным и вторичным, соответственно).
Небольшой корпоративный домен
В данном материале мы рассмотрим конфигурацию программы named и файлы описания зон, необходимые для поддержки простого корпоративного домена в зоне ru.Кроме того, мы разберем настройку named для обслуживания запросов к этому корпоративному домену и рекурсивных запросов хостов корпоративной сети через тот же сервер доменных имен.
В первую очередь определимся с термином "корпоративный домен". Мы его используем здесь для обозначения домена второго уровня, т.е. все, что имеет имя типа name.ru - это корпоративный домен.
Строго говоря, это неправильно. Например, msk.ru - это географический домен, а pp.ru - это домен персональных доменов, он относится к типу доменов общего пользования (лучше было бы сказать "общего назначения"). Корпоративный домен - это домен компании.
Если бы домены государственных учреждений или высших учебных заведений размещались бы в доменах типа gov.ru и edu.ru, то можно было бы отдельно говорить как о тех, так и о других, хотя принципиального различия между процедурами поддержки таких доменов нет. Однако, наши учреждения регистрируют свои домены, как домены второго уровня, т.е. не используют домены общего пользования.
Поэтому, обобщив прилагательное "корпоративный" на все имена предшествующие ru, в контексте данного материала, мы будем вести речь о настройке и поддержке зоны корпоративного домена.
Мы оставляем также за пределами данного материала саму процедуру регистрации домена. Она достаточно подробно описана на сайтах независимых регистраторов, например, http://www.nic.ru/dns/service/how.html. Заметим только, что до того, как начать регистрацию домена нужно сконфигурировать и запустить все необходимые для поддержки домена серверы доменных имен. Это нужно сделать для того, чтобы при делегировании домена регистратор мог проверить их работоспособность.
Разбирать настройку сервера BIND (named) мы будем на примере домена vega.ru, который охватывает сеть класса С (194.226.43.0/24). При этом master сервер зоны мы разместим в этой же IP-сети, а поповоду slave сервера мы заключим соответствующее соглашение с администрацией сервера ns.relarn.ru.
Согласно правилам регистрации доменов второго уровня, как минимум, два сервера доменных имен авторитативных для зоны vega.ru нам необходимо иметь. При чем серверы должны подключаться к Интернет независимо.
