Кратко

  • RFC 3425 навсегда вывел из обращения DNS opcode 1, IQUERY, и предписал серверу отвечать Not Implemented; этот отказ характеризовал операцию, а не существование имени.
  • Обратное отображение сохранилось в явных PTR-записях делегированного пространства. NOTIMP, NXDOMAIN, NODATA, ответ PTR и DNSSEC-проверка — разные свидетельства.

Решение было принято до поиска имени

Опубликованный в ноябре 2002 года RFC 3425 объявил IQUERY полностью устаревшим и заменил раздел 6.4 RFC 1035. На запрос с opcode 1 серверу следовало возвращать Not Implemented.

Такой ответ мог быть точным выполнением стандарта. Он не говорит, что сервер искал owner name, получил NXDOMAIN или установил отсутствие PTR. Сначала решался иной вопрос: поддерживается ли сама операция.

Общее состояние «не найдено» меняет предмет утверждения и создаёт ложный факт.

IQUERY инвертировал локальную базу

В RFC 1035 клиент помещал значение Resource Record в answer section. Сервер искал в своих данных совпадающие тройки типа, имени и класса и возвращал их в question section. Это не был запрос PTR к имени в in-addr.arpa.

Для общего ответа требовался полный просмотр или дополнительный индекс по значениям. RFC 1035 уже называл нагрузку тяжёлой. RFC 3425 показал масштаб: сервер с миллионами имён мог сформировать ответ размером в мегабайты.

Поиск всех доменов, делегированных на nameserver крупного провайдера, мог вернуть десятки тысяч троек. Маленький пакет запускал большое перечисление, открывал группы имён и проводил ввод через редко проверяемый старый код. Это граница риска, а не заявление о конкретной атаке.

Один сервер не знал, куда направить инверсию

Обычный DNS следует делегациям имени. IQUERY спрашивал выбранный сервер о содержимом именно его базы. Если данные находились у другой стороны, естественного referral к ней не было.

Два сервера могли вернуть разные множества, потому что обладали разными данными. Сервер мог отказать IQUERY, хотя хранил связанные RRset. Поэтому ответ не имел полномочий означать «все имена, связанные со значением».

Инверсия одной базы и запрос в делегированном пространстве имён — разные доказательные поверхности.

PTR дал обратному вопросу явное имя

Рабочая модель публиковала соответствие как обычные DNS-данные. Для IPv4 строится owner name под in-addr.arpa, затем запрашивается PTR. RFC 1033, RFC 1034 и RFC 1035 задают основу; RFC 2317 показывает, что блоки меньше /24 тоже требуют явной схемы делегирования.

PTR не гарантирует полноту или идентичность. Зато вопрос получает маршрут и контекст: точный owner name, цепочку делегаций, авторитет, TTL и при наличии DNSSEC — состояние проверки. Отсутствие выражается собственным отрицательным ответом DNS, а не выводится из отказа другой операции.

У ошибок разные субъекты

NOTIMP говорит о неподдерживаемой операции. NXDOMAIN — о существовании owner name. NODATA — о существующем имени без требуемого типа. Timeout сообщает лишь, что окно наблюдения завершилось без приемлемого ответа.

RFC 8020 уточнил использование авторитетного NXDOMAIN, но не превратил отказ opcode в отсутствие. RFC 8499 помогает сохранить терминологию.

После IQUERY-NOTIMP нужно сформировать правильный PTR-запрос. После NXDOMAIN сохраняются авторитет и отрицательное кэширование. Ошибка валидации остаётся ошибкой валидации. Одно пустое поле не подходит всем состояниям.

Выведенный номер остался занятым историей

RFC 3425 определил opcode 1 как устаревший IQUERY и потребовал постоянного вывода из обращения. Реестр параметров DNS IANA и RFC 6895 сохраняют это значение.

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

DNSSEC работает с именованными данными

RFC 3425 отмечал, что защитить IQUERY с DNSSEC крайне трудно без подписи на лету. Синтезированный результат инверсии не является заранее существующим RRset у owner name.

RFC 4033, RFC 4034 и RFC 4035 строят проверку вокруг явных DNS-данных и доказательств отрицания. Проверенный PTR подтверждает утверждение зоны, но сам по себе не доказывает выделение адреса, контроль узла, прямое подтверждение, достижимость, аутентификацию или успех сервиса.

IQUERY-NOTIMP также не становится аутентифицированным отрицанием лишь потому, что находится в DNS-сообщении.

Полезный отказ не выходит за свой контур

RFC 3425 не уничтожил обратный DNS. Он закрыл дорогую локальную инверсию с размытой авторитетностью и оставил делегированный путь PTR.

Исторический урок — сохранять субъект каждого свидетельства. Операция отвергнута, имя не существует, тип отсутствует, RRset проверен, узел идентифицирован и сервис сработал — разные предложения. В раздельном виде отказ полезен. Сведённый к «имени нет», он создаёт наблюдение, которого не было.

Источники и пределы

Первичный набор включает RFC Editor HTML, текст, информационную страницу, Datatracker, историю, ссылки и поиск errata. Контекст дают RFC 1033, RFC 1034, RFC 1035, RFC 2317, RFC 6895, RFC 8499, RFC 4033, RFC 4034, RFC 4035, RFC 8020 и реестр IANA. Разделение символа и работы следует эссе Heng Lu о слоях реальности и приоритете работающего кода.

Источники не доказывают современное распространение, конкретный уязвимый сервер, измеренную атаку, полноту PTR, идентичность, достижимость, авторизацию или результат приложения.