 |
|
|
|
Управляем зонами DNS
Управляем зонами DNS Сформировать файлы, необходимые для создания собственной зоны DNS, – это еще не все. Необходимо настроить и запустить программу BIND, зарегистрировать доменное имя, дождаться завершения тестов – и можно раздавать друзьям адреса mymail@shortdomain.com! Настройка BIND Программа BIND очень богата на параметры конфигурационного файла. Даже простое их перечисление может занять не один лист. Здесь я приведу собственный рабочий конфигурационный файл, слегка измененный к придуманной нами задаче, которая рассматривалась в предыдущей статье «Создаем зоны DNS» (№6 за 2006 г.). Полное руководство по настройке BIND распространяется вместе с дистрибутивом, а также доступно в [1]. Конфигурационный файл BIND – named.conf. Каталог /etc/namedb во FreeBSD обычно содержит этот файл, заполненный настройками по умолчанию, файл named.root, в котором перечисляются «хорошо известные» корневые сервера (этот файл вы можете загрузить с [2]) и шаблон файла обратной локальной зоны PROTO.localhost.rev, на основе которого создается файл localhost.rev. Настройки named.conf В качестве знака комментария используется символ «//», как в программах на С++. Допустимо также использование знака «#», как в скриптах на /bin/sh. Порядок задания параметров произвольный. Первыми идут настройки, относящиеся к системному журналу (syslog). BIND очень богат на опции настройки хранения информации в syslog, перенаправлять ее можно как угодно. В приведенном ниже примере создается канал передачи сообщений (channel) такой, что все сообщения направляются в syslog с facility local7 и severity info. После описания канала задаются категории, указывающие, какие сообщения куда следует направлять. В этом случае все просто, все направляется в один и тот же файл, хотя ничто не помешало бы нам создать несколько каналов и разбросать сообщения между ними. logging { channel named_log { syslog local7; severity info; }; category default { named_log; default_debug; }; category general { named_log; default_debug; }; category unmatched {named_log; default_debug; }; }; После настроек системного журнала идут настройки, управляющие контролем доступа. Они нам понадобятся, чтобы разделить клиентов, запрашивающих информацию, и указать, кто какие зоны будет просматривать. acl me-white { 212.20.5.0/24; }; acl grayteeth { 10.87.1.0/24; }; Клиенты, обращающиеся с адресов, удовлетворяющих этим ACL, будут считаться «внутренними» и получать доступ к «внутренней» зоне. Все прочие же клиенты будут считаться «внешними» и получать доступ только к «внешней» зоне. Создаем внутренние зоны. Для начала определим, кто имеет право получать данные из внутренних зон и то, что для запроса от внутреннего клиента сервер является рекурсивным, то есть не будет в ответ отдавать ссылки на другие сервера (DNS NXDOMAIN), а обязан вернуть ответ на запрос – успешный или неуспешный. view "internal" { match-clients { grayteeth; me-white;}; recursion yes; Определяем специальную зону «подсказок». Эта зона содержит список «хорошо известных» серверов, с которых начинается поиск адреса, если его еще нет в кэше. Фактически, мы описываем весь Интернет этой зоной. zone "." { type hint; file "named.root"; }; Определяем обратную зону для 127.0.0.1. Для данной зоны сервер является основным (master), не отсылает извещения об обновлении, блокирует любые попытки обновить или запросить трансфер зоны. Если для зоны не указаны allow-query, allow-update или allow-transfer, то применяются установки представления (внешнего или внутреннего), попадание в представление означает получение доступа. Таким образом, не задавая allow-transfer, мы оставляем возможность запустить трансфер зоны. Хотя для данной зоны это не страшно – просто бесполезная операция. zone "0.0.127.IN-ADDR.ARPA" { type master; notify no; file "localhost.rev"; allow-update { none; }; allow-transfer { none; }; }; Определяем основную зону прямого преобразования. Для этой зоны сервер является основным, блокирует любые попытки обновления зоны, разрешает запрос из зоны только клиентам, удовлетворяющим перечисленным ACL. zone "krokodil.ru" { type master; file "direct-krokodil-ru.int"; allow-update { none; }; allow-query { me-white; grayteeth; }; }; Определяем основную зону обратного преобразования и завершаем внутреннюю часть. Для этой зоны сервер является основным, блокирует любые попытки обновления зоны, разрешает запрос из зоны только клиентам, удовлетворяющим перечисленным ACL. zone "2.87.10.in-addr.arpa" { type master; file "zone10.rev"; allow-update { none; }; allow-query { me-white; grayteeth; }; }; }; Создаем внешние зоны. Поскольку просмотр ACL идет по схеме «first win», то есть используется первое совпадение, то все клиенты, которые не могут быть отнесены к внутренним, автоматически попадут во внешние, следовательно, нет необходимости в специальном описании ACL. Для запроса от внешнего клиента сервер является нерекурсивным, то есть в ответе может содержаться не только положительный или отрицательный результат, но и ссылка на другой сервер (DNS NXDOMAIN). В нашем случае это не имеет значения, но могло бы понадобиться, если бы мы определяли подзоны (например, end.tail.krokodil.ru потребует отдельной зоны tail.krokodil.ru, которая может администрироваться другим человеком, и соответственно наш сервер должен отсылать клиента к серверу зоны tail.krokodil.ru). view "external" { match-clients { any; }; recursion no; Определяем основную зону прямого преобразования. Для этой зоны сервер является основным и полностью блокирует любые обновления. zone "krokodil.ru" { type master; file "direct-ru.ext"; allow-update { none; }; }; Определяем основную зону обратного преобразования. Для этой зоны сервер является основным и полностью блокирует любые обновления. Определение этой зоны не нужно, если провайдер предоставляет блок адресов размером менее сети класса С. zone "5.20.212.in-addr.arpa" { type master; file "zone212.rev"; allow-update { none; }; }; }; Здесь мы рассмотрели только основные параметры для описания зон. Множество других параметров – опции настройки клиентской части («резолвера»), настройки канала управления RNDC – остались в стороне, поскольку они непосредственно не связаны с настройкой зон, хотя достаточно существенны для работы локальных программ и сопровождения. Запуск и сопровождение Для запуска named достаточно добавить named_enable="YES" в /etc/rc.conf. По умолчанию в нынешних версиях рабочий каталог named делается с рассчетом на jail, и поэтому вынесен в /var/named, где уже созданы подкаталоги /dev, /etc и /var, а /etc/namedb является символическим линком на /var/named/etc/namedb. Меня это не устроило, и я расположил рабочий каталог в более привычном месте – /etc/namedb. Для этого в /etc/rc.conf пришлось добавить строки: named_flags="-c /etc/namedb/named.conf -4 -u bind" named_chrootdir="" Параметр -4 отключает поддержку Ipv6 (когда она еще будет), параметр -u bind задает сброс привилегий после запуска до пользователя bind. Последняя строка нужна для /etc/rc.d/named, чтобы он не пытался создать /var/named/etc/namedb. Если вас устраивает расположение рабочего каталога по умолчанию, то достаточно строки: named_flags="-4 -u bind" После запуска все сообщения должны направляться по тем маршрутам, настройки которых были заданы в named.conf. Если это файлы системного журнала, то они должны быть созданы заранее и syslogd оповещен о произошедших изменениях, иначе сообщения будут пропадать. Если после запуска named он не стартует и в соответствующий журнал ничего не записывается, просмотрите другие журналы, например, /var/log/daemon или другой файл, в который направляются сообщения с facility daemon и severity info, а также сообщения, выводимые на консоль. Если же named успешно открыл канал передачи информации, все данные уже будут направляться в соответствии с настройками. Перед тем как подавать заявку на регистрацию зоны, запустите named, убедитесь, что он работает, настроив на него компьютеры внутренней сети. Также вы можете использовать команды dig, host и dnswalk для проверки работоспособности зоны. Команда dnswalk – это небольшой скрипт на языке Perl, который с помощью несложной модификации можно превратить в средство для закачки полных зон. Устанавливается он из ports/dns/dnswalk и требует достаточно большого количества разнообразных дополнительных модулей – p5-Digest-HMAC-1.01, p5-Digest-SHA1-2.11, p5-Net-DNS-0.57, p5-Net-IP-1.24. Для того чтобы закачивать зоны (на самом деле dnswalk это делает и так, но не сохраняет копию), следует наложить патч: # diff -ub dnswalk.old dnswalk --- dnswalk.old Fri May 12 18:47:16 2006 +++ dnswalk Mon Apr 24 19:55:00 2006 @@ -93,6 +93,11 @@ } @subdoms=undef; foreach $rr (@zone) { + +# Inspired by Shelton to save zone file + $rr->print; +# To here + if ($rr->type eq "NS") { $subdom = $rr->name; $subdom =~ tr/A-Z/a-z/; Средства для тестирования зон описаны в RFC 1713. В нём упоминаются все те же host, dig и dnswalk, а также другие программы, например DDT (Domain Debug Tools). Все программы, упомянутые в RFC, можно найти на [7]. После того, как сервер заработает, можно подавать заявку регистратору. При регистрации в РУЦЕНТРе нужно будет заполнить форму, в которой указать реквизиты организации и контактные адреса. Все поля, информация из которых будет в открытом доступе, имеют специальную пометку. Внимательно читайте подсказки веб-интерфейса, предоставляемые РУЦЕНТРом, – не все поля можно изменять через веб-интерфейс! Впрочем, те поля, которые изменить нельзя, и не имеют в нем возможностей для замены. Network Solutions имеет менее удобный интерфейс – при регистрации он просит зарегистрировать одну персону, контактные адреса которой и будут «по умолчанию» подставлены во все необходимые поля при регистрации домена. Это довольно неудобно, к тому же веб-интерфейс Network Solutions гораздо менее очевиден, чем веб-интерфейс РУЦЕНТРа. В нем можно разобраться, но для того, чтобы, например, добавить еще одну персону и перевести на нее какие-то контакты, придется изрядно повозиться. РУЦЕНТР начинает тестирование через 4 часа после принятия заявки при условии, что на лицевом счету достаточно средств для ее исполнения, иначе заявка будет «поставлена в очередь» и тестирование начнется через 4 часа после поступления денег. После тестирования зоны вы получите информационное сообщение, в котором будет указан результат тестирования. Если тестирование прошло неудачно, то в сообщении будет приведена причина ошибки. Если при регистрации был указан почтовый адрес в новом домене (в нашем случае, например, admin@krokodil.ru), то проверьте еще и работоспособность локального почтового сервера и тот факт, что он принимает почту для домена krokodil.ru, в противном случае подтверждения можно и не дождаться. После регистрации домена вы получите другое подтверждающее сообщение. Также вы получите отдельное сообщение, если была заказана услуга вторичного сервера DNS. Оплата услуг производится на год, когда срок оплаты будет подходить к концу, все регистраторы начинают присылать сообщения с напоминаниями о том, что срок регистрации заканчивается и нужно оплатить следующий срок. Все регистраторы используют концепцию «персон» для установления лиц, которые отвечают за своевременное внесение изменений в информацию о своих зонах, а также получают извещения, например о том, что срок оплаты заканчивается. «Персона» – это набор анкетных данных, сообщаемых при регистрации. Как правило, сюда входят телефон и адрес электронной почты. Именно по указываемым здесь адресам и рассылается информация. После регистрации «персоне» присваивается handle (заголовок), который может быть указан на сайте регистратора в качестве Administrative (административного) или Technical (технического) контакта. Указанные контакты будут получать соответствующую информацию – administrative – об окончании срока оплаты и т. д., Technical – об ошибке получения свежей версии зоны и т. д. Кроме того, по обоим адресам будет рассылаться информация общего характера, например, об изменениях в правилах регстрации доменов. РУЦЕНТР не требует регистрации «персоны» – информация о том, куда сообщать, вводится в анкете. Network Solutions в любом случае создаст, как минимум, одну «персону» и пропишет ее во все необходимые места, RIPE требует создания «персоны» в обязательном порядке. Даже в случае неоплаты следующего срока РУЦЕНТР не освобождает домен день в день. Сначала сервер постоянно, примерно дней за 5 до окончания срока, каждый день шлет напоминания о необходимости оплатить услуги по продлению регистрации домена. Если же оплата так и не была внесена, то доступ к DNS-серверу блокируется, но еще месяц имя не освобождается. Если в этот момент оплатить продление регистрации, то имя не пропадает. Через месяц после того, как оплата была просрочена, имя освобождается и переводится в «аукцион доменов». «Аукцион» – это нововведение РУЦЕНТРа – если вы хотите зарегистрировать на себя какое-либо популярное доменное имя и оно вдруг становится доступным для регистрации, то оно будет разыграно на аукционе. Имя держится на аукционе год, после чего снимается. Whois Whois – вспомогательный информационный сервис, очень тесно связанный с DNS, поскольку с его помощью определяется, например, занято в настоящий момент доменное имя или свободно. Описывается он RFC 954. Задача этого сервиса – поиск информации о запрошенном имени на указанном сервере. Любой регистратор, как правило, предоставляет возможность вам воспользоваться этим сервисом, чтобы выполнить поиск информации о каком-либо домене, сети или персоне. Такой поиск выполняется неявно, когда вы указываете имя домена, которое хотите зарегистрировать. В зависимости от сервера, вам могут либо сообщить, что доменное имя занято, либо предложат зарегистрировать имя в другом TLD. Whois отображает только информацию, которая находится в открытом доступе. При обращении к разным серверам информация может выглядеть по-разному. Например, Network Solutions вставляет в выдаваемую информацию большой рекламный заголовок. Самый простой путь получения информации через whois – воспользоваться соответствующим сервисом, например в РУЦЕНТРе [8]. Для тех же, кто предпочитает командную строку, существует команда whois. Для ее использования требуется разблокированный на брандмауэре порт 43. Существует также простенькая X-версия команды xwhois, требующая Glib. Несмотря на то что обратиться за информацией whois можно к большому количеству регистраторов, которые перечислены в man whois, практическое значение для нас имеют только некоторые из них. За информацией об именах в зонах .com, .org, .net, .edu, .biz и прочих функциональных зон – в Network Solutions [9]. Вывод будет иметь следующий вид (рекламный заголовок опущен): # whois -i freebsd.org
За информацией об именах в зонах .ru, .su – в РУЦЕНТР [8]. Вывод будет иметь совершенно другой вид: # whois -c ru samag.ru
За информацией о регистрации сетей, обратных зон и выяснения принадлежности IP – в RIPE [3]. Вывод будет иметь следующий вид: # whois -r 212.20.5.0/24
Несмотря на то что данная информация уже устарела, она все еще присутствует в RIPE. Можно запросить информацию о персоне, указав ее handle для данного сервера (напоминаю, что каждый регистратор имеет свои собственные handles): # whois -r RNA1-RIPE
DNS считается одной из самых сложных тем при организации сети. И это вовсе неспроста – для понимания его работы требуется многое. Хотя такая относительно простая задача, как создание небольшой зоны, содержащей только ссылки на внешний веб- и почтовый серверы, вполне по силам большинству администраторов. Надеюсь, что прочитав эту статью, вы тоже сможете ее решить.
|
Рашид Ачилов| Комментарии |
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
