Кратко

  • Редакция 14 проекта DNSOP считает делегирование непрерывным, если родитель по-прежнему направляет к той же точке, а текущий NS-набор имеет хотя бы одно общее имя с кэшированным. Если DS наблюдался в обоих состояниях, должен совпадать и как минимум один делегированный подписант.
  • Полностью новый набор NS, полностью новый DS или переход между отсутствующим и существующим DS означает смену полномочий. Данные кэша в этой точке и ниже больше нельзя использовать; строгий и оппортунистический режимы по-разному распределяют отказ и fallback.
  • Пересечение решает задачу резолвера, но не удостоверяет миграцию. Квитанция перехода должна связать плановую общую часть, состояние родителя и ребёнка, основание изменения, три TTL, срок вывода и владельца отката. Это предложение Daniel Kade, а не требование IETF.

Обычное делегирование опубликовано с двух сторон. В родительской зоне находятся NS для referral, нужный glue и, при DNSSEC, DS. Дочерняя зона публикует авторитетный NS-набор на своей вершине. RFC 1034 требует согласовывать обе стороны zone cut, но DNS не даёт транзакции, которая меняет их одновременно.

Поэтому различие не обязательно означает аварию. У родителя может быть длинный фиксированный TTL, у ребёнка — короткий срок для быстрой смены серверов. Очереди регистратора, реестра и DNS-провайдера заканчиваются в разное время. Минимальные ответы могут не включать NS вершины. Обычное приложение его не запрашивает, поэтому резолвер способен никогда не увидеть авторитетную версию ребёнка.

Редакция 14 Delegation Revalidation by DNS Resolvers опубликована 2 сентября 2026 года. Datatracker показывает активный Internet-Draft рабочей группы DNSOP для Standards Track с предполагаемым статусом Proposed Standard; документ ждёт решения председателей о продвижении и истекает 6 марта 2027 года. Это не RFC и не команда внедрения.

Необязательный алгоритм соединяет три действия. После referral резолвер отдельно спрашивает у ребёнка NS вершины и, согласно RFC 2181, ставит авторитетный ответ выше неавторитетной копии родителя. Он получает по возможности авторитетные A и AAAA серверов. Затем возвращается к родителю, чтобы обнаружить удаление, переделегирование или полную смену полномочий.

Одного пересечения достаточно для теста, но не для истории

Кэш помнит NS-имена от родителя, их TTL и TTL набора DS, если видел его. При перепроверке родитель должен снова выдать referral к той же точке. Между прежним и нынешним родительскими NS должно остаться хотя бы одно общее имя.

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

Большинство не требуется. Четыре старых имени могут превратиться в одно старое и три новых. Старый подписант может временно сосуществовать с новым. Так алгоритм допускает поэтапную миграцию без немедленного уничтожения всего зависимого кэша.

Если referral пропал, относится к другой точке, либо NS или применимый DS совершенно новый, кэшированные данные в точке перепроверки и под ней использовать нельзя. Реализация может удалить их или закрыть доступ к старому поколению; результат должен быть таким, словно данных нет.

Тест намеренно не объясняет происхождение общего имени. Оно может принадлежать уходящему провайдеру, общей anycast-платформе, услуге регистратора или забытой зависимости. Совпадение не доказывает собственность, человеческое разрешение, исправность или отсутствие компрометации. Оно лишь даёт кэшу критерий непрерывности.

Ребёнок сообщает авторитетный NS, родитель отзывает мандат

Дочерняя зона авторитетна для NS своей вершины; родительский NS — referral. Редакция 14 предлагает отправлять явный NS-запрос ребёнку параллельно запросу, обнаружившему границу. После успеха последующие обращения должны предпочитать список ребёнка.

При ошибке или NODATA список родителя остаётся лучшим доступным. В оппортунистическом режиме ответ пользователю часто уходит до окончания проверки.

Однако ребёнок не может вечно продлевать собственный мандат. Родитель мог удалить делегирование или передать его другому оператору. Если резолвер обновляет только дочерний NS, старый провайдер способен удерживать кэш после переделегирования. Периодическое возвращение к родителю ограничивает ghost-domain риск.

У адресов своя достоверность. Glue помогает добраться до ребёнка, хотя часто неавторитетен. Полный, подписанный и DNSSEC-безопасный набор адресов можно кэшировать авторитетно; иначе нужны отдельные запросы. Когда все более достоверные адреса недоступны, низкоранговый glue допустим как последний путь.

Fallback сохраняет доступность, но мешает аудиту по одному снимку. Реальный маршрут зависит от достижимости, ранга, порядка ответов и момента завершения проверки.

Строгий режим и оппортунистический режим дают разные гарантии

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

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

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

Политика должна указывать глубину, режим, допустимый fallback и объём очистки. Фраза «revalidation включена» не описывает поведение при незавершённой миграции.

Три TTL и локальный нижний предел

Перепроверка запускается не позже кратчайшего из TTL родительского NS, родительского DS при его наличии и дочернего NS вершины. Время родителя ограничивает жизнь удалённого делегирования. Время ребёнка позволяет раньше пересмотреть его рабочий набор.

Одновременно резолвер должен установить разумный минимум, чтобы зона не навязала вычислительную нагрузку микроскопическими TTL. Универсального значения нет. Самый короткий опубликованный TTL не гарантирует одновременный отзыв во всех мировых кэшах.

Ошибки следует отрицательно кэшировать по RFC 9520, не повторяя их агрессивно. Дополнительные NS- и адресные запросы могут заметно увеличить нагрузку авторитетных серверов. Ограничение работы на один пользовательский запрос входит в защиту.

Сообщение о расхождении не устанавливает виновного

Если дочерний NS отличается от родительского, резолвер может сообщить по каналам RFC 9567 обеим сторонам. Редакция 14 предлагает специальный Extended DNS Error, но его номер остаётся TBD.

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

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

Квитанция для временного моста

При переходе от A к B разумно оставить один NS A и прежнего подписанта. Для кэша это непрерывность. Для эксплуатации мост обязан иметь цель и дату закрытия.

Квитанция разделяет старое, целевое и разрешённое промежуточное состояние. В ней перечислены родительские NS и glue, DS, дочерний NS вершины и авторитетные адреса. Общие имена и подписанты названы вместе с причиной и условием вывода.

Затем она связывает наблюдаемое изменение с контрольным процессом: ссылкой на операцию регистратора или реестра, старым и новым DNS-оператором, утверждающим окончательное удаление и владельцем отката. Квитанция не заменяет аутентификацию и не хранит секреты; она ведёт к её записи.

Три TTL, кратчайший триггер и предположение о минимуме резолверов указаны отдельно. Прекращение приёма конфигурации, удаление NS из родителя, конец авторитетных ответов и исчезновение трафика — разные события.

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

Резолвер не читает эту квитанцию, и IETF-проект её не требует. Она документирует то, что не входит в задачу пересечения: намерение, срок и ответственное завершение непрерывности.

Источники

  1. Перепроверка делегирования DNS-резолверами — редакция 14
  2. Карточка проекта в Datatracker
  3. История документа
  4. Активные документы DNSOP
  5. Устав DNSOP
  6. RFC 1034 — Концепции и средства доменных имён
  7. RFC 2181 — Уточнения спецификации DNS
  8. RFC 9520 — Отрицательное кэширование ошибок разрешения
  9. RFC 9567 — Отчёты об ошибках DNS
  10. Расширяемое делегирование DNS — редакция 11