Файлы базы данных DNS

Главные (Master) файлы, поставляемые с named, подобно named.hosts, всегда имеют домен, связанный с ними, называемый origin. Это имя домена, указанное с параметрами cache и primary. Внутри главного файла Вы можете определить домен и связанные с ним имена файлов. Имя, заданное в файле конфигурации, рассматривается абсолютно (absolute), если оно заканчивается одной точкой, иначе оно рассматривается относительно origin. Можно и прямо сослаться на origin знаком (@).

Данные, содержащиеся в главном файле, разделены на записи ресурсов (resource records, RRs). RRs самые маленькие модули информации, доступные через DNS. Каждая запись ресурса имеет тип. Например, A-записи отображают имя хоста на IP-адрес, а CNAME-записи связывают псевдоним для хоста с его официальным именем. Пример 6-11 показывает главный файл named.hosts для Virtual Brewery.

Записи ресурсов в главных файлах совместно используют общий формат:

[domain] [ttl] [class] type rdata

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

domain

Задает имя домена, к которому относится запись. Если никакое имя не задано, RR применяется к домену предыдущей RR.

ttl

Чтобы сервер имен обновлял информацию, RR ограничен по времени работы (ttl). Это поле определяет время в секундах, которое информация имеет силу после того, как была получена с сервера. Это десятичное число из восьми цифр.

Если значение ttl не дано, ему присваивается значение поля minimum предыдущей SOA-записи.

class

Класс адреса, например, IN для адресов IP или HS для объектов в Hesiod-классе. Для TCP/IP Вы должны определить IN.

Если никакое поле класса не задано, берется класс предшествующей RR.

type

Описывает тип RR. Наиболее часто встречаются типы A, SOA, PTR и NS. Следующие разделы описывают различные типы RR.

rdata

Хранит данные, связанные с RR. Формат этого поля зависит от типа RR. Дальше это будет описано для каждого RR отдельно.

Дальше приведен частичный список RR, которые нужно использовать в файлах DNS.

SOA

Описывает зону авторитета (SOA или "Start of Authority"). Эта запись сообщает о том, что записи после SOA RR содержат авторитетную информацию для домена. Каждый главный файл, включенный в инструкцию primary, должен содержать SOA-запись для этой зоны. Данные ресурса содержат следующие поля:

origin

Это каноническое имя хоста основного сервера для этого домена. Обычно задается как абсолютное имя.

contact

Это e-mail адрес человека, ответственного за поддержание домена, со знаком "@" замененным на точки. Например, если ответственный в Virtual Brewery janet, это поле содержит janet.vbrew.com.

serial

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

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

refresh

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

retry

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

expire

Определяет время в секундах, после которого сервер должен отбросить все зональные данные, если невозможно было войти в контакт с основным сервером. Этот промежуток времени должен быть очень большим. Craig Hunt рекомендует 42 дня.

minimum

Задает по умолчанию значение ttl для исходных записей, которые точно не определяют его. Требует другого сервера, чтобы отбросить RR при проверки после определенного времени.

Ничего нельзя сделать со временем, после которого вторичный сервер попробует модифицировать зональную информацию. Значение minimum должно быть большим, особенно для LAN, где сетевая топология почти никогда не меняется. В случае, когда единственные RR могут часто изменяться, Вы можете приписывать им различные ttl.

A

Ассоциирует IP-адрес с именем. Содержит адрес в dotted quad notation. Для каждого хоста должна быть только одна запись. Hostname, используемый в этой А-записи, считается служебным или каноническим hostname. Все другие hostname расцениваются как псевдонимы и должны быть отображены на канонический (canonical) hostname, используя запись CNAME. Если каноническое имя нашего хоста vlager, его и надо вписать в A-запись с его IP-адресом. Если мы связываем с этим адресом другое имя, например news, надо использовать запись CNAME, которая свяжет его с альтернативным именем.

NS

Указывает на главный (primary) сервер подчиненной зоны. Содержит hostname сервера.

Вы встретите записи NS в двух ситуациях:

Когда Вы делегируете авторитет зависимой зоне.

Внутри главной зональной базы данных зависимой зоны.

Наборы серверов в родительских и делегированных зонах должны соответствовать друг другу, иначе опознание имен работать не будет.

Запись NS определяет имена первичного и вторичного серверов для зоны. Эти имена должны быть разрешимы к используемому адресу. Иногда серверы не принадлежат к обслуживаемому домену, что порождает проблему: нельзя обратиться к серверу, пока не получен его адрес, но получить адрес нельзя, пока не обратимся к серверу (неоткуда). Можно конфигурировать специальные записи непосредственно на сервере имен родительской зоны. Они позволяют серверу из родительской области преобразовывать IP-адрес делегированного зонального сервера. Эти записи обычно названы приклеенными записями (glue records), поскольку они "склеивают" делегированную зону с родительской.

CNAME

Ассоциирует псевдоним хоста с его каноническим hostname. Каноническиий hostname указан в файле, который обеспечивает А-запись, а псевдонимы просто связаны с этим именем CNAME-записью, но не имеют собственных записей.

PTR

Этот тип записи используется, для того, чтобы соединить имена домена in-addr.arpa с именами хостов (hostnames). Это используется для обратного отображения IP-адресов к hostnames. Данное имя должно быть каноническим.

MX

Эта RR объявляет преобразователь почты (mail exchanger) для домена. Для чего надо иметь преобразователи почты, рассказано в главе 17 . Синтаксис MX-записи следующий:

[domain] [ttl] [class] MX preference host

Имя host объявляет преобразователь почты для домена domain. Каждый преобразователь почты имеет целое число preference , связанное с ним. Агент транспортировки почты, желающий доставить почту в домен, будет перебирать все хосты, не имеющие MX-записей в этом домене, пока все не пройдет успешно. Сначала будет проверяться тот хост, у которого самое низкое число, а затем все хосты по возрастанию числа.

HINFO

Эта запись предоставляет информацию относительно аппаратных средств системы и программного обеспечения. Синтаксис этой записи:

[domain] [ttl] [class] HINFO hardware software

Поле hardware идентифицирует аппаратные средства, используемые этим хостом. Имеются специальные соглашения, чтобы точно определить их. Список подходящих имен дан в "Assigned Numbers" (RFС 1340). Если область содержит пробелы, то ее содержимое надо заключить в двойные кавычки. Имена областей

software используются операционной системой. Подходящее имя может быть выбрано из "Assigned Numbers" RFC.

Запись HINFO для Intel Linux-машин может выглядеть примерно так: tao 36500 IN HINFO IBM-PC LINUX2.2

А для Linux-машины на процессоре Motorola 68000 так: cevad 36500 IN HINFO ATARI-104ST LINUX2.0 jedd 36500 IN HINFO AMIGA-3000 LINUX2.0

Содержание раздела