Кратко

  • RFC 1535 описал резолверы 1993 года, превращавшие некорневое имя в упорядоченный ряд кандидатов. Ответ под случайным публичным суффиксом мог остановить поиск до проверки задуманного абсолютного имени.
  • Исправление ограничивало полномочия: неявное расширение оставалось в локально управляемом пространстве, имя с точкой сначала проверялось как корневое, а дополнительные сокращения требовали явной настройки.
  • Для аудита нужно раздельно хранить ввод, конечную точку, policy и её эпоху, кандидаты, ответы, выбор, endpoint, аутентификацию и результат приложения. Конечный IP не заменяет эту цепочку.

В DNS ушёл не тот объект, который видел человек

В примере RFC 1535 пользователь на Machine.Tech.ACES.COM вводил UnivHost.University.EDU. Имя казалось достаточно подробным. Но без завершающей корневой точки некоторые резолверы на основе BSD BIND считали его частичным и пробовали:

  1. UnivHost.University.EDU.Tech.ACES.COM.
  2. UnivHost.University.EDU.ACES.COM.
  3. UnivHost.University.EDU.COM.
  4. UnivHost.University.EDU.

Первый найденный ресурсный record прекращал последовательность. Четвёртый кандидат соответствовал вероятному намерению, но третий принадлежал другому публичному ответвлению и стоял раньше. Значение определял порядок, которого не было в видимой строке.

Пакеты могли быть безупречны, а каждый кандидат — синтаксически допустим. Решающее изменение происходило до сети: локальная policy дополнения подменяла предмет вопроса.

Конечная точка закрывала дополнение, но не доказывала личность

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

Конечная точка сообщала только: больше не добавлять суффикс. Она не аутентифицировала оператора, не подтверждала свежесть ответа, сертификат или итог приложения. Некорневое имя, напротив, могло быть безопасным внутри сознательно ограниченной локальной policy.

Поэтому исходная строка и правило её завершённости — разные receipts. Пунктуация не должна превращаться в универсальное доказательство идентичности.

EDU.COM отвечал в пределах своей зоны

RFC 1535 сообщил, что после регистрации EDU.COM wildcard CNAME в этом частном поддомене мог направить соединения от сайтов .COM к именам .EDU на одну машину. Конкретное harvard.edu.com позволяло показать похожее приглашение входа.

Datatracker, запись RFC Editor и страница errata подтверждают Informational-документ октября 1993 года. Они не измеряют число клиентов, передачу credentials или нынешнее состояние домена.

Оператор EDU.COM не обязан был выходить за делегированную область. Сгенерированный вопрос действительно оканчивался на EDU.COM.. Резолвер взял ввод, похожий на адрес в .EDU, добавил .COM и поставил этот новый вопрос перед корневой формой.

DNS authority следовала фактическому имени запроса. Намерение человека следовало строке на экране. Скрытый генератор кандидатов раздал между ними полномочие.

Умение подниматься по дереву не давало права на предков

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

На starburst.astro.DESERTU.EDU локальный владелец мог разумно расширить chief.admin до chief.admin.astro.DESERTU.EDU. и chief.admin.DESERTU.EDU.. Он контролировал оба пространства. Продолжение до chief.admin.EDU. передавало интерпретацию внешней стороне.

Минимальным решением RFC 1535 был параметр локального scope. Последовательный поиск допускался внутри него и останавливался на границе. Университет не получал власть над .EDU; он определял сокращения только под реально управляемыми именами.

Это соответствует минимальной начальной спецификации Lu Heng: общий механизм координирует необходимое, а будущий выбор остаётся локальным, добровольным и отзывным.

BIND 4.9.2 потребовал явного автора дополнительных путей

Документ говорил, что широкая проблемная функция была по умолчанию отключена в официальном BIND 4.9.2. Строгое неявное правило сокращало набор. Если ввод содержал хотя бы одну точку, сначала следовало пробовать корневую форму; другие варианты задавались явно.

Организации, привыкшие к многосоставным локальным сокращениям вроде bar.loc2 внутри org.city.state.us, могли потерять удобство до добавления нужного search domain. RFC 1535 не скрывал цену совместимости.

Изменился собственник решения. Раньше программа угадывала цепочку по месту хоста. Теперь администратор должен был назвать пространство, которое способен контролировать. Явная настройка тоже может быть ошибочно доставлена DHCP, VPN или контейнером, но у неё есть владелец, версия, граница и откат.

RFC 1123 ограничивал преобразование одним правильным контекстом

RFC 1123 считал сокращения необязательной интерфейсной функцией. Требовалось соглашение для полного имени. Преобразование выполнялось ровно один раз и в надлежащем контексте, чтобы почтовая система не применила собственный список повторно и канонизация не наращивала строку.

Список поиска был упорядоченными суффиксами, иногда для конкретного пользователя или процесса; администратор должен был уметь его отключить. Для ограничения нагрузки на root документ предлагал negative caching и/или минимальное число внутренних точек перед запросом к нелокальным серверам.

Меры отвечают на разные вопросы. Cache ограничивает повтор, порог — охват трафика, локальная граница — полномочия, однократность — исполнителя, root-first — порядок. Статус RFC 1123 подтверждает текст, но не все реализации.

Соседние ошибки DNS нельзя объединять

RFC 1536 и его запись разбирали быстрые повторы, циклы recursion, пустые ответы, недоступные серверы и утечки cache. RFC 1537 и его запись касались ошибок файлов данных DNS.

Это одна эпоха исправлений, но разные следы. Цикл повторяет запросы, плохая zone публикует неверные authoritative данные, RFC 1535 связывает ввод, правило и новые имена. Общая фраза «DNS сломался» уничтожает ответственного компонента.

RFC 1035 и информация о нём дают контекст сообщений и записей. Валидный ответ не доказывает намерение, аутентифицированный сервис или результат приложения.

Журнал начинается до первого DNS-пакета

Нужно сохранить исходный ввод, root-точку, вызывающее приложение и запрос на расширение. Затем — реализацию и версию резолвера, эпоху процесса или namespace, источник конфигурации, упорядоченный список, локальную границу и правило точек.

Для каждого кандидата нужны ранг, время, cache либо сеть, response code, authority, CNAME, адрес и TTL. Кандидат остановки, canonical name и endpoint — отдельные события. После них идут transport, сертификат или другая аутентификация, решение приложения и наблюдаемый эффект.

Секреты сохранять не требуется. Достаточны ограниченный fingerprint запроса, идентичность цели и результат authorization. Running-Code Primacy требует реальную последовательность, а Reality Layers не позволяют назвать конечный IP намерением пользователя.

Граница исторического вывода

Источники доказывают описание и предложение 1993 года. Они не называют современный уязвимый резолвер, не дают статистику развёртывания и не подтверждают завершённую атаку. Informational — статус документа. Конечная точка — не криптографическая аутентификация.

Долговечен узкий принцип: программа, молча дополняющая идентификатор, осуществляет власть над его толкованием. Эта власть должна быть локальной, явной, наблюдаемой и отзывной, а порядок и остановка — воспроизводимыми. Ввод, policy, вопрос, ответ и итог связаны, но не являются одним фактом.

Источники