Изменениях описания зоны (DNS NOTIFY)

. Идея достаточно проста и проистекает из проблемы распространения изменений, внесенных в описание зоны при ее редактировании. Дело в том, что slave-серверы при традиционной работе опрашивают master-сервер (в данном контексте primary master) на предмет изменения в описании зоны через определенные промежутки времени, которые задаются в описании зоны. Возможна ситуация, когда изменения были внесены в зону сразу после ее копирования slave-сервером. В этом случае новая информация появится на всех slave-серверах только при следующем обновлении зоны.

Ситуация усугубляется еще и тем, что остальные не авторитативные серверы держат записи соответствия между именем домена и IP_адресом в своем кэше в течение времени TTL (Time To Live), которое также определяется в описании зоны. Обычно задержка между внесением изменений и стабильной работой с новым описанием зоны в российском сегменте Интернет составляет примерно 2 часа. Вот пример отчета программы nslookup для rambler.ru:

>set type=soa >rambler.ru Server: ns.rambler.ru Address: 217.73.192.49

rambler.ru origin = ns.rambler.ru mail addr = bindmaster.rambler-co.ru serial = 2002090601 refresh = 10800 (3H) retry = 1800 (30M) expire = 10800 (3H) minimum ttl = 3600 (1H) rambler.ru nameserver = ns.rambler.ru rambler.ru nameserver = ns.park.rambler.ru ns.rambler.ru internet address = 217.73.192.49 ns.park.rambler.ru internet address = 217.73.193.23 >

Позиция refresh говорит о том, что время опроса в стандартном режиме составляет 3 часа. А вот из другого отчета для зоны relarn.ru это время и того больше - сутки:

> relarn.ru Server: ns.relarn.ru Address: 194.226.65.3

relarn.ru origin = ns.relarn.ru mail addr = noc-dns.relarn.ru serial = 650127367 refresh = 86400 (1D) retry = 3600 (1H) expire = 604800 (1W) minimum ttl = 86400 (1D) relarn.ru nameserver = ns.relarn.ru relarn.ru nameserver = ns.ussr.EU.net relarn.ru nameserver = ns.spb.su relarn.ru nameserver = ns2.ripn.net ns.relarn.ru internet address = 194.226.65.3 ns.ussr.EU.net internet address = 193.124.22.65 ns.spb.su internet address = 193.124.83.69 ns2.ripn.net internet address = 194.226.96.30 >

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

Таким образом, механизм уведомления об изменениях в описании зоны необходим для ускорения введения в жизнь сделанных изменений.

Принцип работы DNS NOTIFY следующий:

В базу данных primary master вносятся изменения (руками с последующей перезагрузкой сервера или динамически по протоколу динамического обновления зоны).

Primary master оповещает свои slave о том, что произошли изменения, сообщая им номер версии описания зоны.

Slave запрашивает с primary master описание зоны и, если номера версии описаний зоны не совпадают (на primary master номер больше), то инициирует процесс обновления описания зоны.

Завершив обновление описания зоны, slave посылает оповещения на известные ему авторитативные сервера зоны.

На рисунке пояснется работы приведенной выше схемы:

Рис.2. Схема работы DNS NOTIFY

На рисунке 2 primary master является для обоих slave-серверов master-сервером c точки зрения процедуры передачи зоны. Но в принципе, для одного из серверов он может быть и не определен в качестве master-сервера. В этом случае появляется дополнительное звено в дереве зависимости обмена данными зоны. В этом случае изменения будут передаваться от сервера к серверу так, как это показано на рисунке 3:

Рис.3. Схема работы DNS NOTIFY при двухзвенном оповещении об изменении описания зоны.

Теперь поясним механизм

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