Кратко

  • По RFC 3008 подпись данных становилась существенным доказательством DNSSEC лишь после проверки полей и соответствия ключу зоны; правильного криптографического результата было недостаточно.
  • Ключи узла и пользователя сохраняли роль в аутентификации транзакций SIG(0), а публичное состояние подписывал ключ зоны, отделяя личность инициатора от полномочия свидетельствовать за зону.

Подпись могла быть безошибочной и всё же исходить не от того свидетеля. Ключ совпадал, байты были целы, алгоритм давал правильный ответ. Оставался вопрос: имел ли этот ключ право представлять DNS-зону? RFC 3008, опубликованный в ноябре 2000 года, встроил этот вопрос в стандартную политику резолвера.

Документ называл одни подписи существенными, а другие — несущественными. Data SIG обычно покрывала RRset и могла участвовать в DNSSEC-валидации. Другая подпись могла служить приложению, не относиться ни к одному RRset или защищать сообщение как SIG(0). Несущественная подпись не обязательно поддельна; она просто не является звеном публичного доказательства зональных данных.

Такое деление сузило модель RFC 2535. Ранний DNSSEC при некоторых условиях позволял ключам зоны, узла и пользователя подписывать данные. Для динамического обновления это обещало полезную границу: узел подписывает добавленные им записи, а наиболее чувствительный закрытый ключ зоны остаётся офлайн.

Полный процесс не позволял удержать эту границу. Изменение защищённой зоны требовало новых подписей для SOA и NXT. Безопасное обновление из RFC 3007 уже нуждалось в онлайновой способности зоны подписывать. Если ключ зоны всё равно присутствовал и мог подписать принятые данные, публичное признание подписей узла не устраняло исходную экспозицию. Оно лишь заставляло каждый резолвер разбирать более сложные отношения полномочий.

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

Статус ключа зоны не заменял остальные условия. Type covered должен был совпадать с типом RRset. Алгоритм должен был быть известен клиенту и иметь определённый формат SIG. Число labels не могло превышать количество меток в имени владельца. Original TTL обязан быть не меньше текущего TTL подписи, потому что промежуточный сервер не вправе его увеличивать. Текущее время должно было находиться между inception и expiration.

Затем signer name, key tag и алгоритм находили кандидата KEY. Без совпадения подпись считалась несущественной. Если селекторы указывали на несколько ключей, все оставались кандидатами до криптографической проверки. Успешное вычисление не позволяло задним числом присвоить ключу подходящую институциональную роль.

У KEY были свои ограничения. Type flags должны были разрешать аутентификацию. Для существенной подписи данных name type обязан быть zone. Protocol должен был указывать DNSSEC или ALL. Алгоритм KEY должен совпадать с SIG. Один и тот же открытый материал мог правильно выполнить операцию, но не получить доверия, если запись назначала его другому протоколу или субъекту.

Этапы создавали разные квитанции. Криптография связывала ключ, подпись и вход. Проверка формы давала право на обработку. Тип ключа определял полномочие для класса объекта. Цепочка соединяла зону с известной точкой доверия. Временной интервал ограничивал срок. Даже всё вместе не доказывало доступность сервиса по адресу или истинность данных за пределами подписанного DNS-утверждения.

Для транзакций оставался отдельный путь. SIG с type covered, равным нулю, защищала DNS-сообщение и называлась SIG(0), подробнее описанной в RFC 2931. Транзакцию инициирует пользователь или узел, поэтому ожидаемым типом ключа был user либо host/entity. Даже сервер имён подписывал здесь как узел, а не как зона. Ключам зоны обычно не следовало создавать SIG(0).

Ключ узла не становился бесполезным — менялся объект его доказательства. Он мог аутентифицировать principal, отправивший запрос обновления. После этого primary применял локальную политику RFC 3007 по именам, RR-типам и действиям, начиная с запрета. При принятии изменения ключ зоны подписывал публичное состояние. Предложение, допуск и публичное свидетельство оставались разными властными действиями.

Резолверу не требовалась внутренняя политика доступа primary. Он не воспроизводил, какой клиент когда получил право записать каждый RR. Для опубликованных данных действовала общая зональная норма. Оператор мог менять разрешения обновления без изменения DNS-формата и без обучения всех резолверов новой схеме политики.

Старое поле signatory записи KEY намеренно не стало заменой. RFC 3008 не назначал ему значений и не требовал его наличия. Несколько бит выглядели переносимым описанием полномочий, но закрепили бы будущую политику в конечном перечислении и смешали допуск изменения с публичной проверкой. Локальная конфигурация на входе и правило ключа зоны на выходе оставляли ответственность видимой.

Модель принадлежала переходному поколению. RFC 3090 уточнил защищённый статус зоны в старой системе. RFC 3658 ввёл DS и изменил связь делегирования. RFC 4033, RFC 4034 и RFC 4035 позднее заменили поколение KEY/SIG из RFC 2535 и 3008.

Поэтому RFC 3008 нельзя выдавать за современное руководство, а его флаги — без пояснения переносить на DNSKEY и RRSIG. Отчёт RFC 3130 показывает, что в 2001 году DNSSEC воспринимался как набор компонентов, развивавшихся с разной скоростью. Это свидетельство перехода, а не повсеместного внедрения или измеренного эффекта одного документа.

Исторически сохранился порядок решения. Доказательство не приносит с собой полный мандат. Работающий код резолвера должен совместить роль подписанта, покрытый объект, заявленное применение, время и путь доверия. Иначе математическая точность превращает владение ключом в невыданное право определять публичную истину.

Через оптику Running-Code Primacy Лу Хэна полномочие возникает, когда резолвер исполняет всю классификацию, а не когда встречает объект подписи. Общий минимальный слой — правило ключа зоны. Локальное исключение принадлежит принявшему его резолверу и не переписывает норму для остальных. Устойчивость требует отдельных квитанций вместо одного зелёного статуса.

RFC 3008 лишил подпись магии и добавил подотчётность. Операция доказывает контроль ключа; KEY объявляет назначение; место в зоне даёт роль; цепочка — происхождение доверия; часы — срок. Только их совпадение делает правильную подпись уполномоченным DNSSEC-доказательством для этого RRset.

Sources