Кратко

  • Редакция 01 индивидуального Internet-Draft отмечает два назначения DNS RRTYPE, прошедшие Expert Review 20 августа 2026 года: десятичный тип 69 для UNECE и тип 70 для ISO. Кодовые точки уже находятся в реестре IANA, однако документ не стал RFC и не принят рабочей группой DNSOP.
  • В RDATA без изменений переносится код из внешнего стандарта или рекомендации, а год редакции, поправки и исправления намеренно не указываются. Для исторического толкования проект отсылает к версии реестра на момент начала RRSIG, хотя сама подпись не содержит ни идентификатора, ни хеша этой версии.

Представим сохранённый для расследования ответ DNS. Цепочка DNSSEC подтверждается, RRSIG действителен, значение RDATA совпадает с архивной копией. Тем не менее этого недостаточно, чтобы воспроизвести решение приложения: надо ещё знать, какая именно таблица внешнего владельца кодов использовалась в тот момент. После появления типов UNECE и ISO такой разрыв становится не частным свойством интеграции, а явной особенностью модели управления.

В реестре параметров DNS IANA номер 69 отведён UNECE, а 70 — ISO; обе строки датированы 20 августа 2026 года. Редакция 01 проекта загружена 9 сентября. Её приложение и официальное сравнение говорят, что по отношению к редакции 00 техническое изменение одно: документ теперь фиксирует завершённые назначения и Expert Review от 20 августа.

Статус спецификации при этом не следует повышать вместе со статусом номеров. Карточка Datatracker, история документа и API-запись показывают активный индивидуальный Internet-Draft без номера RFC, потока и ответственного Area Director. Пометка Standards Track выражает намерение авторов, но не согласие IETF и не принятие DNSOP.

IANA выделяет контейнер, а не удостоверяет его смысл

Согласно RFC 6895, раздел 3.1, для назначения DNS RRTYPE применяется Expert Review. RFC 8126, раздел 4.5 описывает это как профессиональное решение назначенных экспертов по установленным критериям. Опубликованные заявки UNECE и ISO документируют прохождение этого пути. Результат гарантирует уникальность типов, но не подтверждает истинность, юридическую силу или актуальность вложенного кода.

Проект сознательно не создаёт в IANA копию справочников UNECE и ISO. В записи UNECE дискриминатор может указывать, например, рекомендацию 16 для UN/LOCODE или 20 для единиц измерения. В записи ISO он может называть стандарт 3166-1, 4217 или 639. Сам код передаётся дословно. Издатель зоны не вправе сочинить отсутствующий код, а получатель неизвестного дискриминатора или значения должен сохранить и показать его без толкования, а не объявить всю запись ошибочной.

Так страница списков UNECE и система сопровождения ISO 3166 остаются источниками предметной власти. Аналогичное разделение уже знакомо по RFC 6116: ENUM использует страновые коды E.164, не превращая IANA в параллельного распорядителя международной нумерации.

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

Постоянный дискриминатор скрывает меняющуюся редакцию

Идентификаторы рекомендаций UNECE и стандартов ISO намеренно не включают год издания, поправки и corrigenda. ISO 3166-1 должен оставаться тем же элементом протокола после выпуска новой редакции. Это снижает хрупкость формата и облегчает дальнейшее сопровождение. Одновременно RDATA перестаёт быть точным указателем на исторический документ.

Вместо номера редакции проект задаёт требования на момент публикации: внешний реестр должен быть действующим, бесплатно общедоступным и пригодным для цитирования. Будущие спецификации того же семейства должны описывать правила прекращения действия и повторного назначения. Универсального правила нет. По тексту проекта, удалённые или объявленные нежелательными значения UNECE остаются опубликованными; выведенные из обращения валюты ISO 4217 сохраняют даты; идентификаторы ISO 639 повторно не выдаются; для ISO 3166 действует длительное резервирование, хотя повторное использование в истории встречалось.

Поэтому один и тот же набор символов может означать действующее значение, прослеживаемое историческое значение, временно зарезервированное значение или новое назначение. Решение об этой временной семантике принимает внешний владелец, а не подпись DNS.

RRSIG задаёт координату времени, но не адрес редакции

Если важна историческая точность, проект рекомендует читать код по версии внешнего реестра, которая действовала в момент Signature Inception покрывающего RRSIG. Это полезное правило выбора времени. Оно не является доказательством выбранного источника.

RFC 4034, раздел 3.1.5 определяет Signature Inception как самый ранний момент, когда RRSIG может аутентифицировать покрытый RRset. В подписи также есть срок окончания, алгоритм, метка ключа и имя подписавшей стороны. Там нет номера выпуска UNECE, редакции ISO, URL архива или хеша таблицы. RFC 9364 помещает эти поля в механизм подтверждения происхождения и целостности DNSSEC, но не расширяет его до хранения внешних стандартов.

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

В источниках нет сообщения об ошибочном разборе или неудачном внедрении, и здесь не предполагается такой инцидент. Это обычная граница между двумя видами доказательства: DNSSEC отвечает за подписанные данные, внешний владелец — за содержание своего кода.

Локальная квитанция сохраняет применённое толкование

Минимальное дополнение со стороны потребителя — квитанция разрешения внешнего реестра. В ней стоит хранить RRTYPE и дискриминатор, исходные код и значение, внешнего владельца, точную редакцию реестра либо URI получения со временем и хешем содержимого, начало и окончание RRSIG, подписанта и результат проверки, применённое правило вывода или повторного назначения, исход для неизвестного кода, версию политики издателя и локальное решение, использовавшее результат.

Квитанция ничего не сертифицирует за ISO или UNECE. Она лишь связывает решение с действительно прочитанным свидетельством. Если публикационная страница исчезнет, хеш и допустимая архивная копия покажут, какой материал применялся. Если код будет назначен снова, останется видна временная политика. Если RRset переподпишут, его семантическая история не перепишется автоматически.

Это соответствует идее минимальной общей границы в эссе Heng Lu Minimum Initial Specification: детерминированным становится только место зависимости, а правила и реализация остаются локальными. Из The Policy Mirror следует родственный критерий — значимый автоматический вывод должен воспроизводиться из правила, власти и свидетельства. Предложенная квитанция является моей редакционной рекомендацией, а не требованием IETF, IANA, UNECE или ISO.

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

Источники