TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

■ Соединяться с первичным сервером каждые 24 часа.

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

■ Повторить попытку соединения через 2 часа, если он не сможет соединиться с первичным в намеченное время.

■ Отметить все свои данные просроченными и прекратить отвечать на запросы, если он не сможет соединяться с первичным в течение 30 дней.

Показанные в примере значения рекомендованы (см. RFC 1537) для серверов верхнего уровня.

12.14.2 Время жизни (Time-To-Live)

В RFC 1035 (специфицирует протокол DNS) заявлено, что TTL в записи SOA — это минимальное значение тайм-аута, разрешенное для всех записей. Но на практике администратору хочется использовать TTL в записи SOA как значение по умолчанию, указывая меньшие значения только для определенных хостов, информация на которых должна быстро измениться. В реализации следуют этому более осмысленному действию, а не требованиям стандарта.

В приведенном примере значение по умолчанию (для TTL — 4 дня) обычно располагается в диапазоне от одного дня до недели, в зависимости от устойчивости данного элемента сайта.

12.14.3 Дополнение имени

Имя, которое не заканчивается точкой, дополняется именем домена для зоны, например fishfood.com. Таким образом, в этом файле ns будет соответствовать ns.fishfood.com.

12.14.4 Запись о сервере имен

Запись о сервере имен (Name Server — NS) идентифицирует сервер для домена. Если имеются подзоны, необходимы и элементы для дочерних серверов имен подзон, чтобы сервер с более высоким уровнем мог использовать указатели на серверы низшего уровня. Записи об адресе требуются для обеспечения доступа к дочерним серверам и называются связующими (glue records).

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

12.14.5 Записи об адресе

Запись об адресе (address records) — это просто отображение имени в адрес. Таким образом, адресом ns.fishfood.com будет 172.66.1.1.

12.14.6 Записи CNAME

Вспомним, что для более осмысленного именования можно присваивать серверным хостам короткий псевдоним. В показанном примере службы World Wide Web пересылки файлов и gopher выполняются на той же машине, которая поддерживает доставку электронной почты. Запись для канонического имени (canonical name — CNAME) определяет короткое имя для хоста и разрешает пользователям вводить www.fishfood.com, ftp.fishfood.com или gopher.fishfood.com.

12.14.7 Записи для почтового обмена

Серверы обмена почтой (Mail Exchanger — MX) обеспечивают доставку в/из сети (см. главу 16). В файле существуют три записи MX, которые идентифицируют сервер MX для fishfood.com.

fishfood.com. IN MX 1 MAIL-RELAY

*             IN MX 1 MAIL-RELAY

ns            IN MX 1 MAIL-RELAY

Эти записи фактически указывают, что:

■ Почта, адресованная на некто@fishfood.com, должна быть доставлена на mail-relay.fishfood.com.

■ Подстановочный символ * позволяет пересылать почту, адресованную особым хостам, которые отсутствуют в списке DNS. Почта, адресованная на некто@любой_хост.fishfood.com, должна быть доставлена на mail-relay.fishfood.com.

■ Почта, адресованная на некто@ns.fishfood.com, должна быть передана по адресу mail-relay.fishfood.com.

Все это выглядит так, будто подстановочный символ должен полностью обеспечить обращение к ns.fishfood.com. Тогда зачем же нужен отдельный оператор? Правила для подстановочного символа гласят, что он может быть применен только к системам, не имеющим никаких других записей в базе данных DNS.

Числа, стоящие после MX, называются предпочтительными (preference numbers). Они будут рассмотрены в главе 16 при описании работы с электронной почтой.

12.14.8 Записи TXT и HINFO

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