Кратко

  • draft-hoffman-duj-06 задаёт точную ручную передачу действий DNS от сервиса через человека оператору, но прямо не предназначен для автоматических обновлений и не имеет криптографической защиты.
  • Валидность, полномочие учётной записи, атомарный commit, авторитетная публикация, сходимость кэшей и решение конечного сервиса должны оставаться разными состояниями.

Зелёный экран в неправильной точке цепочки

Пользователь вставил строку, панель разобрала её и показала успех. Внутренняя база зоны уже содержит новую запись. Команда проекта закрывает задачу: «DNS обновлён».

Через несколько минут внешний сервис всё ещё не видит значение. Возможно, авторитетный процесс загружает изменения асинхронно. Возможно, один secondary отстаёт. Возможно, рекурсор сервиса держит старый RRset до истечения TTL. Возможно, сервис запрашивает другую DNS-view. Ни один из этих сценариев не опровергает внутренний commit, но и commit не опровергает их.

DUJ не обещает решить эту часть. Его задача уже и полезнее: заменить неоднозначную человеческую инструкцию точным пакетом добавлений и удалений. Ошибка возникает, когда удобный формат начинает обозначать все последующие результаты сразу.

Минимальная структура вместо свободного текста

Внешнее значение DUJ — массив из двух элементов. Первый равен DUJS или DUJ64; второй — непустой упорядоченный массив обновлений. Каждый шаблон содержит ровно действие add или delete и record-data в формате зонного файла RFC 1035.

В DUJS данные частично читаемы, но комментарии, директивы и встроенные переводы строк запрещены. DUJ64 передаёт те же данные в Base64: сложные кавычки и escape-последовательности меньше страдают от копирования, зато обычный пользователь не видит смысл без декодирования. Вид действия сохраняется.

Массивы вместо расширяемого объекта не дают добавить поле «срочное обновление безопасности» и представить убеждение как часть протокола. Будущая семантика требует нового начального идентификатора.

Это уменьшает ошибки представления. Base64 при этом не шифрует, I-JSON не подписывает, а синтаксически допустимый RRtype не выдаёт полномочий.

Кто принёс строку и кто вправе менять имя

Сначала сервис показывает пакет человеку. Затем человек входит к DNS-оператору и вставляет его. Проект ограничивает подлинность источника и целостность каждого участка качеством соответствующего соединения.

Аутентифицированная сессия оператора говорит, какая учётная запись отправила байты, но не обязательно какой сервис их создал. Настоящая сессия сервиса не доказывает, что человек уполномочен менять каждый FQDN. Имя может находиться за zone cut, где право на родительскую зону уже не действует.

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

Атомарность не выносит вердикт о цели

Все действия упорядочены. Оператор должен заранее установить, что весь DUJ можно применить к целевой зоне атомарно. Если одна операция мешает целому, нельзя выполнять остальные. Так старое значение не удалится без установки замены.

Полностью согласованный пакет может быть вредным. Устаревшая заявка может commit-иться идеально. Инструкция для другого клиента может быть безупречной по синтаксису. Атомарность отвечает за совместность действий, а не за правомерность намерения.

Поэтому после разбора оператор обязан проверить полномочие пользователя на зону. Он может запрещать неизвестные типы локальной политикой, даже если RFC 3597 позволяет их представить. Он может отклонить любой пакет, например добавляющий и затем удаляющий одну запись, и должен понятно объяснить отказ в UI.

Общий формат остаётся тонким. Решение остаётся там, где работает зона.

Повтор может быть успехом без изменения

При повторной отправке точная запись для add уже может существовать, а цель delete — отсутствовать. Проект допускает пропуск таких действий, требует проверки точного состояния и рекомендует сообщать пользователю обо всех сделанных изменениях.

Поэтому квитанция должна раскрывать результат, а не только код успеха. Практический вариант связывает хеш пакета, учётную запись, зону, основание полномочия, решение политики, RRset до и после, пропущенные действия, идентификатор атомарной транзакции и время. Это рекомендация настоящей статьи, а не норма редакции 06.

Далее нужна отдельная квитанция наблюдения: ответ авторитетного сервера и, если от этого зависит решение, взгляд нужного рекурсора или конечного сервиса. Только так внутренний commit не будет изображать публичный и коммерческий результат.

Что означает статус редакции 06

Редакция загружена 26 сентября 2026 года и истекает 30 марта 2027 года. Datatracker показывает активный индивидуальный Internet-Draft без RFC stream и без формального положения в стандартизации IETF. Намерение Standards Track в тексте не является принятием WG, консенсусом IETF, одобрением или RFC.

Замороженный diff между 05 и 06 меняет лишь номер и даты. Источники не подтверждают реализацию, совместимость, внедрение, производительность, инцидент, атаку или деловой результат.

Источники