Кратко

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

Панель резолвера может назвать запрос «аутентифицированным», потому что его Server Cookie прошёл проверку. Следующая система превращает эту метку в личность абонента и снимает с запроса контроль, предназначенный для анонимного трафика. Вывод кажется логичным: сервер выпустил Cookie, отправитель вернул его, исходный адрес совпал. Но NAT операторского уровня может скрывать за этим адресом тысячи пользователей, общий рекурсивный резолвер — действовать от имени всей организации, а наблюдатель на пути — видеть тот же Cookie, пока он действителен.

Это не делает Cookie бесполезным. Он отвечает на более узкий вопрос: есть ли у запроса свидетельство того, что клиент с этим исходным адресом и этим Client Cookie ранее получил ответ от данного сервера или совместимого anycast-набора? Это утверждение о пути возврата и транзакции. Утверждение о личности требует другого доказательства и другого владельца контроля.

Действительный Server Cookie служит слабым свидетельством прежнего обмена

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

Поля Cookie играют разные роли. Клиент создаёт непредсказуемый Client Cookie и должен применять другое значение для каждого другого IP-адреса сервера; RFC 9018 рекомендует 64 бита энтропии. Сервер не выдаёт это поле как учётное удостоверение: он получает значение, выбранное клиентом, и позднее возвращает его. Server Cookie — токен обратного пути сервера. RFC 9018 фактически описывает его как MAC из Client Cookie, IP-адреса клиента, определённых полей версии и времени и секрета, известного серверу либо серверам по одному anycast-адресу.

Когда запрос возвращает действительный Server Cookie, сервер получает слабую уверенность, что клиент по этому адресу и с этим Client Cookie получил прежний ответ с данным значением. В совместимом anycast-сервисе его мог выпустить другой участник того же домена проверки. Слово «слабую» существенно: доказательство относится к контексту адреса и Cookie, а не к человеку, абоненту, профилю браузера или аппаратному корню доверия. RFC 7873, раздел 5.2 позволяет ослабить защиты против поддельных UDP-запросов, но не превращает DNS-опцию в общий протокол аутентификации.

Cookie не доказывает право на защищённое представление зоны, биллинговый счёт, освобождение от политики или лимит на человека. Операционная метка должна повторять утверждение протокола: «действительный Server Cookie для исходного адреса, Client Cookie, домена проверки и момента времени», а не «аутентифицированный пользователь».

Общий адрес разрушает удобное отождествление

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

RFC 9018 отмечает, что клиент за NAT может не заметить смену своего публичного адреса; сервер же способен видеть и потенциально отслеживать публичный адрес NAT-устройства, а предотвращение такого отслеживания не входит в область RFC. Поэтому адресное свидетельство может быть верным на сетевой границе сервера и одновременно слишком грубым для атрибуции абонента.

Использовать действительный Server Cookie как ключ лимита «на человека» означает слить разных пользователей за одним видимым контекстом. Использовать его как биллинговую личность — приписать долговременную ответственность значению, чей жизненный цикл определяется сетевым подключением и состоянием процесса. Ошибка не в Cookie; политика требует от него различения принципалов, для которого он не предназначен.

Мобильность создаёт обратную ошибку. Чтобы не отслеживать устройство между сетями и не обходить IPv6 Privacy Extensions, RFC 9018 требует не использовать Client или Server Cookie повторно после смены IP-адреса клиента. Новый Cookie после переключения может означать того же человека и то же устройство. Стабильный Cookie также не является постоянной личностью: он может лишь отражать стабильный процесс и подключение.

BADCOOKIE фиксирует ветвление, а не виновника

Недействительный Server Cookie — тоже более узкое свидетельство, чем предполагает его имя. RFC 7873 называет несколько причин: значение могло устареть, измениться могли адрес клиента или Client Cookie, anycast-кластер мог быть настроен неодинаково, либо могла иметь место попытка подмены источника. Сервер обрабатывает запрос так, как если бы недействительного Server Cookie не было. Протокол не выбирает одну из причин за оператора.

BADCOOKIE предоставляет путь восстановления. Клиент повторяет запрос с новым Server Cookie из ответа. Если свежий Cookie снова даёт BADCOOKIE, согласованность секретов или методов генерации в anycast-наборе становится правдоподобной гипотезой; RFC 7873 предписывает повторную попытку по TCP. Эта последовательность информативнее счётчика недействительных Cookies.

Полезная запись хранит возраст и метод старого Cookie, адреса, видимые каждой стороне, домен проверки или участника anycast, вновь выданное значение, следующий ответ и результат перехода на TCP. Один BADCOOKIE не отличает нормальное истечение срока, мобильность, неполную ротацию секрета и враждебный трафик.

Это особенно важно при смене секретов. RFC 9018 требует поэтапной ротации в anycast-наборе: участники изучают и проверяют новый секрет до выдачи значений с ним и сохраняют прежний на время перехода. Если один узел переключится слишком рано или забудет прежний секрет, клиенты могут получать попеременно валидные и невалидные ответы в зависимости от маршрута anycast. Называть таких клиентов атакующими — значит скрывать действительную ошибку контроля.

Cookies дополняют проверку DNS-транзакции

DNS Cookies не отменяют правила сопоставления ответов. RFC 5452 требует от резолвера сверять адреса источника и назначения, порт назначения, Query ID, имя, класс и тип ответа с ожидающим запросом до применения правил доверия DNS. Непредсказуемые исходные порты и Query ID также обязательны. Независимые поля расширяют пространство, которое должен угадать атакующий вне пути.

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

RFC 6891, раздел 6.1.1 определяет транспортную поверхность: EDNS — расширение между соседними узлами, а запись OPT переносит управляющую информацию для одной последовательности вопроса и ответа, не содержит DNS-данных и не должна кэшироваться, пересылаться или храниться в зонных файлах. Опция COOKIE принадлежит обработке транзакции, а не постоянному пользовательскому каталогу.

Граница с наблюдателем на пути столь же явна. Тот, кто видит незашифрованный DNS, может перехватить Server Cookie и использовать его против клиента в период действия. Серверный MAC мешает стороне вне пути без секрета создавать произвольные действительные значения; он не шифрует значение при передаче и не аутентифицирует каждого, кто может наблюдать и передавать на данном пути.

Построить запись, сохраняющую границу

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

Если сервис дополнительно аутентифицирует учётную запись или устройство, фиксируйте этот принципал его собственным методом и временем. Связь между личностью и DNS-транзакцией должна быть явной: какая аутентифицированная сессия породила какой запрос резолвера, в каком интервале и с какой неопределённостью при общем резолвере или NAT. Если такой связи нет, Cookie не должен её выдумывать.

Формулировки в панелях и алертах обязаны соответствовать свидетельству. «Действительный токен обратного пути» корректно. «Ранее достигнут этот исходный контекст» может быть корректно с адресом и временем. «Известный клиент», «доверенное устройство» и «авторизованный пользователь» требуют фактов, которых DNS Cookie не содержит.

Источники

  1. RFC 9018 — Interoperable Domain Name System (DNS) Server Cookies
  2. RFC 7873 — Domain Name System (DNS) Cookies
  3. RFC 5452 — Measures for Making DNS More Resilient against Forged Answers
  4. RFC 6891 — Extension Mechanisms for DNS (EDNS(0))