База данных доменной системы имен DNS для каждого домена
представляет собой набор текстовых файлов, которые системный администратор ведет
на основном сервере имен этого домена. Элементы базы данных называются
записями о ресурсах; иногда их сокращенно обозначают PR. Типы и форматы
записей о ресурсах регламентируются документами RFC882, 1035 и 1183.
Базовый формат записи о ресурсах:
[имя] [время] [класс] тип
данные
Поля разделяются знаками табуляции или пробелами и могут
содержать специальные символы, перечисленные в табл. 3.
Таблица 3.
Символ |
Значение |
; |
Вводит комментарий |
# |
Также вводит комментарии (только в версии BIND
4.9) |
@ |
Имя текущего домена |
( ) |
Позволяют данным занимать несколько строк |
* |
Метасимвол (только в поле
имя) |
Поле имя, которое должно начинаться в первом столбце,
обозначает объект (машину или домен), к которому относится данная запись. Если
имеется несколько последовательно расположенных записей об одном объекте, то
после первой записи поле имя можно опустить.
В поле время задается время (в секундах), в течение
которого элемент данных может оставаться в кэше и считаться при этом
достоверным. Это поле часто опускают, но оно обязательно присутствует в файле
запуска кэша, который содержит имена и адреса корневых серверов.
В поле класс задается тип сети. Распознаются три
значения: IN (Internet), СН (ChaosNet), HS (Hesiod). ChaosNet - устаревшая сеть,
в которой раньше работали Lisp-машины фирмы Symbolics. Hesiod - это служба базы
данных, являющаяся надстройкой системы BIND; пока она используется не слишком
широко, но постепенно завоевывает популярность как замена NIS. Значением класса
по умолчанию является IN.
Существуют записи трех различных типов:
- зонные записи: определяют домены и их серверы имен;
- базовые записи: преобразовывают имена в адреса и наоборот, обеспечивают
маршрутизацию почты;
- факультативные записи: содержат дополнительную информацию о машинах.
Содержимое поля данные зависит от типа записи. Типы
записей перечислены в табл. 4.
Таблица 4.
|
Тип |
Имя |
Функция |
Зонные |
SOA |
Начало
полномочии |
Определяет DNS-зону полномочий |
NS |
Сервер
имен |
Определяет серверы для зоны |
Базовые |
А |
Адрес
|
Преобразование имени в адрес |
PTR |
Указатель |
Преобразование адреса в имя |
MX |
Почтовая
станция |
Управляет
маршрутизацией электронной почты |
Факультативные |
CNAME |
Каноническое
имя |
Мнемонические
имена машины |
HINFO |
Информация о
машине |
Описание
аппаратных средств и операционной системы |
RP |
Ответственный |
Технический специалист, отвечающий за машину |
WKS |
Известные услуги |
Услуги, которые предоставляет машина |
TXT |
Текст |
Комментарии или
нестандартная информация |
Записи HINFO не используется по соображениям безопасности.
Записи WKS не используется по соображениям
производительности.
Существуют и другие типы записей, которые широко не
используются.
Запись
SOA
Запись SOA отмечает начало зоны - группы записей о
ресурсах, расположенных в одной области пространства имен DNS. Домен DNS обычно
соответствует минимум двум зонам; одна служит для преобразования имен машин в
IP-адреса, а остальные - для обратного преобразования.
Для каждой зоны делается всего одна запись SOA; зона
продолжается до тех пор, пока не появляется следующая запись SOA. Запись SOA
содержит имя зоны, адреса, необходимые для установления технических контактов,
различные значения тайм-аутов. Эта запись должна быть первой записью зоны.
Например:
;; AUTHORITY RECORDS:
ccl.ru. color=#ffffff
3600 IN SOA ns.ccl.ru.
hostmaster.perm.ru. (
2000102401; serial 10800 ; refresh (3 hours) 3600 ; retry
(1 hour) 2592000 ; expire (30 days) 3600 ) ; minimum (1
hour)
Поле имя может содержать символ @, обозначающий имя
текущей зоны. В этом примере можно было вместо
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
Записи 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
Записи 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 приоритет машина
...
mail.ccl.ru |
IN |
MX |
10 |
gw1.ccl.ru |
|
IN |
MX |
40 |
gw4.ccl.ru |
Записи MX полезны во многих ситуациях, например:
- если у Вас есть почтовый сервер;
- если машина-адресат выключена;
- если адресат не подключен к Internet.
У самого домена должна быть запись MX для почтового сервера,
чтобы можно было посылать почту по схеме пользователь@домен. Это все
равно требует наличия уникальных пользовательских имен на машинах данного
домена. Например, чтобы иметь возможность посылать почту пользователю
root@mail.ccl.ru, нам нужна либо машина mail, либо запись MX в домене
ccl.ru:
mail |
IN |
MX |
10 |
gw1.ccl.ru |
|
IN |
MX |
40 |
gw4.ccl.ru |
Записи
CNAME
Записи CNAME позволяют присваивать машине мнемонические имена.
Мнемонические имена широко применяются для связывания с машиной какой-либо
функции, либо просто для сокращения имени. Реальное имя иногда называют
каноническим (отсюда сокращенное название записи CNAME). Вот несколько
примеров:
ftp IN CNAME anchor kb IN CNAME
kibblesnbits
Запись CNAME имеет следующий формат:
мнемоимя [время] [класс] CNAME
имя_машины
Если у машины есть запись CNAME, которая содержит ее
мнемонические имена, другие записи для данной машины должны ссылаться на ее
реальное имя, а не на мнемоническое. Когда программы DNS встречают запись CNAME,
они останавливают свои запросы по мнемоническому
имени и переключаются на реальное имя
(Мнемоимена полезны, например, в случае, когда имя машины изменилось и вы хотите
разрешить пользователям, знающим старое имя, получить доступ к
машине).
Записи
HINFO
В записи HINFO указываются изготовитель и модель компьютера, а
также операционная система, которую он использует. Многие организации эти записи
не ведут - либо по соображениям безопасности, либо потому, что их системные
администраторы просто-напросто лентяйничают. Если человек, имеющий доступ к
Internet, сможет выяснить тип компьютера и версию операционной системы, Ваша
система станет более уязвимой для взлома. Запись HINFO имеет следующий
формат:
имя [время] [класс] HINFO тип_машины
ос
Например, запись
anchor IN HINFO "sparc10" "sunos
4.1.3"
показывает, что anchor - это машина Sun Sparcstation 10,
работающая в SunOS 4.1.3. Если данные состоят из одного слова, то кавычки не
нужны; кавычки "защищают" встроенные пробелы. Можно использовать любые
строковые данные. Рекомендуемые значения перечислены в RFC1340.
Записи
WKS
В записи 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 определено несколько экспериментальных
типов записей, которые предназначены для работы в новых средах глобальных сетей,
для встраивания в другие типы баз данных, а также для указания лица,
ответственного за машину или группу машин. Эти записи еще не вошли в широкое
употребление.
К новым типам записей относятся:
AFSDB |
Это NS-запись для файловой системы Andrew (AFS), разработанной
в университете Карнеги-Меллон (CMU) и продаваемой фирмой TransArc, и для
уполномоченного сервера базы данных распределенной вычислительной среды
(Distributed Computing Environment, DCE). Формат этой записи похож на формат
записи MX, при этом поле приоритета используется для задания AFS или
DCE. |
ISDN |
Поле ISDN содержит ISDN-адрес, который, по сути дела, является
замаскированным номером телефона. |
Х.25 |
Эта запись содержит адрес, заданный в соответствии со
стандартом Х.25. |
RT |
Запись RT (Route Through - "Сквозная маршрутизация")
предназначена для выдачи подсказок о том, как достичь конкретной машины или
домена по сети ISDN или Х.25. Эти записи похожи на записи MX и указывают на
промежуточные машины, которые направляют пакеты на машину-адресат по
нe-Internet-овским каналам. |
RP |
Запись RP содержит адрес электронной почты (в котором знак @
заменен точкой) лица, ответственного за машину или домен, и псевдоимя записи
ТХТ, которым можно пользоваться для получения дополнительной информации
(например, номера телефона или полного
имени). |
Администратор DNS, указанный в записи SOA, отвечает за весь
домен; записи RP позволяют конкретизировать задачу и обеспечивают включение
другой полезной информации, а не только адреса электронной почты.
|