Кратко

  • IQUERY переворачивал обычную структуру DNS: запрос помещал resource record в Answer, а сервер возвращал соответствующие owner names в Question.
  • Полномочия DNS следовали за именами и границами зон, а не за произвольными значениями записей, поэтому локально правильный список не мог подтвердить глобальную полноту.
  • Полное сканирование, дополнительные индексы, несовместимость с обычным cache, огромные ответы и раскрытие данных делали слабое обещание дорогим; PTR в IN-ADDR.ARPA превращал обратное отображение адреса в обычный делегируемый запрос имени.

Ответ находился в сообщении раньше вопроса

Обычная query DNS содержит QNAME, QTYPE и QCLASS в секции Question. Сервер добавляет подходящие RR в Answer. IQUERY начинался иначе: Question был пуст, а Answer мог содержать A IN 10.1.0.52. Клиент спрашивал, для каких имен этот record стал бы ответом.

RFC 1035 назначил операции opcode 1. Owner name и TTL предоставленного RR не имели значения; короткая root label могла служить заглушкой неизвестного имени. В response сервер помещал ноль, один или несколько наборов QNAME, QTYPE и QCLASS в Question и приводил исходную запись к первому совпадению.

На уровне wire format возникала красивая обратимость. Стандартная операция шла от имени к ресурсу, inverse query — от ресурса к именам. Одни и те же секции сообщения позволяли выразить оба направления.

Распределенная архитектура не обладала такой обратимостью. Resolver с известным именем может двигаться по referrals от root к зоне, ответственной за имя. Адрес, MX target или строка внутри другого RR не содержит сопоставимого пути ко всем зонам, где это значение может встречаться. Выбрать сервер приходилось до того, как клиент мог узнать, обладает ли он нужным набором.

Ограничение было известно с 1983 года

RFC 882 прямо говорил, что domain system не может гарантировать полноту или уникальность inverse queries, поскольку он организован по domain names, а не по host addresses или другим resource types. Для гарантии resolver должен был обратиться к серверу, заведомо имеющему соответствующие данные, либо опросить все серверы интересующего domain.

Это не временная оговорка о скорости ранних компьютеров. Отсутствовал маршрут к authority по ключу поиска. Для имени делегирование само является частью DNS: parent указывает следующего ответственного. У произвольного значения нет parent, referral или естественной границы, последовательно сужающей пространство поиска.

RFC 883 поэтому описывал inverse queries как зависимые от среды. Организация могла направить свои resolvers к серверам с достаточно полной копией собственных зон. Такой инструмент помогал администрированию и диагностике, но не становился источником полномочий для всего namespace.

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

Реальная граница проходила по знаниям выбранного сервера

RFC 1035 ограничивал response именами, обладающими RR, которые name server знает. Ни одна машина не знает весь domain space, поэтому результат нельзя считать полным. Документ предназначал IQUERY главным образом для database management и debugging и запрещал считать его приемлемым общим способом перехода от host address к host name.

Ноль совпадений означал лишь, что выбранный сервер ничего не нашел в доступном corpus. Это не доказывало глобальное отсутствие. Один ответ подтверждал наблюдаемую связь, но не уникальность. Тысячи ответов могли по-прежнему отражать только локальные authoritative zones, случайные cache entries или RR types, для которых был построен индекс.

Обычный отрицательный ответ DNS имеет понятную область действия. Запрошенное имя приводит к authoritative zone, и ее сервер может говорить о существовании имени в этой зоне. IQUERY не определял множество «все записи с этим значением». Для доказательства отсутствия пришлось бы исключить каждую потенциальную зону.

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

Обратный доступ создавал вторую базу рядом с первой

Name servers естественно хранят RR под owner names, потому что стандартные queries начинаются с QNAME. Быстрый поиск по содержимому RDATA требует другого пути доступа.

RFC 883 описывал inversion tables для отдельных зон и ключей. Изменение зоны могло требовать их перестройки. RFC 1035 предлагал выбор: exhaustive search основной базы или отдельная база, индексированная по значениям первой. Сканирование тратит CPU на каждый request; индекс постоянно потребляет memory, синхронизацию и дополнительную сложность.

Сравнение также зависело от RR type. RDATA может содержать address, domain name, character string или составную структуру. RFC 1035 рекомендовал case-insensitive comparison, где это возможно, но признавал, что сервер может хранить octets, не понимая, являются ли они текстом. «Найти это значение» не было одной универсальной операцией.

Издержки распределялись несимметрично. Удаленный requester отправлял короткий ключ. Оператор оплачивал индекс, scan, сборку и передачу. Query не доказывал пользы для зоны и не имел естественного предела числу совпадений.

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

Cache повторял локальный взгляд, не расширяя его полномочия

DNS масштабируется благодаря повторному использованию RRsets до истечения TTL. Результаты IQUERY плохо вписывались в этот механизм. RFC 1035 предупреждал, что их нельзя кэшировать так же, как обычные answers.

Multihomed host может иметь несколько address RR одного типа. Найденное по одному адресу имя не обязательно сопровождается полным RRset. Если cache сохранит извлеченную связь как обычный ответ под восстановленным QNAME, частичная выборка по значению превратится в кажущийся полным набор по имени.

Теряется и исходный corpus. Response могла отражать несколько зон и случайную часть cache одной машины. После распространения потребитель видит значение, но не видит разделы, которые никогда не проверялись. Большее число копий снижает стоимость доступа, однако не увеличивает область доказательства.

В нормальной query lookup key, delegation, authority, cache key и TTL согласованы вокруг имени. IQUERY повторно использовал envelope, но разрушал это согласование. Любая оптимизация должна была сохранять неудобную оговорку: только то, что эта машина знала в этот момент.

PTR дал обратному ключу имя

Успешный reverse mapping адресов появился не благодаря улучшенному глобальному поиску значений. RFC 1034 описывает IN-ADDR.ARPA: octets IPv4 address записываются в обратном порядке как labels специального domain, а PTR под полученным owner name указывает на другой domain name.

Для 10.1.0.52 resolver строит предсказуемое имя в reverse tree и выполняет стандартную query. Ветви дерева делегируются. Authoritative servers можно найти, RRset кэшируется с обычным TTL, отрицательный результат получает смысл внутри установленной зоны.

Indirection и есть архитектурное исправление. PTR не обещает, что запись есть у каждого адреса, что имя одно или что оно аутентифицирует машину. Он делает более узкое утверждение: обратная связь публикуется под owner name, для которого DNS уже умеет находить ответственность.

IQUERY требовал от системы обнаружить неизвестный индекс, начиная со значения. PTR требует от ответственного за reverse space опубликовать явную связь в известном месте. Открытый поиск превращается в делегированное чтение.

Честному клиенту нужна была полнота, злоупотреблению — нет

В 2002 году RFC 3425 объявил IQUERY полностью obsolete. Операцию не реализовали повсеместно, а операторы часто отключали старую поддержку. Документ упоминает bugs в редко исполняемом code, нагрузку на database и раскрытие больших наборов names.

Некоторые значения могли соответствовать огромным множествам. Поиск всех domains, делегированных nameserver крупного провайдера, мог дать десятки тысяч tuples и megabytes ответа. Маленький request вызывал несоразмерное вычисление и передачу, пригодные для denial of service.

Inverse MX queries позволяли агрегировать множество имен за общей почтовой инфраструктурой. Публичная доступность каждого отдельного RR не означает, что оператор предложил массовый каталог по любому измерению. IQUERY снижал стоимость агрегации и одновременно переносил ее часть на сервер.

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

Постоянная отставка сохранила однозначность номера

RFC 3425 не отдал opcode 1 новому механизму. Он заменил соответствующую часть RFC 1035, отметил IQUERY как obsolete, рекомендовал ответ Not Implemented и потребовал навсегда вывести значение из распределения.

Повторное назначение могло заставить старое software толковать новый traffic по заброшенной семантике. Retired value сохраняет однозначную историю протокола и завершает ожидание сервиса без новой коллизии.

Документ также отмечал отсутствие известных clients, зависевших от IQUERY для значимой службы, тогда как PTR под IN-ADDR.ARPA много лет обеспечивал распространенный reverse mapping. Отказ не ломал живую общую зависимость.

DNSSEC делал проблему доказательства еще заметнее. RFC 3425 считал защиту IQUERY responses чрезвычайно сложной без цифровой подписи в момент построения ответа. Подписанная зона аутентифицирует named RRsets и отрицательные доказательства в структуре имен. Произвольный поиск должен дополнительно подтверждать, что из глобально не определенного universe не пропущено ни одного совпадения.

Сервер оставался свидетелем, а не всем namespace

DNS server может быть реальным участником, обладать authority для зон и хранить точные records. Это делает его надежным свидетелем в ограниченной области. Возможность искать в собственной копии не превращает его в principal всех внешних имен с тем же значением.

Заметки Lu Heng разделяют участие и authorization, а также ведение registry и власть над описываемым объектом. IQUERY показывает ту же границу в протоколе. Видимость позволяет сообщать о видимом; она не дает полномочий на глобальное отрицание отсутствующих зон.

Исправлением стал не более крупный центральный каталог. DNS сохранила малый общий слой: names, delegations, RR types, TTL и явно опубликованные reverse records. Участники делают заявления в ограниченных зонах, а resolvers идут по общим правилам, не наделяя одного посредника всеведением.

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

Пять RFC подтверждают формат сообщения, известные ограничения, путь PTR и нормативное решение об отказе. Они не измеряют современный opcode-1 traffic, не перечисляют все исторические implementations и не исключают частные диагностические случаи.

NOTIMP — ожидаемый ответ, а не доказательство, что server вовсе не разбирал request. Timeout может быть вызван фильтрацией или потерей. Положительная response подтверждает локальную обработку, но не глобальную полноту.

PTR также не является удостоверением личности. Forward и reverse data могут отсутствовать, расходиться или быть множественными. Его преимущество здесь — возможность найти ответственную сторону для утверждения, а не автоматическая истинность каждой записи.

IQUERY задавал направление вопроса, но не направление authority. Один bit мог перевернуть сообщение, но не мог перевернуть делегирование распределенной системы. DNS стала надежнее, когда отказалась от привлекательной симметрии и вернула обратные связи под имена.

Источники