Кратко

  • DNS Cookies превращает первый обмен в ограниченное свидетельство достижимости: последующий запрос с правильной парой токенов сложнее подделать атакующему вне маршрута.
  • RFC 7873 определил обмен, а RFC 9018 зафиксировал совместимый Server Cookie версии 1, чтобы разные реализации в одном anycast-наборе могли проверять общее состояние.
  • Механизм не устанавливает личность и не шифрует DNS. Наблюдатель на маршруте видит токены, NAT объединяет клиентов, а ограничения скорости и другие меры остаются обязательными.

В первом запросе нет учётной записи, сертификата или согласованного ключа. Приходит UDP-дейтаграмма с адресом источника, который может быть настоящим или подставным. Клиент добавляет восьмибайтовый Client Cookie в опцию COOKIE расширения EDNS. Поддерживающий сервер возвращает его вместе со своим Server Cookie. В следующем запросе клиент предъявляет оба значения.

Второй пакет несёт короткую историю. Server Cookie зависит от Client Cookie, видимого адреса клиента и секрета сервера. Атакующий вне маршрута может вписать адрес жертвы в IP-заголовок, но обычно не видит отправленный туда ответ и не получает нужный токен. Сервер получает лишь признак того, что уже обменивался данными с этой комбинацией адреса и cookie. Клиент, в свою очередь, может отбросить ответ без ожидаемого Client Cookie.

Это не идентичность. Домашний маршрутизатор, операторский NAT или корпоративный шлюз представляют множество устройств одним публичным адресом. Взломанная машина по правильному адресу остаётся опасной. Наблюдатель на маршруте видит cookie в открытом DNS и может повторить его в пределах срока. DNS Cookies не скрывает имя, не удостоверяет человека или организацию и не заменяет DNSSEC. Доказано только то, что обратный путь однажды сработал.

Такой вывод был полезен, потому что UDP DNS превращал подмену источника в усиление. Короткий вопрос мог вызвать более крупный ответ жертве. Поддельный запрос также заставлял рекурсивный сервер выполнять поиск и DNSSEC-проверку. В обратном направлении ложные ответы стремились опередить правильный и испортить кэш. DNSSEC удостоверяет данные; TSIG даёт более сильную защиту транзакции при управлении ключами; случайные порты и идентификаторы мешают слепому угадыванию; ограничение частоты сокращает выходной трафик. Cookies добавили лёгкое свидетельство возврата без клиентской таблицы на сервере.

В мае 2016 года RFC 7873 назначил COOKIE код 10 в EDNS. Пока Server Cookie неизвестен, клиент отправляет только восемь байтов. После обучения он добавляет серверное значение длиной от восьми до тридцати двух байтов. Исходный стандарт оставил точный способ построения реализации. Сервер мог пересчитать значение из источника, Client Cookie и секрета, не сохраняя отдельную сессию.

Автомат состояний допускает постепенное внедрение. Сервер без поддержки игнорирует опцию. Поддерживающий сервер, получив только Client Cookie, может отбросить запрос, вернуть BADCOOKIE или ответить нормально согласно политике; если отвечает, он сообщает Server Cookie для следующего состояния. Недопустимая длина даёт FORMERR. Старое или неверное значение рассматривается как отсутствующее. Верный cookie позволяет ослабить меры именно против подложного UDP-источника, но не отменяет общий контроль злоупотреблений.

BADCOOKIE — это переход, а не только ошибка. Если в ответе совпадает Client Cookie, клиент принимает новое серверное значение и повторяет запрос. Немедленный повторный отказ позволяет перейти на TCP. Серия таких отказов может раскрыть внутреннюю несогласованность: узлы одного anycast-адреса используют разные секреты, методы или фазы обновления.

NAT объясняет, зачем нужны обе части. Если бы Server Cookie зависел только от публичного адреса, одно устройство могло бы получить токен для всех соседей за тем же шлюзом. Участие Client Cookie различает потоки без персонального состояния на сервере. Различие остаётся сетевым и не определяет человека.

Anycast обнаружил более трудный пробел. Два последовательных запроса к одному адресу могут попасть на разные машины и продукты. RFC 7873 рекомендовал общий Server Secret, но не унифицировал вычисление. Две реализации с одинаковым секретом могли выпускать несовместимые токены. Обычная смена маршрута выглядела как подделка.

В апреле 2021 года RFC 9018 определил шестнадцатибайтовый Server Cookie версии 1: байт версии, три резервных байта, четыре байта времени и восемь байтов SipHash-2-4. Вместе с Client Cookie полная опция имеет ровно двадцать четыре байта. Расчёт охватывает Client Cookie, структурные поля, IP клиента и Server Secret. Адрес участвует в проверке, но не записывается в токен.

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

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

RFC 9018 изменил и Client Cookie: рекомендуются 64 бита энтропии отдельно для каждого IP сервера и запрет повторного использования после смены IP клиента. Это мешает стабильному идентификатору сопровождать устройство между сетями. Узел за NAT может не заметить смену публичного адреса шлюза; этот остаточный риск остаётся вне механизма.

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

Источники