Кратко

  • DNS Cookies поддерживают минимальное состояние DNS-транзакции, затрудняя атаки со стороны противника вне пути трафика: усиление, подделку и отравление кэша.
  • Действительный Server Cookie даёт серверу ограниченную уверенность: запрос пришёл с наблюдаемого адреса и содержит Client Cookie, встречавшийся в предыдущем обмене.
  • Механизм не противостоит наблюдателю на пути и не определяет пользователя, абонента, владельца устройства или аутентифицированный сервис за резолвером либо NAT.
  • Эксплуатации нужен журнал проверки DNS-запроса, который разделяет проверку cookie, сетевое наблюдение, идентичность резолвера и авторизацию.

Представим гипотетическую систему противодействия злоупотреблениям. Дом, офис или сеть доступа отправляет DNS-трафик через общий рекурсивный резолвер. Он обращается к anycast-сервису, получает Server Cookie, а затем предъявляет действительное значение с того же публичного адреса. Последующая система записывает это как доказательство того, что оба запроса сделал один клиент. Протокол установил более узкий факт: второй запрос несёт состояние, которое сервер может проверить по Client Cookie, наблюдаемому адресу, секрету и временному окну.

RFC 7873 определяет DNS Cookies как лёгкий механизм защиты DNS-транзакций. Он даёт ограниченную защиту от усиления отказа в обслуживании, подделки ответов и отравления кэша со стороны нападающего, который не может наблюдать обмен. Именно отсутствие доступа к пути трафика ограничивает эту гарантию.

Первый запрос содержит восьмибайтовый Client Cookie. После ответа последующие запросы могут передавать его вместе с полученным Server Cookie. Сервер способен отклонить или ограничить трафик, который не воспроизводит выданное состояние. Механизм развёртывается постепенно, работает с NAT и anycast и не требует заранее согласованной учётной информации для каждого интернет-клиента.

Поэтому RFC говорит о слабой форме аутентификации, а не о системе идентификации клиента. Маршрутизатор, мост, участник общей линии или иной наблюдатель на пути может видеть незашифрованный DNS-трафик и cookie. Пока значение пригодно, наблюдатель способен повторно его использовать. Cookie повышает цену подделки вне пути, но не превращает видимое предъявительское значение в удостоверение человека или организации.

RFC 9018 задаёт совместимую конструкцию Server Cookie. Версия 1 объединяет Client Cookie, поля версии и резерва, метку времени и IP-адрес клиента под Server Secret. Адрес участвует в вычислении, хотя не записан в значение cookie. Сервер проверяет результат тем же секретом.

Конструкция отвечает на точный вопрос: согласуется ли запрос с cookie, ранее созданным для данного Client Cookie и наблюдаемого адреса при действующих секрете и временном окне? Она не говорит, кто пользуется адресом. Несколько людей делят один резолвер, устройства выходят через один NAT. Процесс резолвера перезапускается, меняет Client Cookie или адрес. И наоборот, за стабильным адресом со временем меняются люди и полномочия.

Время входит в доказательство. RFC 9018 требует проверять метку в заданном интервале и рекомендует принимать примерно час в прошлое и пять минут в будущее. Для значения старше получаса серверу следует выпускать новое. Окно ограничивает повтор, но не является текущей эпохой авторизации учётной записи.

Anycast добавляет ещё одно различие. Участникам набора нужны совместимая конструкция и секреты для проверки результатов друг друга. RFC 9018 описывает три этапа смены: распространить новый секрет, продолжая выпускать со старым; начать выпуск с новым, проверяя оба; удалить старый после времени на обновление клиентов. Если cookie принят другим узлом, это подтверждает согласованность проверки на всех узлах, но не возвращение того же физического сервера, экземпляра резолвера или пользователя.

Правила приватности подтверждают границу. При смене адреса клиент обязан создать новый Client Cookie, а клиент за NAT может не узнать о смене публичного адреса. Непрерывность намеренно связана с сетевым контекстом и состоянием реализации. Превращение её в постоянный идентификатор клиента противоречит предпосылкам мобильности и приватности.

Более сильный механизм для сравнения — TSIG из RFC 8945. TSIG удостоверяет DNS-транзакцию кодом аутентификации между сущностями с заранее настроенным общим секретом. Он способен показать, что динамическое обновление или ответ пришли от одобренной стороны, владеющей ключом. Для этого требуются распространение и защита ключа и именованное доверительное отношение, которых DNS Cookies намеренно избегают.

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

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

Полезный журнал фиксировал бы Client Cookie, версию и метку Server Cookie, результат проверки, наблюдаемый адрес, отвечавший anycast-узел, поколение Server Secret, транспорт и видимость на пути, известный экземпляр резолвера, отдельно аутентифицированного пользователя или сервис, политику авторизации и время действия. Сам секрет никогда не записывается.

Так сохраняется реальная ценность. Действительные cookies помогают ограничивать частоту запросов, уменьшают возможности отражения и отсеивают явную подделку до дорогих проверок. Они также выявляют сбои смены секретов и рассогласование anycast-узлов. Польза появляется из понятной цепочки доказательств, а не из расширения за пределы модели угроз.

Источники

RFC 7873 — Domain Name System (DNS) Cookies; RFC 9018 — Interoperable DNS Server Cookies; RFC 8945 — Secret Key Transaction Authentication for DNS.