Практикум по RFC 1982, 1995 и 1996

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

Разберите сравнение версий DNS-зоны, полные и инкрементальные ответы, применение разностей и проверку после NOTIFY. Все ситуации решаются по уроку и приведённым данным; настройки конкретной реализации проверяются отдельно.

Практика → проверка решения150 минут10 модулей20 вопросов
После курса

Что вы сможете сделать

  1. Сравнивать SOA SERIAL с учётом циклического пространства и неопределённых пар.
  2. Определять состав IXFR и момент завершения обработки изменений.
  3. Учитывать доступную историю при смене источника передачи зоны.
  4. Различать получение NOTIFY, проверку SOA и обновление рабочей копии.
Модуль 1 из 10

SERIAL: значение и допустимое увеличение

Курс опирается на сохранённые RFC 1982, 1995 и 1996 от августа 1996 года. Начните с числового пространства версии зоны. Особенности конкретного DNS-сервера проверяются отдельно.

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

    Проверить тезис: SOA SERIAL: сравнение и переход через границу 01

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

    Проверить тезис: SOA SERIAL: сравнение и переход через границу 02

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

    Проверить тезис: SOA SERIAL: сравнение и переход через границу 07

Модуль 2 из 10

Как сравнить две версии зоны

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

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

    Проверить тезис: SOA SERIAL: сравнение и переход через границу 03

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

    Проверить тезис: SOA SERIAL: сравнение и переход через границу 04

Модуль 3 из 10

Серия шагов и период SOA.expire

Положительный шаг сравнивают с предыдущим состоянием; всю последовательность — ещё и с исходным. Для бумажных примеров задаём малое кольцо 0–255, модуль 256 и допустимую прибавку 0–127; это учебная модель, не размер SERIAL в DNS.

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

    Проверить тезис: SOA SERIAL: сравнение и переход через границу 05

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

    Проверить тезис: SOA SERIAL: сравнение и переход через границу 06

Модуль 4 из 10

Кто запрашивает и что означает одиночная SOA

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

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

    Проверить тезис: IXFR: состав ответа и применение изменений 01

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

    Проверить тезис: IXFR: состав ответа и применение изменений 07

Модуль 5 из 10

Полная зона и инкрементальный ответ

Название IXFR описывает запрос, а состав ответа зависит от сервера и доступной истории. Начало ответа помогает распознать формат, но ещё не подтверждает завершение передачи.

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

    Проверить тезис: IXFR: состав ответа и применение изменений 02

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

    Проверить тезис: IXFR: состав ответа и применение изменений 03

Модуль 6 из 10

Удаления, добавления и момент переключения

Принимайте разности как последовательность изменений рабочей копии. Переданная часть набора записей не заменяет весь набор автоматически.

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

    Проверить тезис: IXFR: состав ответа и применение изменений 04

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

    Проверить тезис: IXFR: состав ответа и применение изменений 05

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

    Проверить тезис: IXFR: состав ответа и применение изменений 06

Модуль 7 из 10

Сохранение зоны и границы истории

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

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

    Проверить тезис: IXFR: хранение истории и переход к полной передаче 01

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

    Проверить тезис: IXFR: хранение истории и переход к полной передаче 02

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

    Проверить тезис: IXFR: хранение истории и переход к полной передаче 03

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

    Проверить тезис: IXFR: хранение истории и переход к полной передаче 04

Модуль 8 из 10

Свёртка и другой источник передачи

Сравнивайте историю каждого источника с версией клиента. Равенство текущих SERIAL двух источников ещё не показывает, какие промежуточные версии доступны на каждом.

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

    Проверить тезис: IXFR: хранение истории и переход к полной передаче 05

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

    Проверить тезис: IXFR: хранение истории и переход к полной передаче 06

Модуль 9 из 10

Известный источник и предел подсказки

В NOTIFY отправитель сообщает о возможном изменении, а получатель решает, нужна ли отдельная проверка. Notify Set, зависимости передачи и доверенный источник относятся к конкретной зоне.

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

    Проверить тезис: DNS NOTIFY: проверка зоны после уведомления 01

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

    Проверить тезис: DNS NOTIFY: проверка зоны после уведомления 02

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

    Проверить тезис: DNS NOTIFY: проверка зоны после уведомления 03

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

    Проверить тезис: DNS NOTIFY: проверка зоны после уведомления 04

Модуль 10 из 10

Получение уведомления и обновление копии

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

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

    Проверить тезис: DNS NOTIFY: проверка зоны после уведомления 05

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

    Проверить тезис: DNS NOTIFY: проверка зоны после уведомления 06

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

    Проверить тезис: DNS NOTIFY: проверка зоны после уведомления 07

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

    Проверить тезис: DNS NOTIFY: проверка зоны после уведомления 08

Финишная прямая

Проверьте инженерное мышление

Вопросы проверяют не память на аббревиатуры, а умение не делать лишних выводов.

01Оператор увеличивает SOA SERIAL с 4 294 967 294 на 4. Какое значение он должен получить по модулю 2³²?
02Инженер выбирает наибольшую из предложенных прибавок n, для которой одно увеличение SOA SERIAL определено в RFC 1982. Какое значение проходит эту проверку?
03Оператор сравнивает SOA SERIAL, равный нулю, с каждым номером из списка. При каком втором номере RFC 1982 оставляет порядок этой пары неопределённым?
04Оператор сопоставляет SOA SERIAL двух копий: 4 294 967 295 и 1. Как оценить эту пару именно в серийном порядке?
05Инженер использует учебное кольцо 0–255 с модулем 256. Он начинает с 90 и выполняет две прибавки по 100. Чему равен конечный номер?
06Оператор запланировал две прибавки SOA SERIAL по 1 200 000 000 за один период SOA.expire. Каждая отдельно допустима. Какой вывод учитывает рекомендацию RFC 1982 о всей последовательности?
07Вторичный сервер C с версией 18 запрашивает IXFR у источника S с версией 21. Какую SOA должен поместить C в запрос по формату RFC 1995?
08Клиент IXFR хранит SERIAL 50. По UDP он получил единственную SOA с SERIAL 52 и никаких данных зоны. Что RFC 1995 рекомендует этому клиенту дальше?
09Клиент отправил QTYPE=IXFR. Сервер вернул полную зону, окружённую её текущей SOA, сохранив этот тип запроса. Как клиенту оценить формат по RFC 1995?
10Клиент хранит версию 8. Ответ начинается SOA 10, SOA 8, затем идут удаляемые записи. Какой вывод о начале обмена делает клиент по RFC 1995?
11Клиент IXFR с рабочей версией 7 обрабатывает разности 7→8 и 8→9. Первая обработана, вторая оборвалась. Какому условию переключения копии следует этот клиент по RFC 1995?
12У клиента две A-записи имени: 192.0.2.10 и 192.0.2.11. В принятой разности удаляется .10 и добавляется .12; запись .11 не упомянута. Как клиенту применить эту разность?
13Сервер раздал новую версию зоны, оставив на устойчивом хранилище старую, затем аварийно перезапустился. Какой порядок действий этому серверу рекомендует RFC 1995 для снижения такого риска?
14Инженер сравнил длины ответов IXFR и AXFR: они равны. Как ему применить именно рекомендацию RFC 1995 об удалении истории, когда IXFR длиннее AXFR?
15Клиент получил корректный инкрементальный ответ. Может ли этот клиент по одному такому ответу определить, сворачивал ли источник несколько изменений в одно?
16Клиент получил версию 12 от A. Сервер B сейчас имеет 15, но не знает 12 после свёртки истории. Какой ответ на IXFR от этого клиента рекомендует подготовить B?
17Сервер получил NOTIFY для своей зоны от адреса, которого нет среди известных ему источников этой зоны. Какое действие получателя рекомендует RFC 1996?
18Сервер получил NOTIFY от известного источника зоны. SOA в Answer отличается от локальной. Как этому получателю использовать подсказку по RFC 1996?
19Отправитель NOTIFY получил от целевого сервера ответ с ожидаемыми полями сопоставления для этого события. Что вправе отметить отправитель на основании такого ответа?
20Получатель знает источники A и B. A обновился и прислал NOTIFY, а B ещё хранит прежнюю версию. У кого получателю следует проверить SOA по RFC 1996?
Проверяемая база

Источники курса

Полные сведения о первоисточниках приведены один раз для всего курса. Под тезисами — ссылки на соответствующие утверждения Архивариума.

  • Первичная спецификация

    Serial Number Arithmetic

    Internet Engineering Task Force · RFC 1982, August 1996

    Полный RFC 1982 (август 1996, 7 страниц) прочитан локально 2026-09-09. Сверены диапазон и операции SOA SERIAL, неопределённые пары и SOA.expire. retrieved_on — дата постановки в очередь. Последующие документы и текущие реализации не проверялись.

    Открыть первоисточник
  • Первичная спецификация

    Incremental Zone Transfer in DNS

    Internet Engineering Task Force · RFC 1995, August 1996

    Полный RFC 1995 (август 1996, 8 страниц) прочитан локально 2026-09-09. Сверены запрос и ответы IXFR, применение разностей, сохранение зоны, удаление и свёртка истории. Прежняя дата получения сохранена. Последующие документы и текущие реализации не проверялись.

    Открыть первоисточник
  • Первичная спецификация

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

    Internet Engineering Task Force · RFC 1996, August 1996

    Полный RFC 1996 (август 1996, 7 страниц) прочитан локально 2026-09-09. Сверены Notify Set, известный источник, проверка SOA, границы подсказок и подтверждений, распространение NOTIFY. Прежняя дата получения сохранена. Последующие документы и текущие реализации не проверялись.

    Открыть первоисточник

Delect.ru — информационный справочник: сведения о ценах, наличии и брендах формируются из данных витрины для анализа и сравнения. Наличие по данным витрины лучше дополнительно уточнять у выбранного поставщика; перед закупкой обязательно ставьте резервы. Сервис не является посредником при сделке и не сторона договора; коммерческие условия согласуются напрямую с выбранным дистрибьютором. Обозначения брендов приводятся для идентификации предложений.

Подтвердите действие