Почему это важно
Практическое пояснение: доступность двух серверов с одной текущей зоной ещё не подтверждает одинаковую историю изменений. При переключении источника передачи нужно учитывать известную клиенту версию и возможный полный ответ.
Что подтверждено
Обновлённую зону следует сохранять в устойчивом хранилище до использования новой версии в ответах IXFR или AXFR. Иначе сбой сервера может оставить вторичным серверам данные, которых у восстановленного источника уже нет.
Граница применимости: RFC 1995, август 1996 года; раздел 2, стр. 2. Сохранены should и описанный сценарий сбоя. Конкретная реализация fsync, журналирования или репликации хранилища здесь не задаётся.
Серверу IXFR рекомендуется хранить текущую зону и различия с несколькими старыми версиями. Хранить все прежние версии бесконечно сервер не обязан; старые версии разрешено удалять в любое время.
Граница применимости: RFC 1995, август 1996 года; разделы 2 и 5, стр. 2–3. Рекомендация хранить историю не является гарантией наличия любой конкретной старой версии.
RFC 1995 рекомендует удалять информацию о старых версиях, если суммарная длина ответа IXFR превысила бы длину ответа AXFR. Для описанной стратегии документ указывает верхнюю границу хранения вдвое больше текущей зоны.
Граница применимости: RFC 1995, август 1996 года; раздел 5, стр. 3. Условие строгое: длиннее, а не равно. Оценка удвоенного объёма относится к этой стратегии, а не к измеренному расходу памяти любого DNS-сервера.
Информацию о версиях старше периода SOA.expire также разрешено удалять из истории IXFR.
Граница применимости: RFC 1995, август 1996 года; раздел 5, стр. 4. В источнике may. Это разрешение удалить историю, а не обязанность хранить все более молодые версии или менять TTL ответов.
Сервер IXFR может свести несколько последовательностей разностей в одну и отбросить сведения о промежуточных версиях. Эта свёртка необязательна; по ответу клиент не может определить, применялась ли свёртка.
Граница применимости: RFC 1995, август 1996 года; раздел 6, стр. 4. Свёртка относится к истории изменений, а не к сжатию байтов транспорта или обязательной функции каждого сервера.
Разная свёртка истории на двух серверах может сделать версию клиента, полученную от первого сервера, неизвестной второму. Тогда нужна полная передача. При неизвестной версии в запросе серверу рекомендуется не выдавать ошибку по этой причине, а попытаться выполнить полную передачу.
Граница применимости: RFC 1995, август 1996 года; раздел 6, стр. 4. Рекомендация распространяется и на сервер без функции свёртки. Равенство текущих версий серверов не доказывает совпадение доступной истории.
Что проверить
- Проверьте сохранение новой версии в устойчивом хранилище до её выдачи.
- При смене источника IXFR проверьте, известна ли новому серверу версия клиента.
- Разделяйте наличие текущей зоны и наличие исторических разностей.
- Сравните размер предполагаемого IXFR с полной передачей по выбранной политике.
- Не считайте SOA.expire обещанием хранить всю более молодую историю.
- Уточните политику свёртки и удаления истории у каждого источника передачи.
- Проверьте возможность полного ответа при неизвестной версии клиента.
Первоисточники
Incremental Zone Transfer in DNS
Internet Engineering Task Force · RFC 1995, August 1996
Полный RFC 1995 (август 1996, 8 страниц) прочитан локально 2026-09-09. Сверены запрос и ответы IXFR, применение разностей, сохранение зоны, удаление и свёртка истории. Прежняя дата получения сохранена. Последующие документы и текущие реализации не проверялись.
Открыть первоисточник