Кратко

  • RFC 2845 включил MAC запроса в MAC подписанного ответа DNS, вызванного этим запросом.
  • В многочастном обмене DNS/TCP накопительный MAC покрывал предыдущий MAC и следующие сообщения по порядку; TSIG ставился в первом и последнем сообщении и как минимум через каждые сто сообщений.
  • Позднее RFC 8945 потребовал от отправителя добавлять TSIG в каждое сообщение ответа, сохранив для проверяющих ограниченную совместимость с неподписанными промежуточными сообщениями. Ни одна версия не превращает аутентификацию транзакции в конфиденциальность, истинность данных или локальное разрешение.

Ответ не был отдельным пакетом

Идентификаторы и коды ответа DNS описывали обмен, но не аутентифицировали собеседника и не защищали транзакцию от изменения. RFC 2845, опубликованный в мае 2000 года, добавил TSIG — метазапись в сообщении DNS, проверяемую с помощью общего секрета. Область применения намеренно ограничили парой взаимодействующих узлов: у обоих уже должен был быть настроен один и тот же ключ, а его распространение осталось вне спецификации.

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

Эта связь говорила лишь о покрытых байтах и отношении ключей. Поскольку секрет общий, успешная проверка показывала соответствие сообщения настроенному ключу, но не устанавливала, какой человек или процесс им владел. TSIG не шифровал DNS и не решал, следует ли разрешить обновление. Операцию DNS UPDATE задавал RFC 2136; локальная политика по-прежнему должна была решить, может ли аутентифицированный узел менять зону.

Передача зоны стала последовательностью сообщений

Сложнее всего было обрабатывать ответ из нескольких сообщений, например передачу зоны по TCP. Если проверять каждый пакет изолированно, терялась упорядоченная связь между ними. RFC 2845 требовал TSIG в первом и последнем сообщениях и как минимум одну подписанную контрольную точку на каждые сто сообщений. Между контрольными точками сообщения DNS по порядку включались в следующий расчет MAC вместе с предыдущим MAC и относящимися к делу временными полями.

Проверяющий устанавливал непрерывность ограниченного участка потока, а не независимую подпись каждого промежуточного сообщения. При провале проверки RFC предписывал закрыть TCP-соединение и считать передачу прерванной, но не задавал точный порядок повтора. Действительная контрольная точка подтверждает часть полученной последовательности, а не то, что сервер позднее зафиксировал, или что вторичный сервер впоследствии выдал клиентам.

Правило изменилось, граница осталась

RFC 4635 добавил идентификаторы алгоритмов HMAC-SHA к исходному варианту HMAC-MD5. В 2020 году RFC 8945 заменил RFC 2845 и RFC 4635 как интернет-стандарт STD 93. Правило отправки стало строже: соответствующий спецификации отправитель подписывает каждое сообщение ответа. Правило совместимости для проверяющего другое: он должен принимать до 99 неподписанных промежуточных сообщений, требуя подпись первого и последнего. Эта допустимость не дает современному отправителю права пропускать подписи.

RFC 8945 прямо обозначает и предел доказательства: TSIG аутентифицирует передачу между двумя узлами, знающими общий секрет, но не происхождение и не корректность исходных данных. Это не DNSSEC, который аутентифицирует данные по иной модели доверия. TKEY может применяться для установления ключей, однако распространение ключей не входит в сам TSIG. Стандарты описывают ограниченный механизм, а не универсальный знак доверия.

Источники: RFC 1035; RFC 2104; RFC 2845; RFC 8945; RFC 4635; RFC 2136; RFC 2930.