 |
|
|
|
Создаем и управляем зонами DNS. Часть 1
Создаём зоны DNS Domain Name System – своеобразная «нервная система» сети Интернет. Именно благодаря ей вы, набирая http://www.samag.ru, попадаете на сайт журнала «Системный администратор», а не куда-нибудь еще. Как создать, настроить и запустить DNS-сервер для небольшого предприятия? Структура DNS В настоящее время Интернет – это огромная сеть, в которую входят миллионы узлов, расположенных по всему миру. Для того чтобы запрос, сделанный с одного компьютера, мог достичь цели, расположенной на другом компьютере, нужно прежде всего эту цель задать. Можно, конечно, указать IP-адрес напрямую. Если он вам известен, конечно. Но здесь существует возможность очень просто ошибиться – информация о том, где находится нужный вам адрес уже могла измениться, и в лучшем случае вы увидите сообщение о том, что адрес не найден, а в худшем – окажетесь на сайте, совершенно не имеющем никакого отношения к тому, что было нужно. Надежней и проще будет обратиться к системе, которая хранит соответствие между символическими именами типа www.samag.ru и IP-адресам, соответствующими им в данный момент (в нашем случае 217.144.98.99). DNS и является такой системой. Поскольку от ее успешного функционирования зависит работа всей сети Интернет, эта система функционирует по принципу распределенной базы данных – есть «хорошо известные» серверы, числом 13, их еще называют «корневыми» (root servers), содержащие информацию о серверах, содержащих информацию о серверах и т. д. Как дом, который построил Джек. Вся сеть Интернет, которая описывается зоной «.» (точка) делится на так называемые TLD (Top Level Domains – домены верхнего уровня), распределяемые либо по функциональному, либо по географическому признаку. Существует также термин primary domain – «первичный домен», или «домен первого уровня», но этот термин используется значительно реже. Распределение по географическому признаку осуществляется в соответствии с ISO 3166, устанавливающему для всех стран мира двух- и трехбуквенные коды. Распределение по функциональному признаку осуществляется по мере необходимости создания нового TLD. Здесь следует отметить, что всеми вопросами по отношению к TLD занимается ICANN (Internet Corporation for Assigned Names and Numbers), и именно этот орган решает – создавать ли новый TLD. Корневые сервера сами по себе содержат только ссылки на сервера, содержащие информацию о зонах второго уровня, которые в свою очередь содержат информацию о серверах, содержащих информацию о зонах третьего уровня и т. д. В большинстве случаев иерархия исчерпывается на третьей-четвертой зоне. Но не потому, что здесь заложено какое-то ограничение. Просто запоминать сложные имена ничуть не проще IP-адресов. Таким образом, процесс поиска информации, допустим, о веб-сервере www.granch.ru, будет выглядеть следующим образом:
Данный процесс проиллюстрирован на рис. 1, где цифры обозначают последовательность запросов.
Рисунок 1. Процесс поиска информации Как встроить свою информацию в структуру DNS? Прежде чем включаться в какую-либо систему, нужно иметь некоторое представление о том, куда и каким образом включаться. Куда встраиваем? За различные TLD отвечают различные сервера, и если за географические домены отвечает, как правило, один сервер (точнее говоря, одна организация), то за домены функциональные может отвечать, вообще говоря, неограниченное количество так называемых регистраторов, то есть компаний, заключивших специальные договоры с ICANN о том, что именно они будут регистрировать имена в некоторых функциональных доменах. Краткое описание функционального домена и адрес его регистратора приведены в [3]. Если регистраторов несколько, то дается адрес основного (например, VeriSign [4] для домена .com). Домены .gov и .mil зарезервированы исключительно за американским правительством и американскими же военными организациями, причем резервирование .gov оформлено соответствующим RFC – RFC 2146 [5]. Полный список всех существующих в настоящий момент географических же TLD с указанием регистратора домена и необходимой контактной информации можно посмотреть в [6]. Хотя если, скажем, в зоне .com можно выбирать из огромного списка, то для зон .ru и .su РУЦЕНТР, [8], без вариантов. Здесь надо отметить несколько моментов. Фактически зона .su относится к несуществующему государству Советский Союз (Soviet Union), хотя тем не менее продолжает обслуживаться и открыта для регистрации. Регистрация там достаточно дорогая – 100 долларов за регистрацию или поддержку в год. Не существует никакого приоритета, согласно которому одна организация или человек имеет преимущество при регистрации домена над другим. Один американский бизнесмен, занимавшийся производством пластиковых окон, зарегистрировал домен windows2000.com. Когда то же самое попыталась сделать Microsoft, она с удивлением обнаружила, что это имя уже занято, и за него компании пришлось выложить крупную сумму. Существует даже понятие «киберсквоттерство» – процесс регистрации доменов с целью их последующей перепродажи. РУЦЕНТР тоже решил приложить к этому руку, и по новым правилам, которые вводятся с 1 июня 2006 года, освобождающиеся домены выставляются на «аукцион доменных имен» и передаются тому, кто даст больше. Имена удерживаются на «аукционе» в течение года, если за этот срок никто на него не претендует, имя выводится в свободную регистрацию. При создании TLD, перечисленных выше, планировалось также создание TLD .xxx для сайтов с тематикой «для взрослых». ICANN отклонила это предложение. Недавно оно было вынесено на повторное голосование, и ICANN снова его отклонила [7]. Зато появился TLD .tel [9], рассчитанный на использование одновременно в компьютерах и мобильных устройствах. Существует RFC 1480, описывающий правила регистрации имен в домене .us. Правила эти чрезвычайно громоздки и запутанны и предполагают создание имен из 6-7 уровней типа Hamilton.High.LA-Unified.K12.CA.US Каким образом встраиваем? Раньше все было гораздо сложнее. Для регистрации зоны .com мне пришлось заполнять множество текстовых форм – с данными на организацию, с данными на контактных лиц... Формы эти потом отсылались на специальные адреса, откуда приходили ответы – приняты или нет. Затем предварительно сформированный файл зоны тестировался, и опять же по почте приходило сообщение о том, успешно завершено тестирование или нет. Сейчас все стало гораздо проще. И Network Solutions, и РУЦЕНТР обзавелись веб-интерфейсами, с помощью которых все вышеперечисленное (за исключением, конечно, составления файла зоны) можно сделать несколькими кликами мыши. Все данные можно исправить, дополнить или удалить в любой момент. Ранее с РУЦЕНТРом требовалось заключать договор на обслуживание, но начиная с 1 июня 2006 года в действие вводятся новые правила, согласно которым достаточно зарегистрироваться на их сайте. Зарубежные регистраторы, как правило, обходятся кредитными картами, но если домен по какой-либо причине не может быть зарегистрирован, деньги будут возвращены не ранее чем через три дня. Регистратору потребуется указать IP-адрес и маску подсети сервера, на котором будет запущена программа DNS-сервера, и который будет содержать основную базу данных, создаваемую и редактируемую вами по мере необходимости. Этот сервер будет называться первичным сервером (master server). Кроме того, потребуется указать как минимум один IPадрес сервера, содержащего резервную копию базы на случай отказа первичного сервера. Такие серверы называют вторичными серверами (slave servers). Чтобы долго не размышлять о том, где разместить вторичный DNS, РУЦЕНТР предлагает разместить его на их площадке. Стоимость услуг РУЦЕНТРа составляет 15 долларов в год за домен в зонах .ru, .net, .com, .org, 50 долларов за домен в зонах .biz, .info, 100 долларов за домен в зоне .su и 5 долларов в год за поддержку вторичного DNS в любой (в том числе и зарегистрированной не у них) зоне. Почему требование к наличию вторичного DNS-сервера является обязательным? Поскольку стабильность работы DNS крайне важна для стабильности работы сети Интернет в целом, то лицо или организация, регистрирующая домен, обязана удовлетворять некоторым условиям, касающимся стабильности работы DNS:
Каких-либо требований к размещению серверов по новым правилам не выдвигается, хотя ранее требовалось наличие их в разных IP-сетях. www.krokodil.ru Итак, допустим, мы хотим создать сайт www.krokodil.ru (на момент написания статьи это имя было свободно), посвященный разведению крокодилов в домашних условиях. Подключение по выделенной линии есть, сеть класса С, а именно 212.20.5.0 – 212.20.5.255 (этот диапазон в настоящее время свободен) провайдером выделена. Этот пример несколько нехарактерен для нынешнего времени с его дефицитом IP-адресов, но он взят специально для того, чтобы рассмотреть создание обратной зоны. Также будет рассмотрен вариант с подключением через сеть 212.20.5.0/31. Внутренняя сеть нашей крокодиловодческой конторы состоит из шести компьютеров и будет отделена от Интернет firewall-proxy и т. д. под управлением FreeBSD. Что нам понадобится для осуществления задуманного? Прежде всего отмечу, что существуют варианты, не предполагающие какого-либо знания DNS – все размещается на площадке провайдера, все обслуживается провайдером, вам предоставляется только веб-интерфейс. Эта услуга чрезвычайно популярна за рубежом, но очень слабо востребована в России. Ее описание выходит за рамки данной статьи, поэтому рассматривать ее я не буду. Во-первых, нам понадобится программа DNS-сервера. На сегодняшний день только одна программа реализует требуемый набор функций. Это DNS-сервер BIND, распространяемый ISC (Internet System Consortium Inc., [10]) – некоммерческой организацией, которая занимается разработкой серверов BIND, DHCP, INN и NTP. Если он отсутствует в вашей системе, его необходимо скачать и установить. FreeBSD поставляется вместе с BIND 9.3.2, поэтому в данной статье будет рассматриваться именно эта версия. Следует отметить, что для версий BIND 8.x приводимое ниже описание конфигурации совершенно неприемлемо, поскольку формат конфигурационных файлов BIND 8.x коренным образом отличается от формата конфигурационных файлов BIND 9.x. Во-вторых, понадобится распределить выделенные нам IP-адреса и наделить адресами внутренние компьютеры. Здесь все чрезвычайно просто: пусть 212.20.5.1 – шлюз провайдера, 212.20.5.2 – адрес UNIX- сервера, 10.87.1.0/24 – внутренняя подсеть, в которой с 1-й по 6-й – рабочие станции, 254 – адрес внутреннего интерфейса сервера. Остальные адреса будут зарезервированы для будущего расширения. В-третьих, потребуется заранее подготовленный файл описания зоны, который будет определять небольшое количество внешних адресов: krokodil.ru – корневой сервер зоны, www.krokodil.ru, ftp.krokodil.ru, mail.krokodil.ru и ns.krokodil.ru. Имя ns (nameserver) является практически традиционным наименованием компьютеров, на которых работает служба DNS, хотя, конечно, никто не помешает вам назвать его, например jaws.krokodil.ru. Будут определены также имена для компьютеров внутренней сети, доступные только изнутри: tooth1.krokodil.ru – tooth6.krokodil.ru. Записи DNS Существует достаточно большое количество типов разнообразных записей, которые можно помещать в DNS. Обьем данной статьи позволяет рассмотреть лишь наиболее важные из них, для получения полной информации следует обратиться к соответствующим RFC: RFC 1033 и RFC 1035 определяют форматы основных записей, RFC 1122 – формат записи PTR, RFC 2782 – формат записи SRV. Мы рассмотрим только те записи, которые понадобятся для формирования файлов зон, необходимых для регистрации домена:
Формат записей DNS общий для всех типов записей: [имя] [ttl] [класс] <тип> <данные> где:
Имя может принимать любое значение, и в таком случае оно считается именем обьекта. Если имя заканчивается на точку, то оно считается полностью определенным, иначе в конец имени подставляется имя зоны, которое может быть задано двумя способами:
$ORIGIN krokodil.ru
Специальный символ «@» обозначает текущее имя зоны. Имейте в виду, что директива $ORIGIN отменяет директиву zone и действует до появления следующей директивы $ORIGIN или до конца файла. До момента появления первой директивы $ORIGIN она считается заданной значению директивы zone конфигурационного файла BIND. Если имя задано, оно должно начинаться с первой позиции строки. TTL обычно опускается и задается глобально директивой $TTL. Директива $TTL для BIND 9.x является обязательной и, как правило, задается в самом начале файла. В поле данных этой директивы задается время жизни (в секундах) элемента, в течение которого он может находиться в кэше и считаться достоверным. В данном примере это двое суток (48 часов). $TTL 172800 Класс записи может принимать одно из следующих значений:
Тип записи – один из типов, перечисленных выше. Следует обратить внимание на то, что поля имя, ttl и класс могут быть опущены. При этом в качестве их значений принимается последнее определенное значение (при этом задание @ будет корректным определением), а если значение не было определено нигде, то для поля класс принимается значение по умолчанию «IN», для других полей – приводит к сообщению об ошибке. Кроме записей, в файле зоны могут быть команды. Всего команд четыре – $TTL, $ORIGIN, $INCLUDE и $GENERATE. Описание команды $GENERATE приведено в документации на программу BIND, а также в [13] и [14], команда $INCLUDE работает соответственно своему написанию – включает указанный файл в текущий файл. $INCLUDE /etc/namedb/krokodil-ru-int.soa Примечание: знак «;» (точка с запятой) является признаком комментария. Запись SOA Эта запись определяет начало зоны. Любая зона должна начинаться с записи SOA. Появление другой записи SOA автоматически заканчивает первую зону и начинает вторую. Формат записи SOA приведен ниже. Фактически запись SOA именует зону и задает для нее некоторые умолчания. @ IN SOA krokodil.ru. hostmaster.krokodil.ru. ( 2005122001 ; Serial number 10800 ; Refresh every 3 hours 3600 ; Retry every hour 1728000 ; Expire every 20 days 172800 ) ; Minimum 2 days Разберем пример. Знак @ в поле имени означает, что необходимо взять имя зоны, заданное ранее директивой $ORIGIN. Класс записи – IN, тип записи – SOA. SOA – это единственная запись, которая имеет такой сложный список параметров. Первый параметр – это адрес главного сервера имен зоны. В данном примере это krokodil.ru. Второй параметр – адрес электронной почты лица, ответственного за данную зону. Обратите внимание, что адрес записан как «username.domain», а не «username@domain». Второй параметр – это список значений, заключенный в скобки. Теоретически возможно его записать в одну строку, но практически я нигде этого не видел, всюду употребляется форма записи, приведенная в примере. Список состоит из пяти элементов:
Запись NS Эта запись задает имена серверов, поддерживающих зону, т.е. ведущих ее базу. Здесь должны быть перечислены имена первичного и всех вторичных серверов. Обычно эта запись следует непосредственно за записью SOA. В поле данные заносится одно значение – имя или IP-адрес сервера DNS-зоны независимо от того, является ли он главным или подчиненным. Все указанные здесь имена должны быть полностью определенными, то есть заканчиваться точкой! IN NS ns.krokodil.ru. IN NS ns4.nic.ru. В приведенном примере описывается сначала главный сервер нашей зоны ns.krokodil.ru, а потом подчиненный сервер – узел РУЦЕНТРа ns4.nic.ru. Запись A Запись типа A – это основное содержимое файлов зоны прямого преобразования или же просто «прямой» зоны, то есть выдающей имя компьютера по его адресу. Она составляется для каждого компьютера. Для удобства чтения эти записи обычно группируются в порядке возрастания IPадресов, а также группируются с записями MX, соответствующими данному IP-адресу, хотя это, конечно, не является обязательным. В поле имя заносится имя, назначаемое IP-адресу, в поле данные – IP адрес, которому назначается имя. При наличии у адреса дополнительных имен, имя, назначенное адресу записью типа A, называют основным именем. tooth1 IN A 10.87.1.1 tooth2 IN A 10.87.1.2 tooth3 IN A 10.87.1.3 tooth4 IN A 10.87.1.4 tooth5 IN A 10.87.1.5 tooth6 IN A 10.87.1.6 В данном примере описано назначение IP-адресов компьютерам внутренней сети, которая имеет адрес 10.87.1.0/24. Для компьютеров внутренней сети, как правило, нет необходимости формирования каких-либо дополнительных записей, за исключением разве что CNAME. Запись CNAME Запись типа CNAME – это дополнительная возможность DNS. Она позволяет назначить одному IP-адресу более одного имени. В поле имя заносится дополнительное имя, назначаемое IP-адресу, в поле данные – основное имя, назначенное ранее записью типа A, или другое дополнительное имя, назначенное записью CNAME. При этом имя, стоящее в поле данных записи, называют каноническим (отсюда и название записи – Canonical Name). Одному IP-адресу можно назначить неограниченное количество дополнительных имен посредством записей CNAME, но в записях другого типа должно быть указано имя, назначенное записью A, а не записью CNAME. Ниже приводится пример правильного и неправильного назначения дополнительных имен. Правильно: ns IN A 10.87.1.1 name1 IN CNAME ns IN MX 10 ns Неправильно: ns IN A 10.87.1.254 name1 IN CNAME ns IN MX 10 name1 Записи CNAME могут указывать одна на другую, но не более семи уровней, восьмой обязательно должна идти запись, указывающая на имя, назначенное записью типа A. В литературе встречается рекомендация использовать множественные записи типа A вместо назначения адресу множества дополнительных имен. По поводу этого можно сказать, что данный момент упоминается в RFC 2219 в плане «не существует абсолютных рекомендаций по этому поводу, каждый должен решать для себя, что для него лучше». Множественные CNAME проще для администрирования, множественные A-записи легче обрабатываются, поскольку происходит меньше перенаправлений. Запись MX Запись типа MX – это второй основной элемент файла зоны. Эта запись расшифровывается как «Mail eXchanger», и предназначена для указания IP-адресов или имен компьютеров, которые принимают почту для узла, описанного в поле name. В этом поле может быть пусто, а также указано полностью или не полностью определенное имя. Если в поле name пусто или указано не полностью определенное имя, то имя дополняется из директивы $ORIGIN. Формирование записей MX в сложных случаях, когда настраивается достаточно большая зона с разветвленной схемой приема почты, – весьма нетривиальная задача, которая тесно переплетается с работой программ, использующих протокол SMTP для доставки почты, поэтому мы рассмотрим только наиболее простой случай – вся почта принимается сервером UNIX. В поле данные заносятся два значения – приоритет и имя или IP-адрес компьютера, принимающего почту, направляемую на данный компьютер. С одним IP-адресом может быть связано, вообще говоря, неограниченное количество записей типа MX, и все они должны иметь разный приоритет. Почта направляется в соответствии с приоритетом – почтовый агент сортирует записи в порядке нарастания приоритетов и именно так предпринимает попытки доставить почту. Предположим, мы договорились с админом узла behemot.ru о том, что сможем использовать его сервер как транзитный узел, который будет получать нашу почту с целью последующей доставки ее адресатам, когда связь восстановится. Тогда описание сервера krokodil.ru будет выглядеть следующим образом: krokodil.ru. IN A 212.20.5.2 IN MX 10 krokodil.ru. IN MX 50 behemot.ru. www IN CNAME krokodil.ru. mail IN CNAME krokodil.ru. ftp IN CNAME krokodil.ru. Это комплексный пример, он сразу показывает использование записей MX, А и CNAME. Здесь мы:
Запись PTR Это совершенно особый тип записей. В нашем примере мы «специально» взяли полную подсеть, чтобы рассмотреть случай «нормальной» работы с записями PTR. Случай с сетью 212.20.5.0/31 будет рассмотрен чуть позже. Запись PTR предназначена для осуществления обратного преобразования – имен в IP-адреса. Подобные преобразования очень широко применяются в различных программах, предоставляющих доступ к некоторым сетевым ресурсам: они проверяют соответствие прямого и обратного преобразования и в случае несовпадения или отсутствия записи PTR могут отказать в доступе. Зона, содержащая записи PTR, называется зоной обратного преобразования или же просто «обратной» зоной. Записи PTR не имеют никакого отношения к записям A, MX, CNAME и другим, описывающим прямое преобразование. Сделано это намеренно с целью использовать для обоих преобразований один и тот же набор программных модулей. Здесь, правда, нас ожидает сложность следующего вида – полностью определенное доменное имя вида www.krokodil.ru. «наращивает размерность» слева направо (то есть укрупнение узлов идет по мере продвижения по тексту имени слева направо), а IP-адрес 212.20.5.2 – справа налево. Для унификации программных модулей приняли следующую условность: все IP-адреса – это имена, входящие в специальный TLD in-addr.arpa. «Зонами» в этом домене являются подсети, а имя зоны записывается в виде IP-адреса, читаемого наоборот. Таким образом «имя» нашей обратной зоны будет 5.20.212.in-addr.arpa для обратной зоны, содержащей описание для внешней сети и 1.87.10.in-addr.arpa для обратной зоны, содержащей описание внутренней сети. Точно так же, как для использования доменного имени необходимо его зарегистрировать, так и для использования обратного преобразования необходимо зарегистрировать обратную «зону» у координатора обратных зон. В отличие от зон прямого преобразования здесь существует только один координатор, и регистрация у него бесплатная. Регистрацией обратных зон занимается RIPE NCC [11]. Вся информация о регистрации обратной зоны приведена в [12]. Зачем нужно регистрировать обратную зону? Сервер верхнего уровня зоны in-addr.arpa должен знать, что для выполнения запроса обратного преобразования ему следует обратиться к такому-то серверу, в данном случае к нашему 212.20.5.2. Разумеется, где-либо регистрировать обратную зону внутренней подсети не нужно. Сама запись PTR выглядит очень просто – в поле имя заносится последняя часть IP-адреса, в поле данные – полностью определенное имя прямого преобразования. Обращаю внимание на последнее – имя, заносимое в поле данных, должно быть полностью определенным, поскольку записи PTR сами задают связь между IP-адресом и именем, они не могут получить ниоткуда информацию о том, к какой зоне следует отнести не полностью квалифицированное имя прямого преобразования. $ORIGIN 1.87.10.in-addr.arpa 1 IN PTR tooth1.krokodil.ru. 2 IN PTR tooth2.krokodil.ru. 3 IN PTR tooth3.krokodil.ru. 4 IN PTR tooth4.krokodil.ru. 5 IN PTR tooth5.krokodil.ru. 6 IN PTR tooth6.krokodil.ru. В приведенном выше примере мы задали обратное преобразование для компьютеров внутренней сети. Для сервера мы запишем одну строчку (в реальном примере директивы $ORIGIN указывать не надо, они приведены только, чтобы было понятно, о какой зоне идет речь): $ORIGIN 5.20.212.in-addr.arpa 2 IN PTR krokodil.ru Здесь необходимо отметить, что записи CNAME для задания множественного обратного соответствия не используются, поэтому при запросе «какое имя соответствует адресу 212.20.5.2» результатом всегда будет krokodil.ru независимо от количества установленных для него псевдонимов. Чем будет отличаться случай, когда провайдер выделяет блок 212.20.5.0/31 вместо полноценной подсети? С точки зрения формирования всех записей, кроме PTR, ничем. Процедура создания прямой зоны и ее регистрации не зависит от количества адресов, тем более что для большинства случаев много адресов и не надо. Однако с точки зрения записей PTR разница есть. В сторону упрощения. А может быть, и нет – в зависимости от провайдера. И заключается она в том, что записи: gate.krokodil.ru. IN A 212.20.5.1 krokodil.ru. IN A 212.20.5.2 будут находиться на вашем сервере и управляться вами, но записи: 1 IN PTR gate.krokodil.ru. 2 IN PTR krokodil.ru. должны быть сформированы провайдером, потому что возможность самому регистрировать обратную зону и самому ей управлять предоставляется только при наличии сети класса не менее С. Это, с одной стороны, облегчает работу – не нужно регистрироваться в RIPE, но с другой стороны, осложняет – для внесения изменений в именование сервера нужно каждый раз связываться с провайдером. Файловая структура Самому BIND, конечно же, все равно, в каком порядке идут записи и как они отформатированы. Это важно только тем, кто будет сопровождать зону, особенно, если изменения в нее будут вноситься часто. Здесь я опишу распределение зон по файлам так, как это используется в тех зонах, которые я сопровождаю. Разумеется, это не единственный возможный порядок и, возможно, не лучший. Но это работает. Зоны внешние и внутренние BIND 8.x имел один чрезвычайно крупный недостаток – он не позволял дифференцировать выдаваемую информацию в зависимости от каких-либо факторов – приходилось либо показывать лишнее, либо скрывать нужное. Внешним клиентам совершенно нет никакой необходимости знать о наличии компьютеров внутренней сети, но, поскольку разделить информацию не было возможности, любой компьютер мог установить структуру внутренней сети посредством запросов DNS. BIND 9.x свободен от этого недостатка – он позволяет посредством списков управления доступом (Access Control List, АСL) распределить запросы по «представлениям» (views). Представления могут иметь произвольные имена, обычно создается внутреннее представление «internal», которому удовлетворяют клиенты внутренней подсети, и внешнее представление «extrenal», которому удовлетворяют все остальные. Здесь помните, что это одна и та же зона, просто показывается она по-разному – как правило, в файлах внешних зон присутствует только та информация, которая необходима внешним клиентам, – о внешнем сервере, о путях доставки почты и т. д., а в файлах внутренних зон отражается вся сетевая топология. Кроме того, если сопровождается обратная зона, то необходимо точно так же разделить по файлам информацию об адресах обратного преобразования. Итак, вернемся к нашему примеру. Файловая структура будет следующей. У нас имеется прямая зона krokodil.ru и обратная зона 5.20.212.in-addr.arpa. Кроме того, обязательно должна присутствовать обратная зона зона 0.0.127.in-addr.arpa для обеспечения корректного обратного преобразования localhost 127.0.0.1. Зона эта нужна для того, чтобы BIND не пытался запрашивать корневые сервера о самом себе, что происходит, когда 127.0.0.1 указывает на «localhost.» Запись прямого преобразования 127.0.0.1 localhost.krokodil.ru будет занесена в файл прямого преобразования внутренней зоны. Для того чтобы не загружать сеть передачей бесполезных данных, для внешних и внутренних зон используются разные записи SOA – записи во внешних зонах меняются весьма редко, а во внутренних довольно часто. Следовательно, мы имеем следующие файлы:
Несмотря на обширный список, файлы достаточно короткие, поэтому приводятся здесь полностью, за исключением комментариев. Сделаем одно замечание относительно имени localhost. RFC 1912 специально упоминает настройку файлов c разрешением имени 127.0.0.1 и localhost. В нашем примере зона localhost соответствует RFC 1912, хотя в жизни вполне можно встретить разрешение имени 127.0.0.1 localhost.domain.tld и соответствующее ему обратное разрешение. Файл localhost.rev. Использует одну запись SOA вместе с внутренней зоной обратного преобразования: $INCLUDE /etc/namedb/krokodil-ru-int.soa 1 IN PTR localhost. Файл zone212.rev: $INCLUDE /etc/namedb/krokodil-ru-ext.soa 1 IN PTR gate.krokodil.ru. 2 IN PTR krokodil.ru. Файл zone10.rev: $INCLUDE /etc/namedb/krokodil-ru-int.soa 1 IN PTR tooth1.krokodil.ru. 2 IN PTR tooth2.krokodil.ru. 3 IN PTR tooth3.krokodil.ru. 4 IN PTR tooth4.krokodil.ru. 5 IN PTR tooth5.krokodil.ru. 6 IN PTR tooth6.krokodil.ru. Файл direct-krokodil-ru.int: $INCLUDE /etc/namedb/krokodil-ru-int.soa krokodil.ru. IN A 10.87.1.254 IN MX 10 krokodil.ru. www IN CNAME krokodil.ru. mail IN CNAME krokodil.ru. proxy IN CNAME krokodil.ru. ftp IN CNAME krokodil.ru. ns IN CNAME krokodil.ru. localhost. IN A 127.0.0.1 tooth1 IN A 10.87.1.1 tooth2 IN A 10.87.1.2 tooth3 IN A 10.87.1.3 tooth4 IN A 10.87.1.4 tooth5 IN A 10.87.1.5 tooth6 IN A 10.87.1.6 Файл direct-krokodil-ru.ext: $INCLUDE /etc/namedb/krokodil-ru-ext.soa krokodil.ru. IN A 212.20.5.2 IN MX 10 krokodil.ru. IN MX 50 behemot.ru. www IN CNAME krokodil.ru. mail IN CNAME krokodil.ru. ftp IN CNAME krokodil.ru. gate IN A 212.20.5.1 Файл krokodil-ru-int.soa: @ IN SOA krokodil.ru. hostmaster.krokodil.ru. ( 2006051202 ; Serial number 10800 ; Refresh every 3 hours 3600 ; Retry every hour 1728000 ; Expire every 20 days 172800 ); Minimum 2 days ; IN NS krokodil.ru. Файл krokodil-ru-ext.soa: $TTL 172800 @ IN SOA korkodil.ru. hostmaster.krokodil.ru. ( 2005122001 ; Serial number 10800 ; Refresh every 3 hours 3600 ; Retry every hour 1728000 ; Expire every 20 days 172800 ); Minimum 2 days ; IN NS krokodil.ru. IN NS ns4.nic.ru. Заключение Как создать, настроить и запустить DNS-сервер для небольшого предприятия? На самом деле не так сложно, как кажется изначально, – достаточно пройти этот путь один раз, дальнейшие действия будут идти «на автомате». Приложение Домены верхнего уровня Первоначально, согласно RFC 920, в списке функциональных TLD присутствовали только .com, .gov, .mil, .edu, .org [1], которые представляли соответственно коммерческие, правительственные, военные организации, образовательные учреждения и некоммерческие организации. Впоследствии этот список несколько расширился – в 1985 г. добавился TLD .net, представляющий организации-поставщики сетевых услуг, а в 1988 – TLD .int, представляющий международные организации. В 2001-2002 к этому списку добавились практические неизвестные российскому пользователю TLD .aero, .biz, .cat, .coop, .jobs, .mobi, .museum, .name, .pro и .travel. Более подробная информация приведена в [2]. Географические же домены распределены раз и навсегда. Хотя это не значит, что вы не можете зарегистрировать в нем свой домен. Многие географические домены, случайно совпавшие с «хорошо известными» сокращениями, являются чрезвычайно привлекательными. Например, .md (Молдавия) очень привлекательна для медицинских учреждений и жителей штата Мэриленд, США; .tv (Тувалу) – для сайтов, связанных с телевидением; .tm (Туркменистан) совпадает с написанием сокращения «Trade Mark», а .nu (Ниуэ – есть такой остров-колония) – для сайтов в стиле «ню». Ссылки и литература:
|
Рашид Ачилов
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
