Кратко

  • GSS-TSIG согласует контекст GSS через TKEY и защищает DNS-сообщения с помощью TSIG, но не решает, кому разрешено менять зону.
  • Полная доказательная цепочка отдельно фиксирует принципала, правило, допустимое действие, запись состояния, распространение и последующее наблюдение.

Разбор удобно начать не с атаки, а с обычной строки журнала: «проверка GSS-TSIG успешна». Это полезный факт. Он не отвечает, имел ли аутентифицированный принципал право удалить конкретную запись, сохранил ли первичный сервер изменение и получил ли его затем выбранный наблюдатель.

RFC 3645 задаёт два этапа. Сначала клиент и сервер переносят непрозрачные токены GSS-API в записях TKEY и вызывают GSS_Init_sec_context и GSS_Accept_sec_context. Контекст проходит состояния «не инициализирован», «согласуется» и «установлен». Затем GSS_GetMIC и GSS_VerifyMIC создают и проверяют подписи в записях TSIG. Текстовая версия недвусмысленно говорит: механизм предназначен для аутентификации, а не авторизации.

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

У компонентов тоже разные обязанности. RFC 2743 определяет абстракцию GSS-API, RFC 2930 — TKEY как средство установления ключей, RFC 2845 — исходную модель TSIG, а RFC 8945 обновляет её. RFC 4121 описывает механизм Kerberos v5 для GSS. Их совместная работа обеспечивает совместимость, но не заменяет политику администратора зоны.

Контекст ограничен во времени. RFC 3645 требует отдельный контекст для описанной связи клиента и сервера; число обменов зависит от базового механизма, а указанные циклы ограничены десятью попытками. Клиент переводит контекст в установленное состояние только после проверки финального подписанного ответа. Ошибка делает сообщение неаутентичным, истечение срока требует нового контекста, а не молчаливого наследования доверия.

Для совместимости документ рекомендует SPNEGO и требует поддержку Kerberos v5 в заданном профиле, допуская и другие механизмы. Защита зависит от реально выбранного механизма GSS. Поэтому запись gss-tsig без названия механизма, целевого имени, источника учётных данных, имени ключа, срока контекста, состояния защиты от повторов, партнёра и результата проверки недостаточна.

Граница полномочий описана в RFC 3007: администратор зоны задаёт политику, сервер применяет её, а проверка учитывает принципала и желаемое действие. По умолчанию изменение запрещено, если политика явно не разрешила его. RFC 2136 определяет предпосылки и операции Dynamic Update. Таким образом, подтверждённая личность — вход авторизационного решения, а не готовое решение.

Защита опубликованных данных — ещё один слой. RFC 4033 описывает аутентификацию происхождения и целостность DNSSEC-данных. Проверенная DNSSEC-ответная запись не восстанавливает полномочия прежнего обновления. И наоборот, аутентифицированный запрос на обновление не доказывает, что новое состояние сохранилось и стало видно в последующем запросе.

Реестр алгоритмов TSIG IANA координирует имя gss-tsig, а реестр параметров DNS — другие значения по процедурам, затронутым в RFC 6895. Наличие записи доказывает общее обозначение, но не активный контекст, локальное разрешение или совершённое изменение.

Исторические рамки проверяются по метаданным RFC Editor, карточке Datatracker, истории документа и поиску исправлений. Они не дают оснований утверждать нынешнюю распространённость или поведение конкретной реализации.

Работы Heng Lu о слоях реальности, минимальной общей спецификации и первичности работающего кода задают институциональный вывод. Стандарт создаёт общий технический минимум. Локальная политика выдаёт права. Реальный сервер и позднейшее наблюдение определяют существующее состояние. Слияние этих уровней превращает ограниченное свидетельство в мнимую власть.