Кратко

  • RFC 3445 ограничил новые KEY значением протокола 3 для DNSSEC: запрос не мог выбрать внутренний подтип, а подпись включала все записи RRset.
  • Переход был намеренно несимметричным: авторитетная сторона прекращала писать старые значения, но читатель сохранял их при проверке, чтобы не изменить подписанный набор и не расколоть кэши.

Универсальный ящик без перегородок

В RFC 2535 RDATA KEY содержала флаги, октет протокола, алгоритм и открытый ключ. Значение 1 относилось к почте, 2 к IPsec, 3 к DNSSEC, 4 к TLS; 5–254 оставались доступными, а 255 означало любой протокол. DNS предлагал готовую распределённую полку.

Однако клиент запрашивал тип KEY, а не протокол внутри него. Сервер возвращал весь RRset имени. Подпись DNSSEC тоже охватывала набор целиком, а не нужную приложению часть. Назначений было много, но граница поиска, доказательства и кэширования — одна.

RFC 3445, опубликованный в декабре 2002 года после ограниченного экспериментального развёртывания, сделал из обнаруженной проблемы нормативную границу. Текст, запись RFC Editor, Datatracker, история, ссылки, последующие цитирования и опечатки доказывают документальную запись, но не масштаб внедрения.

Шесть различий под одной оболочкой

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

Смешанный RRset рос вместе с посторонними приложениями, увеличивал ответы и связывал независимые циклы ротации. Если программа игнорировала поле протокола, скомпрометированный прикладной ключ мог быть принят за ключ зоны. Правильная криптография не исправляет ошибочный выбор носителя полномочий.

RFC 3445 разрешил для новых авторитетных данных только протокол 3, зарезервировал все флаги кроме бита зоны 7 и закрыл 1, 2, 4, 255 и прежний свободный диапазон. Новые назначения требовали Standards Action. DNSSEC-применения из RFC 2930, RFC 2931 и RFC 3007 сохранялись; старое различие host/user — нет.

Не доверять — не значит удалить до проверки

Значение не-3 нельзя применять для аутентификации DNS, но запись следовало удерживать в наборе до проверки подписи. Подписывался исходный полный RRset. Если убрать член раньше, проверяются другие байты и SIG ломается; разные фильтры также оставляют кэши с несовпадающими наборами.

Отказ в смысловых полномочиях отличается от сохранения материала доказательства. Безопасная последовательность: закрыть старую запись, сохранить чтение, лишить значение авторитета и удалять лишь после подтверждённого схождения.

RFC 4033, 4034 и 4035 позднее заменили семейство 2535 и использовали DNSKEY. SSHFP, CERT и TLSA показывают специализированные контейнеры, но не единственную причинную цепочку. IANA подтверждает состояние реестра, а не код, внедрение или безопасность.

Общим должен быть контур доверия, а не только формат

Слои реальности Heng Lu разделяют зарегистрированное значение, действительность подписи, административную власть, работающий код и результат. Один контейнер не объединяет эти доказательства. Приоритет работающего кода объясняет роль эксперимента: запросы, подписи и кэши показали стоимость, скрытую аккуратной абстракцией, но не сделали код сувереном.

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

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

Источники