RFC 1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)

image_print
Network Working Group                                       P. Vixie
Request for Comments: 1996                                       ISC
Updates: 1035                                            August 1996
Category: Standards Track

Механизм быстрого уведомления об изменении зоны

A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)

PDF

Статус документа

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа «Internet Official Protocol Standards» (STD 1). Документ может распространяться без ограничений.

Тезисы

В этом документе описан код операции NOTIFY для DNS, посредством которой ведущий (master) сервер извещает группу ведомых (slave) серверов о том, что хранящиеся на ведущем сервере данные изменились и ведомым серверам следует инициировать запрос для получения новой информации.

1. Обоснования и сфера документа

1.1. Медленное распространение новых и измененных данных в зоне DNS может быть обусловлено относительно большим периодом обновления для этой зоны. Преимущество редких обновлений состоит в том, что это снижает нагрузку на ведущий сервер. Но за это преимущество приходиться расплачиваться тем, что в течение достаточно продолжительного интервала после обновления зоны может сохраняться несогласованность между уполномоченными серверами (authority server) зоны.

1.2. DNS-транзакция NOTIFY позволяет ведущему серверу информировать ведомые об изменениях в зоне1 и, тем самым, снизить задержку распространения информации без возникновения нежелательного роста нагрузки на ведущий сервер. Данная спецификация позволяет уведомлять ведомые серверы лишь об изменении SOA RR2, но архитектура NOTIFY может быть расширена и на другие типы RR.

1.3. Документ умышленно включает множество ролевых определений — серверы Master (ведущий), Slave (ведомый) и Stealth (скрытый), их перечисление в NS RR, а также поле SOA MNAME. В этом смысле данный документ можно считать дополнением к [RFC1035].

2. Определения и инварианты

2.1. Определения используемых в документе терминов

Slave (ведомый)

Уполномоченный сервер, который использует перенос зоны для ее получения. Все ведомые серверы указываются в NS RR для данной зоны.

Master (ведущий)

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

Primary Master (первичный ведущий)

Ведущий сервер в корне графа зависимостей для переноса зоны. Первичный ведущий сервер зоны указывается в поле SOA MNAME, а также может указываться в NS RR. По определению для зоны существует только один первичный ведущий сервер.

Stealth (скрытый)

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

Notify Set (набор [серверов] для уведомления)

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

2.2. Серверы зоны должны быть организованы в граф зависимости так, чтобы существовал единственных первичный ведущий сервер, а все остальные серверы должны использовать перенос AXFR или IXFR с первичного ведущего сервера или с какого-либо из ведомых, который является одновременно и ведущим. Не допускается наличие петель в графе зависимостей AXFR.

3. Сообщение NOTIFY

3.1. Когда ведущий сервер обновляет одну или несколько RR, в которых могут быть заинтересованы ведомые серверы, ведущий сервер может передать измененные RR для имени, класса, типа и (необязательно) новые RDATA каждому ведомому серверу, используя протокол на основе операции NOTIFY.

3.2. NOTIFY использует формат сообщений DNS, хотя реально применяется только часть доступных полей. Поля, не рассматриваемые в данном документе, заполняются нулями (двоичными) и реализации должны игнорировать все сообщения, для которых данное условие не выполняется.

3.3. Сообщение NOTIFY похоже на QUERY в том, что в запросе флаг QR сброшен, а в отклике — установлен. Отклики не содержат полезной информации, но получение отклика ведущим сервером служит индикацией того, что ведомый сервер получил сообщение NOTIFY и ведущий сервер может удалить этот ведомый из очереди на повтор передачи для данного события NOTIFY.

3.4. Транспортным протоколом для транзакций NOTIFY будет UDP, если ведущий сервер не настроен на использование протокола TCP (например, в тех случаях, когда между ведущими и ведомыми серверами имеется межсетевой экран, который пропускает только трафик TCP, или измененная запись RR настолько велика, что не может быть передана в дейтаграмме UDP/DNS).

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

3.6. При использовании UDP ведущий сервер периодически шлет ведомому запрос NOTIFY, пока не будет превышено число попыток («таймаут»), получено сообщение ICMP о недоступности порта или получен отклик NOTIFY от ведомого сервера с соответствующими значениями идентификатора запроса, QNAME, IP-адреса отправителя, и номером порта UDP на стороне отправителя.

Примечание

Интервал между попытками и общее число повторов следует делать конфигурационными параметрами, доступными администратору сервера имен. Возможна независимая установка параметров для каждой зоны. Разумными значениями являются интервал 60 секунд (или таймаут при использовании TCP) и максимальное число попыток — 5 (для UDP). Представляется разумным использование линейного или экспоненциального роста интервала повтора в зависимости от номера попытки.

3.7. Запрос NOTIFY имеет QDCOUNT > 0, ANCOUNT >= 0, AUCOUNT >= 0, ADCOUNT >=0. Если ANCOUNT > 0, раздел answer представляет незащищенное указание в новом наборе RRset для данного <QNAME,QCLASS,QTYPE>. Ведомый сервер, получивший такое указание, волен трактовать эквивалентность этого раздела answer своим локальным данным, как индикацию того, что не нужно выполнять других действий. Если ANCOUNT = 0 или ANCOUNT > 0 и раздел answer отличается от локальных данных ведомого сервера, последнему следует обратиться к известным ему ведущим сервераv для получения новых данных.

3.8. Ни в коем случае не следует использовать раздел answer запроса NOTIFY для обновления локальных данных ведомого сервера, индикации необходимости переноса зоны или изменения значений таймеров обновления зоны для ведомого сервера.