База данных доменной системы имен DNS для каждого домена представляет собой набор текстовых файлов, которые системный администратор ведет на основном сервере имен этого домена. Элементы базы данных называются записями о ресурсах; иногда их сокращенно обозначают PR. Типы и форматы записей о ресурсах регламентируются документами RFC882, 1035 и 1183.

Базовый формат записи о ресурсах:

[имя] [время] [класс] тип данные

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

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

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

В поле класс задается тип сети. Распознаются три значения: IN (Internet), СН (ChaosNet), HS (Hesiod). ChaosNet - устаревшая сеть, в которой раньше работали Lisp-машины фирмы Symbolics. Hesiod - это служба базы данных, являющаяся надстройкой системы BIND; пока она используется не слишком широко, но постепенно завоевывает популярность как замена NIS. Значением класса по умолчанию является IN.

Существуют записи трех различных типов:

• зонные записи: определяют домены и их серверы имен;
• базовые записи: преобразовывают имена в адреса и наоборот, обеспечивают маршрутизацию почты;
• факультативные записи: содержат дополнительную информацию о машинах.

Содержимое поля данные зависит от типа записи. Типы записей перечислены в табл. 4.

Записи HINFO не используется по соображениям безопасности.

Записи WKS не используется по соображениям производительности.

Существуют и другие типы записей, которые широко не используются.

Запись SOA отмечает начало зоны - группы записей о ресурсах, расположенных в одной области пространства имен DNS. Домен DNS обычно соответствует минимум двум зонам; одна служит для преобразования имен машин в IP-адреса, а остальные - для обратного преобразования.

Для каждой зоны делается всего одна запись SOA; зона продолжается до тех пор, пока не появляется следующая запись SOA. Запись SOA содержит имя зоны, адреса, необходимые для установления технических контактов, различные значения тайм-аутов. Эта запись должна быть первой записью зоны. Например:

;; AUTHORITY RECORDS:

ccl.ru. color=#ffffff 3600 IN SOA ns.ccl.ru. hostmaster.perm.ru. (

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

Поле время отсутствует. Класс - IN (Internet), тип - SOA , а остальные элементы составляют поле данные.

Сервер ns.ccl.ru - основной сервер имен этой зоны.

Запись hostmaster.perm.ru. указывает адрес электронной почты для технических контактов в формате пользователь. машина, (а не пользователь@машина ). Если Вам необходимо отправить почту администратору домена, просто замените первую точку знаком @ и уберите последнюю точку.

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

Последовательные номера не обязательно должны быть непрерывными, но должны монотонно возрастать. Если Вы случайно задали на основном сервере очень большое число и оно передается вспомогательным серверам, то исправить порядковый номер на основном сервере не удастся. Вспомогательные серверы будут запрашивать новые данные только в том случае, если порядковый номер записи SOA основного сервера больше порядковых номеров записей, хранимых вспомогательными серверами (Формальное ограничение на величину порядкового номера только одно: число справа от десятичной точки должно быть меньше 9999.).

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

Первый элемент - тайм-аут регенерации, refresh. Он показывает, как часто вспомогательные серверы должны сверяться с основным сервером и смотреть, не изменился ли порядковый номер конфигурации зоны. Если зона изменилась, вспомогательные серверы должны создать новый экземпляр данных зоны. Общепринятые значения для данного тайм-аута - от одного до шести часов (3600 - 21600 секунд).

Если вспомогательный сервер пытается проверить порядковый номер основного, а тот не отвечает, вспомогательный сервер сделает повторную попытку по истечении периода времени, заданного тайм-аутом retry. Опыт показывает, что нормальное значение для данного параметра - от 20 до 60 минут (1200 - 3600 секунд).

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

Параметр minimum задает время жизни записей о ресурсах, которое будет приниматься по умолчанию. Он кэшируется вместе с записями и используется для отмены их действия на неавторитетных серверах. Каждая запись может в поле время содержать явно заданное значение; если такое значение не установлено, то используется значение из записи SOA. Опыт показывает, что следует брать значения от нескольких часов до нескольких дней. Увеличение значения этого параметра приблизительно до недели существенно снижает интенсивность сетевого графика и нагрузку на доменную систему имен.

Записи NS описывают серверы, которые авторитетны для данной зоны. Обычно эти записи следуют за записью SOA. Запись NS имеет следующий формат:

зона [время] [класс] NS имя_машины

Например:

ccl.ru color=#ffffff 3600 IN NS ns.ccl.ru
ccl.ru color=#ffffff 3600 IN NS ns.ussr.eu.net
ccl.ru color=#ffffff 3600 IN NS ns.spb.su

Поскольку имя зоны здесь совпадает с указанным в поле имя записи SOA, которая идет перед записями NS, поле зона можно оставить пустым. Поэтому строки

IN NS ns.ccl.ru
IN NS ns.ussr.eu.net
IN NS ns.spb.su

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

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

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

имя_машины [время] [класс] А ip-адрес

Например:

lab10.icmm.ru color=#ffffff 85640 IN A 62.76.204.162

Записи PTR выполняют обратное преобразование IP-адресов в имена машин. Как и в случае с записями А, для каждого сетевого интерфейса машины должна быть сделана одна запись PTR. Перед тем как описывать эти записи, давайте отвлечемся и поговорим о специальном домене верхнего уровня, который называется IN-ADDR.ARPA.

Полностью определенные имена машин можно рассматривать как структуру, в которой "старший бит" стоит справа. Например, в имени

vtau.pstu.ac.ru

vtau находится в pstu, pstu находится в ac, a ac - в ru. С другой стороны, в IP-адресах "старший бит" стоит слева:

195.19.161.194

Машина 194 находится в сети 195.19.161.

Домен IN-ADDR.ARPA был создан для того, чтобы и для преобразования IP-адресов в имена машин, и для преобразования имен в IP-адреса использовался один и тот же набор программных модулей. Поддомены этого домена именуются как IP-адреса с байтами, расставленными в обратном порядке. Например, зона для cети 195.19.161 составлена следующим образом (см. рис. 5):

Рис. 5. Таксономия зон в IN-ADDR.ARPA

Обратите внимание на то, что на рис. 5 компонент 161.19.195 (представляющий сеть класса C) отмечен как одна зона. Зоны с именем 195.IN-ADDR.ARPA нет. Это противоречит здравому смыслу и ранее сказанному нами в этой главе, но это очень особый случай.

По сути дела, никто не делает запросов о 195.IN-ADDR.ARPA. (Попробуйте сделать это с помощью dig или nslookup, и у Вас ничего не получится.) Проблема состоит в том, чтобы запросы об адресах под 195.IN-ADDR.ARPA выдавали результаты, имеющие смысл.

Оказывается, если сделать на всех серверах зоны IN-ADDR.ARPA записи NS о 161.19.195.IN-ADDR.ARPA, то надобность в промежуточной зоне (195.IN-ADDR.ARPA) исчезнет. Ссылки на ее поддомены будут обрабатываться таким образом, чтобы возвращался самый подробный адрес сервера, о котором у данного сервера есть запись NS.

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

Считайте этот адрес единым целым и строите родительский домен и поддомен как обычно.

Общий формат записи PTR таков:

адрес [время] [класс] PTR имя_машины

Запись PTR в домене IN-ADDR.ARPA, соответствующая приведенной выше записи А для машины vtau, будет иметь такой вид:

194.161.19.195 IN PTR vtau.pstu.ac.ru.

Имя 194.161.19.195 не заканчивается точкой и поэтому является относительным. Вопрос: относительным относительно чего? Ни в коем случае не относительно "pstu.ac.ru.". Для того чтобы эта запись была точной, домен по умолчанию должен называться "IN-ADDR.ARPA.".

Этого можно добиться либо поместив записи PTR в отдельный файл, в котором домен по умолчанию - IN-ADDR.ARPA. (заданный в файле начальной загрузки демона named ), либо изменив этот домен с помощью директивы $ORIGIN .

Если домен по умолчанию определен как 161.19.195.IN-ADDR.ARPA., то запись можно представить так:

194 IN PTR vtau.pstu.ac.ru.

Поскольку pstu.ac.ru и 161.19.195.IN-ADDR.ARPA - разные области пространства имен DNS, они составляют две отдельные зоны. У каждой из этих зон должна быть своя запись SOA и свои записи о ресурсах. Помимо определения зоны IN-ADDR.ARPA для каждой реальной сети Вам нужно определить зону, которая заботилась бы о закольцовывающей сети, 127.0.0.

Файлы, содержащие записи PTR, в больших организациях часто строятся по подсетям. При этом домен по умолчанию включает лишь часть сетевого адреса, которая является обшей для всех подсетей (Такое возможно лишь в том случае, если подсети разбиты по границе байта). В приведенном выше примере домен по умолчанию включает полный адрес подсети. Отметим, что имя машины vtau должно быть полностью определенным, чтобы к нему не добавился домен 161.19.195.IN-ADDR.ARPA.

Обратные соответствия, содержащиеся в записях PTR в домене IN-ADDR.ARPA, используются всеми программами, которые аутентифицируют входящий сетевой трафик. Например, удаленная регистрация без пароля допускается, если исходная машина указана по имени в пользовательском файле ~/.rhosts. Когда машина-адресат получает запрос на установление соединения, она знает машину-отправителя только по IP-адресу. Пользуясь услугами DNS, она преобразовывает IP-адрес в имя, которое сравнивается с соответствующим файлом. Программы natstat, sendmail, X Window, syslog, finger, ftp, rlogind - все они получают имена машин из IP-адресов с помощью обратного преобразования.

Важно, чтобы записи А соответствовали записям PTR. Несовпадение и отсутствие последних приводит к тайм-аутам, в результате чего Ваша система замедляет ход и начинает еле ползти.

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

Запись MX имеет следующий формат:

имя [время] [класс] MX приоритет машина ...

Записи MX полезны во многих ситуациях, например:

• если у Вас есть почтовый сервер;
• если машина-адресат выключена;
• если адресат не подключен к Internet.

У самого домена должна быть запись MX для почтового сервера, чтобы можно было посылать почту по схеме пользователь@домен. Это все равно требует наличия уникальных пользовательских имен на машинах данного домена. Например, чтобы иметь возможность посылать почту пользователю root@mail.ccl.ru, нам нужна либо машина mail, либо запись MX в домене ccl.ru:

Записи CNAME позволяют присваивать машине мнемонические имена. Мнемонические имена широко применяются для связывания с машиной какой-либо функции, либо просто для сокращения имени. Реальное имя иногда называют каноническим (отсюда сокращенное название записи CNAME). Вот несколько примеров:

ftp IN CNAME anchor
kb IN CNAME kibblesnbits

Запись CNAME имеет следующий формат:

мнемоимя [время] [класс] CNAME имя_машины

Если у машины есть запись CNAME, которая содержит ее мнемонические имена, другие записи для данной машины должны ссылаться на ее реальное имя, а не на мнемоническое. Когда программы DNS встречают запись CNAME, они останавливают свои запросы по мнемоническому имени и переключаются на реальное имя (Мнемоимена полезны, например, в случае, когда имя машины изменилось и вы хотите разрешить пользователям, знающим старое имя, получить доступ к машине).

В записи HINFO указываются изготовитель и модель компьютера, а также операционная система, которую он использует. Многие организации эти записи не ведут - либо по соображениям безопасности, либо потому, что их системные администраторы просто-напросто лентяйничают. Если человек, имеющий доступ к Internet, сможет выяснить тип компьютера и версию операционной системы, Ваша система станет более уязвимой для взлома. Запись HINFO имеет следующий формат:

имя [время] [класс] HINFO тип_машины ос

Например, запись

anchor IN HINFO "sparc10" "sunos 4.1.3"

показывает, что anchor - это машина Sun Sparcstation 10, работающая в SunOS 4.1.3. Если данные состоят из одного слова, то кавычки не нужны; кавычки "защищают" встроенные пробелы. Можно использовать любые строковые данные. Рекомендуемые значения перечислены в RFC1340.

В записи WKS перечисляются известные сервисные программы, поддерживаемые данной машиной. Многие организации эти записи не используют, опять-таки по соображениям безопасности. Мы не знаем ни одной программы, которая зависела бы от записей WKS; ими пользовались только машины Symbolics. Запись WKS имеет следующий формат:

имя [время] [класс] WKS [адрес] протокол программы

Например:

anchor IN WKS TCP telnet smtp ftp

Поле адрес (IP-адрес) обычно опускают. Вообще говоря, мы рекомендуем опускать всю запись.

Существует несколько записей, которые предназначены специально для содействия в маршрутизации почты, особенно при направлении почты группе получателей. Запись MB (Mail Box) задает машину, на которой находится почтовый ящик адресата, запись MG (Mail Group Member) определяет почтовую группу, а запись MR (Mail Rename Record) содержит новое имя почтового ящика. Одно время были записи MD и MF, но затем их заменили записями MX. Записи MINFO (Mailbox Information) обеспечивают управление списками рассылки.

Единственная широко используемая запись о ресурсах из вышеперечисленных - MX. Функциональные возможности, воплощенные в записях MG, MR и MINFO, можно реализовать с помощью файла aliases.

Запись ТХТ используется для добавления произвольного текста к DNS-записям машины. Например, следующие записи определяют нашу организацию:

IN ТХТ "University of CO, Boulder Campus, CS Dept"
IN ТХТ WP-PH://directory.сolorado.edu/105
IN ТХТ WP-SMTP-EXPN-Finger://ns.cs.сolorado.edu

Запись ТХТ имеет такой формат:

имя [время] [класс] ТХТ информация

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

К новым типам записей относятся:

Администратор DNS, указанный в записи SOA, отвечает за весь домен; записи RP позволяют конкретизировать задачу и обеспечивают включение другой полезной информации, а не только адреса электронной почты.