Кратко

  • DNS сравнивает буквы ASCII без учета регистра, хотя многие серверы дословно копируют вопрос в ответ. DNS-0x20 пытался превратить такое эхо во временный признак конкретной транзакции.
  • Один подходящий символ давал не более одного бита, а нормализация по пути могла удалить весь рисунок. Механизм требовал очистки до распаковки и защищенного от принуждения отката, не аутентифицировал ответ и остался просроченным Internet-Draft.

Имя оставалось прежним, память резолвера — нет

Перед отправкой запроса резолвер может случайно менять регистр каждой буквы имени. Авторитетный сервер обязан найти тот же RRset независимо от получившейся последовательности. Когда приходит ответ, резолвер проверяет уже не только эквивалентность имени, но и точное совпадение Question с сохраненным вариантом.

Это две проверки с разными полномочиями. Первая определяет объект в пространстве имен. Вторая связывает пакет с незавершенным запросом. Внешний наблюдатель может знать запрашиваемое имя, но не обязательно знает написание, возникшее лишь в момент отправки.

Именно так DNS-0x20 использовал регистр. Он не делал заглавную форму отдельным именем, а занимал незначащую форму в качестве краткоживущего состояния.

Старый компромисс сохранил представление

RFC 1035 в 1987 году потребовал выполнять официальные сравнения DNS без учета регистра. Имена, отличающиеся только A-Z и a-z, идентичны. Но документ одновременно предписал по возможности сохранять исходный регистр и сводить его потерю к минимуму.

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

RFC 4343 уточнила, что речь идет о буквах ASCII, а не о любых языковых преобразованиях и не об IDNA. Сохранение формы не гарантируется: разные варианты могут занимать одну запись, а сжатие имен может заимствовать написание метки из другой части сообщения.

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

Бит 0x20 стал одноразовым выбором

Internet-Draft Use of Bit 0x20 in DNS Labels от марта 2008 года предложил случайно менять бит 0x20 каждой буквы ASCII в QNAME. Именно он различает верхний и нижний регистр. Сервер складывает все варианты при поиске, а отправитель различает их, пока ожидает ответ.

Метод опирался на точное копирование Question. Авторы сообщили, что испытанные ими крупные авторитетные реализации 2008 года возвращали имя бит в бит. Тогдашние спецификации не обязывали делать это с регистром, а некоторые реализации приводили вопрос к нижнему регистру.

RFC 5452 описывает более широкий контекст. Принимаемый ответ должен соответствовать вопросу, идентификатору, адресам, портам, классу и типу. Случайный 16-битный ID все равно задает конечную цель; непредсказуемый исходный порт расширяет пространство. Регистр должен был добавить еще несколько одновременно угадываемых решений, уже находящихся в QNAME.

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

Бюджет определяло само имя

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

Флаг «0x20 включен» не отражает фактическую силу. Нужно считать буквы конкретного вопроса, оценивать непредсказуемость выбора и измерять, сколько битов вернулось без изменений.

Международные метки не позволяют механически расширить расчет. RFC 4343 отделяет ASCII-сравнение от IDNA. Применение языковых правил регистра к сетевому значению способно изменить обрабатываемое имя, а не создать эквивалентную пробу.

Исправный посредник мог уничтожить пробу

DNS-форвардер, переводящий вопросы в нижний регистр, может вернуть правильные данные для правильного имени. С точки зрения базовой семантики он работает. Для 0x20 он стер ожидаемое состояние.

Так привычка реализации превращалась в сквозную зависимость. Резолвер создает рисунок, но авторитетные серверы, форвардеры и инспектирующие устройства определяют, сохранится ли он. Перечень испытанных в 2008 году продуктов не гарантирует поведение всех последующих путей.

Несовпадение также не объясняет причину. Возможны подделка, постоянная нормализация, особенность маршрута или ошибка. Проект советовал журналировать событие, отбросить ответ и попробовать другие авторитетные адреса. Измененный регистр сам по себе не был доказательством отравления.

Случайная форма не должна была пережить транзакцию

DNS использует указатели сжатия. Имена в Answer, Authority и Additional могут ссылаться на байты Question. Если распаковать ответ, пока случайный рисунок остается в вопросе, форма может попасть в кэш и затем появиться в чужих ответах.

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

В этой последовательности заключена общая инженерная граница. Если допустимая вариативность формата становится nonce, нужно определить момент ее удаления. Генерация без очистки превращает защиту одной операции в загрязнение общего состояния.

Откат мог стать удаленным переключателем

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

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

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

DNSSEC устраняет тот же самый разрыв

RFC 4034 определяет каноническую форму RR для DNSSEC: сжатые имена разворачиваются, а относящиеся к ним заглавные ASCII-буквы становятся строчными. Подписант и валидатор должны получить одинаковую последовательность октетов.

0x20 хотел сохранить случайное различие на одну поездку. DNSSEC удаляет различия, чтобы аутентифицировать канонические данные. Точное эхо увеличивает цену слепой догадки; корректная подпись может связать RRset с цепочкой полномочий. Это не взаимозаменяемые свойства.

История просроченного проекта

DNS-0x20 истек в сентябре 2008 года. Он не стал RFC и не доказывает современные настройки или повсеместное развертывание. Заявления о реализациях относятся только к тестам авторов того времени.

Историческая ценность проекта в ином. Различие, исключенное из идентичности ради совместимости, может оставаться доступным как временное состояние. Но его нужно измерять, сохранять по всему нужному пути, защищать от принудительного отката и удалять до долговременного хранения.

Заглавные буквы не изменили, что означает имя. В пределах одного запроса они изменили, какой ответ резолвер согласился считать своим.

Источники и ограничения

Материал опирается на RFC 1035, RFC 4343, RFC 5452, RFC 4034 и Internet-Draft DNS-0x20 от марта 2008 года. Эти документы не устанавливают нынешнюю долю внедрения, настройки продуктов по умолчанию или универсальную совместимость.