IXFR

Когда в зоне меняется одна запись, пересылать вторичному серверу весь файл расточительно — особенно если в нём десятки тысяч строк. Механизм из RFC 1995 решает это так: вторичный сервер сообщает номер версии, который у него уже есть, и получает только разницу. Версией служит серийный номер из SOA-записи.

Для этого первичный сервер должен помнить историю правок. BIND, например, ведёт журнал изменений рядом с файлом зоны (файл с расширением .jnl) и из него собирает ответ. Обычно IXFR работает в паре с NOTIFY (RFC 1996): первичный сервер сам сообщает вторичным, что зона изменилась, и те сразу запрашивают обновление, не дожидаясь таймера refresh.

Как выглядит обмен

Ответ состоит из блоков «удалить — добавить». Сначала идёт старая SOA и записи, которые нужно убрать, затем новая SOA и записи, которые нужно добавить. Если между версиями было несколько правок, такие блоки следуют друг за другом. Вторичный сервер применяет их по порядку и в итоге получает ту же зону, что и на первичном.

Если истории с нужной версии нет или различий слишком много, первичный сервер вправе ответить полной копией зоны, как при AXFR. Для вторичного сервера такой откат прозрачен.

Пример запроса через dig

Утилита dig умеет запросить изменения начиная с конкретного серийного номера. Сервер должен разрешать передачу зоны вашему адресу, иначе вернёт отказ:

dig @ns1.example.ru example.ru ixfr=2026100901

В выводе видно, какие записи удалены и какие добавлены после версии 2026100901.

Из-за чего ломается инкрементальная передача

• Серийный номер не увеличили после правки — вторичные серверы считают, что изменений нет.
• Зону с динамическими обновлениями поправили вручную в файле, не заморозив её командой rndc freeze, — журнал расходится с файлом, и BIND сообщает об ошибке при загрузке.
• Передача не защищена: без списка разрешённых адресов или подписи TSIG зону может скачать кто угодно.