Родерик Смит - Сетевые средства Linux
В различных конфигурационных файлах BIND точка с запятой интерпретируется по-разному: в файле named.conf ею заканчивается выражение, а в файле зоны она определяет комментарии. Это следует учитывать при редактировании конфигурационных файлов BIND, в противном случае сервер будет работать некорректно.
Конфигурационный файл зоны обычно помещается в каталог /var/named, и ему присваивается имя, связанное с именем зоны. Обычно для такого файла выбирается имя db.имя-зоны или named.имя-зоны. Конфигурационному файлу можно присвоить любое имя, необходимо лишь, чтобы оно совпадало с именем, указанным в /etc/named.conf.
Формирование описания зоны
Для описания зоны используется запись SOA (Start of Authority — начало полномочий). В поле, определяющем тип записи, указано значение SOA. Наличие этой записи означает, что сервер имен поддерживает данный домен. В поле имени указывается имя зоны, совпадающее с именем, заданным в файле /etc/named.conf (не забывайте о завершающей точке!). Содержимое записи в данном случае состоит из трех частей.
• Ведущий сервер имен. Первое имя (в листинге 18.2 это spruce.threeroomco.com.) представляет имя ведущего сервера имен для зоны. В листинге 18.2 за этим именем следует обратная косая черта (). Как и во многих конфигурационных файлах, этот символ означает, что продолжение записи находится на следующей строке. Часто в конфигурационных файлах зоны две строки объединяются в одну, и в этом случае обратная косая черта не нужна.
• Почтовый адрес администратора. Второе имя (в листинге 18.2 это admin.threeroomco.com.) определяет почтовый адрес администратора, отвечающего за поддержку зоны. Этот адрес представляется в несколько необычном формате. Чтобы его можно было использовать, надо заменить первую точку на символ @, так, адрес admin.threeroomco.com. будет преобразован в [email protected]
• Временные соотношения. Числовые значения, помещенные в скобки и располагающиеся в последующих строках, задают информацию о временных соотношениях. В листинге 18.2 приведены комментарии, поясняющие назначение соответствующих чисел. В строке, помеченной комментариями serial, содержится последовательный номер, который необходимо увеличивать при каждом редактировании файла. Ведомый сервер на основании данного значения определяет, следует ли обновлять свой конфигурационный файл. Многие администраторы задают последовательный номер как дату (в формате YYYYMMDD), сопровождая ее номером изменений, произведенных в течение текущего дня. В строке refresh задается время в секундах между обращениями ведомого сервера к ведущему. Значение 3600, приведенное в листинге 18.2, соответствует одному часу, следовательно, ведомый сервер будет каждый час проверять, не изменились ли параметры зоны на ведущем сервере. Значение retry представляет время в секундах, по истечении которого ведомый сервер предпримет повторную попытку обращения к ведущему серверу в случае, если первая попытка окажется неудачной. Значение expire также определяет время в секундах, в течение которого запись считается действительной, если ведомому серверу не удается связаться с ведущим. По истечении указанного времени запись не может быть использована для преобразования имен. Величина expire обычно соответствует одной неделе и, конечно же, должна превышать значение refresh. Значение default_ttl задает время жизни. В течение этого времени сервер DNS должен хранить информацию о результатах преобразования. Обычно величина времени жизни составляет от одного дня (86400 в листинге до одной недели (604800). Если IP-адреса вашей сети часто изменяются или если вы предполагаете, что вскоре придется произвести много изменений, имеет смысл задать время жизни порядка часа.
Определение адресов и имен
Большинство записей в конфигурационном файле зоны предоставляет информацию о соответствии между именами и IP-адресами. В поле имени, как правило, задается имя компьютера либо другое имя, связанное с IP-адресом. В поле имени также можно задавать символ @, заменяющий имя домена. Данный символ обычно используют в записях MX и NS (листинг 18.2). Эти записи не несут информации о взаимосвязи имен и адресов, а определяют специальные имена для всего домена.
Ниже описаны основные типы записей.
• А. В записи A (address — адрес) в поле имени задается имя узла, а содержимое записи представляет собой IP-адрес. В качестве имени узла можно использовать полное доменное имя (с завершающей точкой), например gingko.threeroomco.com., либо имя узла без указания имени домена, например birch или spruce. Можно также в качестве имени компьютера указать имя домена, так, например, в листинге 18.2 задано соответствие между именем threeroomco.com. и IP-адресом 192.168.1.4.
• CNAME. Запись CNAME (canonical name — каноническое имя) ставит в соответствие имени другое имя. В поле содержимого может быть указано либо полное доменное имя с завершающей точкой, либо имя узла без имени домена. Если вы задаете полное доменное имя, оно не обязательно должно принадлежать домену, определяемому посредством файла зоны. Например, в листинге 18.2 имя kelp связывается с компьютером в другом домене. Записи CNAME обычно применяются в тех случаях, когда важные IP-адреса могут изменяться без вашего участия. Например, если вы размещаете Web-страницу на внешнем компьютере, то можете связать имя www с именем этой машины. Если адрес внешнего компьютера изменится, ваша запись останется корректной.
• PTR. В листинге 18.2 записи типа PTR отсутствуют. Эти записи применяются для обратного преобразования и будут рассматриваться ниже.
• NS. Запись NS (name server — сервер имен) задает сервер имен для домена. В конфигурационном файле должна присутствовать хотя бы одна запись NS, указывающая на компьютер, заданный в качестве ведущего сервера имен в записи SOA. В поле имени данной записи указывается либо имя домена, либо символ @. IP-адрес компьютера, содержащего сервер имен, задается с помощью записи А.
• MX. Запись MX (mail exchanger — обмен почтой) предоставляет информацию о почтовом сервере для зоны. В поле имени этой записи указывается символ @ либо имя домена. В поле содержимого записи содержатся два компонента: код приоритета и имя узла. Когда удаленный почтовый сервер собирается передать сообщение пользователю в домене (например, [email protected]), он запрашивает у сервера имен записи MX. Затем уделенный сервер пытается связаться с компьютером, для которого указано наименьшее значение приоритета (в листинге 18.2 это birch.threeroomco.com.). Если этот компьютер не доступен, удаленный сервер предпринимает попытку установить соединение с тем узлом, приоритет которого выражается следующим по величине значением (в листинге 18.2 это mail.pangaea.edu.). Перебор компьютеров продолжается до тех пор, пока сообщение не будет доставлено либо пока не выяснится, что все узлы, указанные в записях MX, не доступны. Очевидно, что компьютер, имя которого задано в записи MX, должен быть настроен для приема почты. Вопросы передачи почтовых сообщений будут рассматриваться в главе 19.
СоветНекоторые типы записей указывают на компьютеры, расположенные за пределами домена. Так, например, вы можете задать в качестве почтового сервера узел внешней сети.
В листинге 18.2 приведены примеры многих из перечисленных выше записей. В реальном конфигурационном файле зоны содержится информация о гораздо большем количестве компьютеров.
Конфигурация зоны для обратного преобразования
В листинге указано несколько зон, некоторые из них предназначены для обратного преобразования. Эти зоны позволяют серверу DNS определять доменное имя по IP-адресу. Для того чтобы это стало возможным, необходимо создать псевдодомен in-addr.arpa. В файле /etc/named.conf содержатся указатели на конфигурационные файлы, описывающие подмножества этого домена. Поскольку имя домена уточняется при движении справа налево, а IP-адрес уточняется по мере движения слева направо, в имени псевдодомена адрес должен быть указан в обратном порядке. Например, имя зоны для диапазона адресов 192.168.1.0/24 будет иметь вид 1.168.192.in-addr.arpa.
Зона для обратного преобразования, или обратная зона, настраивается подобно зоне прямого преобразования. Конфигурационный файл зоны содержит записи SOA и NS, но основное место в нем занимают записи PTR. При обратном преобразовании не возникает необходимость в записях MX, А и CNAME. В листинге 18.3 содержится конфигурационный файл обратной зоны, соответствующий файлу, приведенному в листинге 18.2.
