Кратко

  • RFC 3397 назначил DHCP-опции 119 упорядоченный список доменов поиска. Клиент сначала объединял фрагменты по RFC 3396, а затем разбирал указатели сжатия RFC 1035 во всём агрегированном блоке.
  • Список действовал раньше DNSSEC. Принятый вредоносный суффикс мог создать другое полное имя, для которого владелец чужого домена выдавал законно подписанные записи: подлинный ответ на вопрос, не задуманный пользователем.

Строка myhost ещё не была DNS-именем, достаточным для однозначного запроса. Между коротким вводом и сетевым пакетом политика должна была выбрать доменный суффикс, составить FQDN и определить порядок попыток. RFC 3397 стандартизировал передачу такой политики от DHCP-сервера клиенту.

Документ вышел в ноябре 2002 года по стандартной процедуре и определил Domain Search как опцию 119. Её область ограничивалась DNS. Она не выбирала между разными службами имён: для их порядка существовал RFC 2937. Опция 119 сообщала только список доменов, которыми резолвер дополнял неполные DNS-имена.

Значение экономило место за счёт формата меток и сжатия из RFC 1035. Searchstring содержал последовательность доменных имён, а повторяющееся имя или его хвост можно было заменить двухоктетным указателем на прежнее вхождение. Например, второй домен с окончанием apple.com. не обязан был снова передавать те же метки.

Смещение указателя отсчитывалось от начала данных опции, без октетов кода и длины. Это была локальная ссылка внутри логического значения, а не обращение к внешнему DNS, адрес в другом пакете или сетевой маршрут. Именно границы этого пространства определяли правильность декодирования.

Логическое значение могло быть физически разделено. По правилам RFC 3396 несколько экземпляров опции 119 сначала объединялись в один блок данных. Лишь после этого разрешалось следовать указателям RFC 1035. Поэтому цель могла находиться за границей фрагмента: координаты относились ко всему агрегату, а не к отдельному полю.

В примере RFC имена eng.apple.com. и marketing.apple.com. распределялись по трём экземплярам опции. Второе имя завершалось C004 — ссылкой на смещение четыре в полном блоке, где начиналось apple.com.. Если разбирать каждый фрагмент отдельно, такой адрес выглядел бы недействительным. Сборка DHCP должна была предшествовать декомпрессии DNS.

Правило завершения запрещало додумывать недостающие байты. Каждый домен оканчивался нулевой корневой меткой либо корректным двухоктетным указателем. Если агрегат заканчивался посреди имени без одного из этих завершителей, частичное имя отбрасывалось. Узнаваемый префикс не доказывал остаток.

После декодирования вступала в силу политика резолвера. RFC 3397 опирался на предупреждения RFC 1535 и RFC 1536. Список поиска следовало задавать явно, а не выводить из имени узла. Строку с точкой сначала нужно было пробовать как полное имя, и лишь после неудачи добавлять локальные домены. К строке без точки суффикс мог добавляться сразу.

Здесь возникала подмена. Пользователь ожидал, что myhost станет myhost.bigco.com. Недобросовестный DHCP-сервер задавал roguedomain.com, и компьютер спрашивал myhost.roguedomain.com. Подделывать последующий DNS-ответ не требовалось: изменился предмет запроса.

RFC прямо отмечал, что DNSSEC не предотвращает такую атаку. Владелец постороннего домена мог опубликовать собственные записи и правильно их подписать. Проверка подтверждала подлинность данных для myhost.roguedomain.com, но не доказывала, что именно этот домен имели в виду пользователь или администратор.

Это не означало отказ криптографии. У каждого шага была своя власть. Локальные настройки определяли приоритет. DHCP предлагал список. Клиент принимал, при необходимости аутентифицировал и декодировал его. Резолвер строил кандидаты. DNS отвечал, DNSSEC проверял ответ, приложение использовало адрес. Позднее доказательство не могло задним числом разрешить раннее решение.

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

Защиты относились к правильному уровню: соблюдать поиск из RFC 1536, не позволять DHCP заменять вручную настроенные DNS-параметры и при необходимости требовать аутентификацию DHCP до принятия опции 119. Но даже удостоверенное DHCP-сообщение подтверждало отправителя, а не намерение конкретного пользователя.

Расследованию нужна отдельная квитанция на каждом переходе. Следует сохранять исходный короткий ввод, ручной и полученный списки, порядок, происхождение, сервер и решение аутентификации. Затем — фрагменты 119, агрегат RFC 3396, цели указателей, отброшенные имена и последовательность кандидатов. Только после этого связываются реальный DNS-вопрос, результат проверки, адрес и соединение приложения.

Наличие опции в захвате не доказывает принятие. Правильно разобранный список не доказывает применение. DNS-запрос может не сохранять исходный текст. Валидная подпись не объясняет происхождение суффикса. Если свести эти факты к одному «успешно разрешено», пропадёт именно тот переход полномочий, который требовал проверки.

Реестр параметров BOOTP/DHCP IANA фиксирует код 119 и тем самым согласованное назначение, но не внедрение. Текущий поиск RFC Editor не находит подходящих исправлений к RFC 3397; это не сертификат парсеров, приоритетов и работающих резолверов.

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

RFC 3397 учит не отрицать подписанный ответ, а точно понимать его доказательную силу. Он удостоверяет данные для уже выбранного имени. Чтобы установить правильность назначения, нужно доказать, кто и как сформировал вопрос.

Источники