Передача DNS-зоны: SERIAL, IXFR и NOTIFY

SERIAL записи SOA принимает целые значения от 0 до 4 294 967 295. Для DNS SERIAL_BITS равен 32; в серийном порядке нет выделенных наименьшего и наибольшего значений, у каждого значения есть предшественник и преемник.

Для SOA SERIAL определено прибавление n от 0 до 2 147 483 647 включительно. Результат равен (s + n) по модулю 4 294 967 296. Прибавление числа вне этого диапазона документ оставляет неопределённым.

Ноль не имеет особого значения в серийной арифметике или SOA SERIAL. RFC 1982 предупреждает, что некоторые реализации ошибочно обрабатывали ноль как специальное значение, и рекомендует осторожность перед установкой SERIAL в ноль.

Для двух разных значений SOA SERIAL с абсолютной разностью меньше 2 147 483 648 более новым считается большее целое. При разности больше 2 147 483 648 более новым считается меньшее целое.

Два SOA SERIAL, различающиеся ровно на 2 147 483 648, не равны, но их порядок не определён. Реализация может вернуть любой порядок или ошибку; пользователю нельзя полагаться на один конкретный результат.

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

RFC 1982 рекомендует следить, чтобы суммарное увеличение SOA SERIAL за период SOA.expire не превышало 2 147 483 647. Каждый шаг начинает собственную последовательность и продолжает предыдущие последовательности, начатые в этом периоде. При вынужденном отступлении следует проверить следование всех серверов за каждым шагом.

Клиент IXFR — вторичный сервер, который запрашивает передачу; сервером IXFR может быть первичный или вторичный сервер. Запрос имеет тип IXFR и содержит SOA версии клиента в секции Authority.

Одиночная SOA в ответе IXFR имеет разные причины: версия клиента совпадает с серверной или новее неё, либо полный ответ не помещается в UDP-пакет. Во втором случае SOA текущей версии сервера указывает клиенту на необходимость запроса IXFR по TCP.

Если инкрементальная передача недоступна, на запрос IXFR возвращается полная зона. Сервер также может выбрать полный ответ. Первая и последняя ресурсные записи полного ответа — SOA зоны, а тип запроса остаётся IXFR.

В инкрементальном ответе список последовательностей изменений окружён SOA текущей версии сервера. Ответ начинается с двух SOA: сначала текущей версии сервера, затем заменяемой версии клиента.

Одна последовательность разностей IXFR содержит удаляемые, затем добавляемые записи. Список удалений начинается со старой SOA, список добавлений — с новой SOA. Изменение записи передаётся удалением прежней и добавлением изменённой записи; остальные записи того же типа могут не передаваться.

Последовательности разностей IXFR идут от самых старых изменений к самым новым. Они описывают историю от версии, известной клиенту, до текущей версии сервера.

Клиенту IXFR следует заменять старую версию зоны новой только после успешной обработки всех разностей.

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

Серверу IXFR рекомендуется хранить текущую зону и различия с несколькими старыми версиями. Хранить все прежние версии бесконечно сервер не обязан; старые версии разрешено удалять в любое время.

RFC 1995 рекомендует удалять информацию о старых версиях, если суммарная длина ответа IXFR превысила бы длину ответа AXFR. Для описанной стратегии документ указывает верхнюю границу хранения вдвое больше текущей зоны.

Информацию о версиях старше периода SOA.expire также разрешено удалять из истории IXFR.

Сервер IXFR может свести несколько последовательностей разностей в одну и отбросить сведения о промежуточных версиях. Эта свёртка необязательна; по ответу клиент не может определить, применялась ли свёртка.

Разная свёртка истории на двух серверах может сделать версию клиента, полученную от первого сервера, неизвестной второму. Тогда нужна полная передача. При неизвестной версии в запросе серверу рекомендуется не выдавать ошибку по этой причине, а попытаться выполнить полную передачу.

В RFC 1996 master — авторитетный сервер, настроенный как источник передачи зоны, а primary master находится в корне этой зависимости и указан в SOA MNAME. По умолчанию Notify Set содержит серверы из NS зоны, кроме указанного в SOA MNAME; скрытый сервер без NS может требовать явного добавления.

В графе зависимостей передачи зоны должен быть один primary master. Остальные серверы получают зону от него или от промежуточного сервера, который сам получает копию и служит источником для других. Циклы в графе AXFR не допускаются.

Секция Answer запроса NOTIFY является незащищённой подсказкой. Её нельзя использовать для изменения локальной зоны, решения о начале передачи или изменения таймеров обновления. Совпавшая с локальными данными подсказка может позволить получателю не выполнять дальнейшую проверку.

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

В этой версии NOTIFY определено уведомление об изменении SOA. Получателю рекомендуется запросить SOA у известного источника, приславшего уведомление, и проверить увеличение SERIAL; при увеличении следует начать AXFR или IXFR. Другой известный источник может ещё не успеть обновить копию.

Ответ NOTIFY подтверждает получение уведомления и позволяет отправителю убрать событие для этого получателя из очереди повторов. Для UDP отправитель сопоставляет ответ по query ID, QNAME, IP-адресу и UDP-порту источника. Такое подтверждение не означает завершение передачи зоны.

Промежуточный сервер должен отправлять NOTIFY дальше только после обновления своей SOA или установления, что обновление не нужно. Получателю рекомендуется отложить обработку повторного NOTIFY с теми же QNAME, QCLASS и QTYPE до завершения начатой обработки.

Источник зоны может задержать отправку NOTIFY, чтобы разнести начало передач во времени, но задержка не должна превышать SOA REFRESH. Случайные 30–60 секунд приведены как подходящий пример для общей локальной сети и зон умеренного размера.