Файлы зон


На http://alpha-logistics.ru/negabaritnye-perevozki/ нагабаритные перевозки по России.

Итак, у нас есть конфигурационный файл, который сообщает демону named(8), за какие домены тот отвечает и где расположены файлы с информацией об этих доменах. Но сами эти файлы еще надо создать!

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

Чтобы изучить работу с файлами зон, ознакомьтесь с представленными примерами. И обнаружив, что скребете затылок, вспомните, что продираетесь сквозь болото первобытного Интернета. Если бы DNS был изобретен сегодня, файлы зон наверняка выглядели бы совсем иначе.*

Ниже представлен пример файла обратной зоны для хоста localhost с IP-адресом 127.0.0.1. Давайте исследуем этот файл. Прежде всего, вспомним, что все строки, начинающиеся с точки с запятой, представляют собой комментарии. Тщательно комментируйте файлы зон; впоследствии эта информация поможет вспомнить, почему настройка выполнялась так, а не иначе.

Инструкция $TTL (1) задает время жизни зоны (в секундах). Это значение определяет, как долго другие серверы будут кэшировать информацию об этой зоне. Данная инструкция позволяет задать любое время жизни зоны по своему усмотрению. 3600 секунд (1 час) — это не очень много. Хорошее среднее значение — 10 800 секунд (3 часа). Выбор TTL сродни черной магии; значение по умолчанию подойдет в большинстве случаев.

Следующая запись — Start of Authority (SOA, начало авторитетности). В ней представлено краткое описание зоны — каково ее поведение и как серверам следует себя с ней вести. У каждой зоны есть только одна запись SOA. В нее входит не информация о домене, а лишь сведения о продолжительности ее хранения.

Символ @ (2), с которого начинается SOA-запись, — это специальное сокращение для «зоны, указанной в named.conf». В данном случае named.conf сообщает, что в этом файле хранятся данные для зоны 0.0.127.in-addr.arpa. Когда named считывает named.conf и загружает его содержимое в память, он выполняет такую замену. Фактическое доменное имя было бы более понятным для новичков, однако это препятствовало бы возможности определять несколько зон в одном файле. Вместо символа @ можно применять полное доменное имя, но почти никто так не поступает.

IN представляет тип данных (3) — данные Интернета. SOA (4) означает запись Start of Authority. Оба элемента присутствуют в каждом создаваемом файле зоны.

Следующая часть — имя машины (5), на которой находится мастер-файл. Этот файл создан на test.blackhelicopters.org.

Далее следует адрес электронной почты (6) человека, ответственного за эту зону. Сценарий make-localhost по умолчанию задает адрес учетной записи root на локальной машине. В нем отсутствует символ @, потому что он соответствует названию зоны, указанному в named.conf.* Если оставить @ в адресе электронной почты, то адрес превратился бы в root0.0.127.in-addr.arpa.test.blackhelicopters.org, что не только плохо смотрится, но и является ошибкой. Первую точку в адресе электронной почты следует рассматривать как заменитель символа @.

В большинстве случаев на сервере имен нет почтового сервера. Согласно установившейся в Интернете практике, в поле электронного адреса поставьте имя пользователя учетной записи администратора и свое доменное имя, например hostmaster@absolutefreebsd.com. Предполагается, что у каждого домена есть электронный адрес администратора, предназначенный для ответа на вопросы, связанные с DNS.

Обратите внимание на круглые скобки в начале и в конце записи SOA. Формально запись SOA должна располагаться в одной строке. Однако тогда ее было бы трудно читать. Поэтому в стандартных файлах зон эта запись разбита на несколько строк. Открывающая круглая скобка указывает на обрыв строки. Каждая строка до закрывающей круглой скобки считается частью записи SOA. Традиционно круглые скобки включают в себя набор таймеров и порядковый номер (7).

Первое число — это порядковый номер (serial number), который обозначает версию файла зоны. Всякий раз, когда вы редактируете файл, увеличивайте и порядковый номер. Порядковый номер может быть любым, однако удобнее всего применять дату. Обычно она записывается в формате YYYYMMDD с двумя дополнительными цифрами в конце. Порядковый номер 20061203 в листинге означает 3 декабря 2006 года. Две дополнительные цифры сообщают, сколько раз файл изменялся в течение дня. Мне случалось обновлять информацию о домене до десяти раз в день.

Предположим, я создаю файл зоны 9 мая 2008 года и задаю порядковый номер 2008050901. Если я изменю файл зоны 8 июня, порядковый номер изменится на 2008060801. Если я изменю файл зоны второй раз в этот же день, порядковый номер будет 2008060802. Такая система допускает до 100 изменений в день — примерно одно изменение каждые 15 минут. Если окажется, что этого недостаточно, то надо переосмыслить рабочий процесс.

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

Следующее число — значение интервала обновления (refresh) в секундах. Это число определяет, как часто вторичные серверы связываются с первичным и проверяют, не обновился ли мастер-файл. В этом примере файла localhost.rev вторичный сервер имен будет обращаться за обновленным мастер-файлом каждые 3600 секунд (1 час).

Порядочная проблема

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

Если вторичный сервер не может сравнить свои данные с данными на первичном сервере, в ответ на запросы он выдает текущую информацию из файла зоны — в конце концов, для этого и предназначен резервный сервер! Данный механизм будет подробно рассмотрен в разделе «Refresh, retry и expire на практике» этой главы.

Значение retry (повторная попытка) определяет, как часто вторичный сервер должен выполнять попытки связаться с первичным сервером в случае его недостижимости. В данном примере этот интервал составляет 900 секунд (15 минут). Если вторичный сервер имен не сможет обновить свои данные через час, он будет пытаться сделать это каждые 15 минут, пока первичный сервер имен не отзовется.

Значение expire (истечение срока действия) определяет, когда вторичный сервер должен уничтожить записи в кэше. По мнению администратора, в данных обстоятельствах наличие недействительной информации хуже ее отсутствия. В нашем примере период времени составляет 3 600 000 секунд (1000 часов, или чуть более 41 дня).

Последнее число — минимальное время жизни (minimum time-to-live). В старых реализациях BIND это значение определяло время жизни буквально всей информации. Сейчас оно означает только TTL для отрицательных ответов. Например, если вы ищете givememymoneyback.absolutefreebsd.com, ваш сервер имен узнает, что такого хоста не существует. В результате он будет «помнить» об этом факте в течение времени, равного минимальному времени жизни. Не забудьте поставить закрывающую круглую скобку после значения времени жизни, в противном случае named предположит, что остаток файла также представляет собой часть SOA-записи, и не только будет сбит с толку, но и поведет себя весьма агрессивно.

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

Каждая строка состоит из четырех частей: имя хоста или число, тип данных, тип сервера и фактические данные. Первое поле может быть пустым либо содержать имя хоста (например, www) или число (например, 12). Имя зоны автоматически присоединяется в начало либо в конец этой записи в зависимости от того, для чего предназначен этот файл — для обратного или прямого DNS, соответственно. Поскольку наш пример предназначен для обратного DNS, цифра 1 (1) добавляется к 127.0.0. В результате получается IP-адрес 127.0.0.1.

Если в первом поле ничего нет, named так или иначе добавит имя зоны. В результате получится разумное значение по умолчанию. Например, первое поле строки NS, представленной в примере, ничем не заполнено, поэтому named считает, что это зона 0.0.127.in-addr.arpa или сеть, начинающаяся с 127.0.0, то есть домен, указанный для этого файла в named.conf.

Тип данных DNS — всегда IN (Интернет).

Третье поле (тип сервера) особенно интересно. NS-запись (2) представляет сервер имен. В нашем примере единственным сервером имен для данного домена является test.blackhelicopters.org. Если вы размещаете localhost.rev на нескольких серверах имен, в них надо добавить дополнительные строки NS. С другой стороны, PTR-запись (3) представляет отображение IP-адреса в имя хоста. Эта зона — для сети 127.0.0., а хост .1 в данной сети — это localhost.blackhelicopters.org.

Refresh, Retry и Expire на практике

Уже говорилось о том, что означают параметры Refresh, Retry и Expire, — теперь мы посмотрим, как они работают, на примере.

Допустим, у нас есть домен с периодом Refresh, равным 4 часам, периодом Retry, равным 1 часу, и периодом Expire, равным 48 часам. Это означает, что вторичный сервер имен связывается с первичным каждые четыре часа и проверяет наличие обновлений. Время от времени вы редактируете записи на первичном сервере имен, и в течение ближайших четырех часов они передаются на вторичный сервер. Пока что все хорошо. Теперь предположим, что первичный сервер имен взорвался, и осколки его жесткого диска разлетелись по всей округе. Что произойдет со вторичным сервером и с клиентами, которым необходима информация о домене?

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

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

Если вторичный сервер не сможет подтвердить свои данные в течение периода Expire, информация о домене будет признана устаревшей и ненужной. В этом случае вторичный сервер сотрет у себя всю информацию о домене и будет возвращать ошибку в ответ на любой запрос об этом домене. Домен исчезнет из Сети.

Действия в случае аварий DNS

Если с вашим первичным сервером имен и в самом деле произойдет катастрофа, у вас есть время, равное сумме значений Expire и Retry, чтобы заменить данный сервер или переконфигурировать вторичный сервер, сделав его первичным.

Пример реальной зоны

Файл локальной зоны отчасти надуман — он представляет только одну машину с одним IP-адресом. Однако он удобен, его можно найти на любом сервере имен, а данные, содержащиеся в нем, либо широко используются, либо совершенно необходимы. Теперь рассмотрим файл зоны, который более полно представляет домены, находящиеся на обслуживании, — файл зоны для домена absolutefreebsd.com.

Данный файл похож на файл localhost.rev, обсуждавшийся выше, однако это файл реально существующей зоны для настоящего домена Интернета. Посмотрим, что в нем есть. Во-первых, есть время жизни (1). Его значение равно одному часу — когда сервер имен получает информацию для этого домена, он хранит ее один час. SOA-запись (2) содержит контактную информацию и значения времени Refresh, Retry и Expire, а также порядковый номер.

В файле зоны перечислены два сервера имен: bewilderbeast.blackhelicopters.org и tribble.lodden.com (3). Согласно значениям времени в файле зоны, tribble.lodden.com, будет сравнивать свои записи с записями bewilderbeast.blackhelicopters.org каждый день. Если попытка сравнить записи завершится неудачей, то сравнение будет осуществляться каждые 2 часа. Если tribble.lodden.com не может сравнить свои записи с записями первичного сервера в течение 1000 часов, он перестает отвечать на запросы о домене absolutefreebsd.com. Наконец, удаленные серверы имен будут кэшировать ответы «нет такого хоста» в течение двух дней.

Обратите внимание: устаревшие версии серверов DNS могли принимать значения времени только в секундах. Теперь вместо числа 86400 для определения интервала длительностью в одни сутки можно использовать значение 1d. Интервалы в секундах до сих пор можно встретить в старых файлах зон, но в наше время заниматься такими математическими вычислениями — совершенно лишнее.

Почтовый ретранслятор

Далее представлен новый тип записи, MX (4) — почтовый ретранслятор (mail exchanger) домена. Хотя у домена есть только один первичный почтовый хост, у него может быть несколько резервных почтовых серверов. Тем не менее почта должна обязательно дойти до основного почтового хоста. В этих записях указываются предпочтительный почтовый и резервные серверы. Эта тема подробно обсуждается в главе 16.

Дополнительное поле в записи MX — это приоритет (preference), числа 10 и 20. Серверы с меньшим приоритетом считаются более предпочтительными. В нашем случае сервер bewilderbeast.blackhelicopters.org с приоритетом 10 является предпочтительным почтовым сервером для absolutefreebsd.com. Если первичный сервер недоступен, mail.nobletechnology.net выступит в качестве резервного сервера.

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

Записи о хостах

Наконец, у нас есть записи о каждом хосте в домене. Наиболее часто используются записи о хостах двух типов: CNAME и А. Мы уже говорили при рассмотрении программы dig(1), что CNAME — это псевдоним (точнее, ссылка на каноническое имя). Запись А (5) указывает IP-адрес. В нашем примере программа dig(1) покажет, что хост absolutefreebsd.com — это псевдоним для www.absolutefreebsd.com. (Напомню, что в отсутствие явно указанного имени запись по умолчанию относится к домену, представленному этим файлом!) Хост www.absolutefreebsd.com имеет IP-адрес (6) 198.22.63.8.

Почтовые ретрансляторы и серверы имен нельзя определять записями типа CNAME; для них следует указывать фактические имена хостов.

Точки, окончание и файлы зон

Демон named(8) предполагает, что все имена хостов в файле зоны являются частью этой зоны. В файле зоны для absolutefreebsd.com нельзя указать имя www.absolutefreebsd.com; named уже знает, что речь идет о домене absolutefreebsd.com, поэтому достаточно просто указать www., a named(8) добавит имя зоны к имени каждого хоста, если явно не указать обратное. Это довольно удобно, за исключением случаев, когда хост не является частью домена. Например, ни один из серверов имен, обслуживающих домен absolutefreebsd.com, не входит в этот домен. Я ведь не хочу, чтобы мой первичный сервер имен отображался как bewilderbeast.blackhelicopters.org.absolutefreebsd.com.

Вы уже видели, что при создании зон в SOA-записях символ точки может подставляться вместо символа @ в адресах электронной почты. Однако точки также играют роль символов окончания для имен хостов. Если после имени хоста добавить символ точки, демон named(8) будет считать, что все имена хостов являются частью зоны, для которой предназначен этот файл. Как видно из предыдущих примеров, каждое полное имя хоста, расположенное после записи SOA, заканчивается точкой. Даже в записи CNAME имя хоста www.ahsolutefreebsd.com заканчивается точкой. Если бы точка отсутствовала, то этот псевдоним относился бы к хосту www.absolutefreebsd.com.absolutefreebsd.com. Я бы не хотел вводить такое имя в адресной строке веб-броузера, чтобы получить нужную мне веб-страницу! (Замечу, что наличие такой вещи, как фактическое имя хоста, фанаты DNS находят забавным. Вспомните об этом, прежде чем превратиться в такого фаната.)

Обратные зоны DNS

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

Я настоятельно рекомендую использовать сценарий mkrdns для автоматизации администрирования обратных зон DNS. Это позволит сэкономить время и уменьшит число ошибок. Сценарий mkrdns написан на языке Perl, поэтому он настолько прост, что для него даже не требуется отдельный «порт». Поищите сценарий mkrdns в какой-нибудь поисковой системе, загрузите его и положите в каталог /usr/local/bin.

Чтобы сценарий mkrdns смог создать файл обратных зон, у вас уже должен иметься файл зоны. Этой зоне должна соответствовать корректная запись типа SOA, не обязательно содержащая информацию о хостах, mkrdns использует SOA-запись в качестве шаблона при создании файла обратной зоны. Сценарий запускают так:

# mkrdns /etc/namedb/named.conf

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

Комментарии запрещены.