Кратко

  • draft-levine-dnsextlang-14 предлагает описывать RRTYPE в TXT, чтобы многие новые типы поддерживались конфигурацией. Это индивидуальный Internet-Draft, а не RFC и не действующая служба IANA.
  • Флаг X сообщает о необходимости специальной обработки и помогает отказать при отсутствии функции. Он не доставляет код и не подтверждает реализацию.
  • DNSSEC удостоверяет происхождение и целостность RRset в рамках политики валидатора. Смысл, совместимость и разрешение на запуск требуют отдельных доказательств.

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

Draft решает реальную проблему: новый RRTYPE часто требует обновить master-file parser и provisioning. Stanza задаёт имя, номер, опции и поля. Сервер сможет переводить текст в RDATA, экспортёр — восстанавливать текст, интерфейс — строить формы. Реализация не исчезает; часть её переезжает в интерпретируемые данные.

Два имени не создают атомарную версию

Определение публикуется как одинаковые TXT по номеру в RRTYPE.ARPA и по имени в RRNAME.ARPA; возможен CNAME. Языковые варианты несут описания. При расхождении draft не задаёт победителя. Кэши, языковые записи, alias по умолчанию и локальный override могут показывать разные поколения.

В тексте есть заметная нестыковка: каталог назван _LIST.RRTYPE.ARPA, а пример использует _LIST.RRNAME.ARPA. Это вопрос к следующей редакции, а не приглашение продуктам молча выбрать разные варианты.

TTL не обеспечивает одновременное переключение. RFC 8767 допускает stale-ответы при ограниченных сбоях обновления. Draft этого не требует, однако квитанция должна различать текущий authoritative ответ, живой cache и stale fallback. Локальный файл также обязан иметь видимый hash и приоритет.

DNSSEC не проверяет смысл

Раздел безопасности упоминает spoofing и DNSSEC. RFC 4033 определяет аутентификацию происхождения и целостность RRset через trust anchor и цепочку. Успешная проверка показывает, кто опубликовал байты и что они не были незаметно изменены. Она не сравнивает две копии, не тестирует длины, backend, parser или намерение оператора.

Публикация, аутентификация и активация — разные акты. Подписанная ошибка остаётся ошибкой. Поэтому DNSSEC нельзя превращать в автоматическое разрешение на исполнение.

X обозначает границу

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

RFC 3597 уже задаёт TYPEnn \# длина hex и прозрачную работу с неизвестными типами без additional-section processing. Новый язык улучшает читаемость, формы и табличное преобразование. Универсальная форма остаётся безопасным запасным путём.

Квитанция исполнения

Draft предупреждает, что неверные определения способны вызвать странные ошибки и обойти ограничения provisioning. Поэтому сохраняются: редакция документа; ответ каталога; hashes числовой, символьной и языковых версий; DNSSEC-политика; TTL, возраст и stale; override; версии сервера, parser и backend; модуль для каждого X; положительные, отрицательные и ресурсные тесты; bytes преобразования text–wire–text; загрузка изолированной зоны; authoritative query; область включения и rollback.

Это эксплуатационная модель статьи, а не нормативное требование draft. Подпись не заменяет тест. Тест не заменяет загрузку. Загрузка не заменяет ответ. Один ответ не означает конвергенцию парка.

Разделение делает сбой ремонтируемым: конфликт имён относится к reconciliation, неизвестный token — к admission, изменившиеся bytes — к codec, различие canary и production — к deployment.

Общий слой должен быть тонким

Централизуются грамматика, связь имени и номера, семантика полей, язык, регистрация и обязательные инварианты. Backend, лимиты, время активации, специальная логика и откат остаются у оператора.

Это соответствует минимальной начальной спецификации Heng Lu: общим становится лишь необходимое для совместимости, последующие решения локализуются, а добровольное принятие подтверждает running code. Видимый override и RFC 3597 fallback допустимы; невидимая разница поколений — нет.