Кратко

  • Если DS родительской зоны не соответствует DNSKEY дочерней, резолвер с проверкой DNSSEC может отклонить делегирование. Отметка SEP этого несоответствия не исправит.
  • SEP — лишь подсказка инструменту при выборе ключа. RFC 4034 и 4035 запрещают валидатору менять проверку подписей из-за этого бита; ключу для проверки RRset по-прежнему нужен Zone Key.
  • Эдвард Льюис — один из трёх авторов RFC 3757. Запись подтверждает его участие в работе над стандартом, но не единоличное авторство, конкретную реализацию или нынешнее место работы.

Намерение оператора и доказательство протокола

Ошибка начинается, когда операционный флаг принимают за доказательство правильного ключа. Если инструмент выбирает DNSKEY только из-за установленного SEP, он может подсказать оператору не тот ключ для подготовки DS; если родительская зона публикует DS, не соответствующую DNSKEY дочерней, проверяющий резолвер может отклонить делегирование. Сам SEP этот разрыв не устраняет: он обозначает предполагаемое назначение ключа, но не удостоверяет его и не меняет правила проверки DNSSEC.

RFC 3757 вышла в апреле 2004 года. Её соавторы — Олаф Колкман, Якоб Шлитер и Эдвард Льюис. Спецификация добавила SEP в поле флагов DNSKEY, чтобы обозначать ключи, предназначенные для роли безопасной точки входа. Среди возможных применений названы помощь при создании записей DS и отметка ключей для статической настройки. Но документ прямо указывает: протокол проверки DNS этот бит не использует. Поэтому SEP — не удостоверение подлинности ключа.

При подготовке DS программа подписи может выбрать помеченный SEP ключ из набора DNSKEY дочерней зоны. После этого оператору всё ещё нужно проверить, что рассчитанный DS соответствует выбранному ключу; родительская зона должна отдельно опубликовать нужную запись. Бит в дочерней зоне не подтверждает действие родителя и не удостоверяет корректность подписи. Валидирующий резолвер применяет правила DNSSEC, а не предпочтение инструмента.

Опубликованные в 2005 году RFC 4034 и RFC 4035 заменили RFC 3757, сохранив это различие. В RFC 4034 SEP назван подсказкой для программ подписи или отладки. RFC 4035 устанавливает, что наличие SEP не должно менять валидацию. Кроме того, SEP не заменяет флаг Zone Key: DNSKEY нужен и он, чтобы проверять подписи над наборами ресурсных записей. Первый флаг касается предполагаемой обработки оператором, второй — допустимой роли в проверке подписей.

RFC 6781 объясняет, почему операторы всё же учитывают SEP. В распространённой схеме его ставят на KSK, участвующий во взаимодействии с родительской зоной, и не ставят на ZSK. Однако некоторые системы используют один тип ключа для функций, которые схема KSK/ZSK разделяет. Инструменты, рассчитанные только на разделение, могут неверно классифицировать или выбирать записи. Предупреждение RFC служит основанием проверить конкретные программы, но не доказывает, что где-либо произошёл сбой проверки.

SEP не следует путать с битом REVOKE из RFC 5011. В ней описан автоматический механизм обновления якорей доверия с отдельным состоянием отзыва. Это другой процесс и другой флаг. SEP не обозначает отзыв и не служит правилом обновления якоря.

Записи о Льюисе дают ограниченную биографическую основу: RFC 3757 называет его одним из трёх авторов, профиль IETF Datatracker фиксирует этот RFC, а страница автора Internet Society предоставляет ограниченный профессиональный контекст. Источники не подтверждают, что он единолично разработал SEP или реализовал конкретный продукт. Упоминание ARIN в RFC историческое и не доказывает нынешнее трудоустройство. Сами RFC не измеряют долю внедрений, частоту ошибок или число инцидентов. Надёжный вывод уже: SEP помогает организовать работу с ключами, тогда как доверие опирается на опубликованную связь DS и проверку по протоколу.

Источники