Кратко

  • RFC 8482 допускает разные правила ответа ANY для UDP и TCP. Это возможность оператора, а не обязательный путь к полному набору данных.
  • Непустой небольшой ответ даёт обычному резолверу материал для кэширования. Незнакомый код отказа, напротив, мог побудить его обратиться к другим авторитетным серверам.
  • Синтетический HINFO использует старый формат записи, но способен временно скрыть настоящий HINFO в кэше. TTL определяет не только экономию запросов, но и часть задержки при смене политики.

Два транспорта, несколько допустимых решений

В примере из RFC 8482 сервер может отвечать на ANY традиционным способом по TCP и минимально по UDP. Само наличие такого примера легко принять за рекомендацию всегда повторять короткий ответ через TCP. Документ этого не обещает: поведение зависит от выбранной оператором политики.

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

Документ опубликован в январе 2019 года в категории Standards Track и обновляет RFC 1034 и RFC 1035. Описанные изменения для инициаторов и отвечающих сторон необязательны. Это не отмена типа ANY и не приказ всем серверам возвращать HINFO.

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

Отказ, который продолжал работу

Существовали добросовестные причины отправлять ANY: отладка, проверка состояния данных имени, попытка получить MX, A и AAAA одним запросом. Последний приём удобен, только если приложение понимает его пределы. RFC 8482 предупреждает: нельзя предполагать, что запрос обязательно дойдёт до авторитетного сервера и вернёт все существующие RRset. Нужен иной способ получить недостающие сведения.

У отвечающей стороны были свои издержки. Формирование широкого ответа могло требовать дополнительной обработки. Большой объём данных облегчал их массовый сбор. В UDP небольшой запрос с подменённым адресом источника мог вызывать значительно больший ответ в сторону жертвы отражённой атаки. Сокращение ответа уменьшало привлекательность такого усилителя.

Эти мотивы не делают каждый ANY вредоносным. Они также не дают здесь измеренной доли атак или универсального коэффициента экономии. Уменьшение ответа на один тип вопроса не превращает общедоступные DNS-данные в секрет.

В ходе обсуждения рассматривался новый код ответа, сообщающий о нежелании предоставлять обычный результат ANY. По описанию RFC, резолверы, столкнувшись с незнакомым кодом, повторяли запрос к другим доступным авторитетным серверам. Протоколу предлагали новый способ сказать «нет», но существующие программы читали его как повод искать ответ дальше.

Альтернатива состояла в непустом RRset. Его можно было сохранить обычным образом, не обучая все клиенты новому коду. Сохранённая группа записей уменьшала повторные ANY для того же имени. Это конкретное обоснование выбранного подхода, а не утверждение, будто любой код ошибки во всех реализациях вызывает одинаковые повторы.

Что именно скрывается за словом ANY

В ноябре 1987 года RFC 1035 обозначил тип запроса 255 звёздочкой. Реализации обычно называют его ANY. В нынешнем реестре параметров DNS IANA описание говорит о некоторых или всех записях, доступных на сервере. Там же HINFO остаётся типом 13, предназначенным для сведений о хосте.

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

Не следует расширять и сам объект вопроса. RFC 1034, также опубликованный в ноябре 1987 года, разделяет QNAME, QTYPE и QCLASS. ANY в поле типа не превращает имя в шаблон и не становится переносом зоны AXFR. Вопрос об одном имени не перечисляет все имена зоны.

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

Минимальные методы RFC 8482 относятся к существующему имени, классу IN и типу ANY. В остальном сохраняются обычные алгоритмы. Они не разрешают выдумывать существование имени и не делают NXDOMAIN удобным ярлыком для отказа отвечать широко на существующее имя.

Выбрать группу — не значит обрезать её

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

При этом сама выбранная группа должна оставаться целой в рамках обычных правил. В RFC 2181, выпущенном в июле 1997 года, RRset объединяет записи с одинаковыми именем, классом и типом, но потенциально разными данными. Несколько адресов одного типа — не меню, из которого можно произвольно оставить один и назвать результат полным RRset.

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

Старые поля, новая цель

Второй вариант создаёт HINFO, если у соответствующего имени нет CNAME. Рекомендуется одна запись: строка CPU содержит RFC8482, строка OS пуста. Для этого не требуется постоянно дописывать такую запись в данные зоны.

Исторический HINFO из RFC 1035 состоит из двух символьных строк — CPU и OS. Среди его назначений были процедуры FTP, учитывающие сходство машин и операционных систем. Минимальный ответ использовал уже понятную форму, хотя конкретное содержание больше не описывало обнаруженный процессор.

Если известно, что запись создана по этому правилу, номер RFC в поле CPU не следует читать как результат инвентаризации оборудования. Пустая OS — строка нулевой длины, а не исчезнувшее второе поле и не заявление об отсутствии операционной системы.

Однако по одним полученным значениям нельзя достоверно определить происхождение произвольного HINFO. RFC 8482 предостерегает от вывода, что запись обязательно синтезирована по этой спецификации, и от особой обработки, основанной лишь на таком предположении. Похожее содержимое не становится удостоверенным признаком политики.

Отдельно документ разрешает обычное кэширование. Он также допускает сокращение исходящих ANY при наличии подходящего HINFO в кэше или ответ из кэша по обычным правилам. Это разрешение не нужно превращать ни в обязательное новое состояние каждого клиента, ни в запрет использовать сохранённую запись. Ограничение касается уверенности в её происхождении.

Когда кэш удерживает уже не ту политику

Синтетическому ответу нужен выбираемый оператором TTL. Слишком короткое время уменьшает эффект: инициатор снова спрашивает о том же имени. Слишком длинное мешает будущему изменению способа ответа ANY. RFC предлагает сделать значение настраиваемым, а не объявляет единственный правильный интервал.

TTL, согласно RFC 2181, ограничивает максимальное удержание записи. Он не заставляет все кэши хранить её ровно столько: реализация может установить меньший предел. Поэтому нельзя выводить из одной цифры синхронное истечение всех копий или возможность мгновенно отозвать их изменением настройки авторитетного сервера.

За общей задержкой скрывается конкретный конфликт. Синтетический HINFO, попавший в кэш после ANY, может заслонить настоящий HINFO зоны при последующем запросе именно этого типа. Оператору, который пользуется обычными сведениями HINFO, RFC советует выбрать существующий RRset или иной тип записи для минимального ответа.

Авторы документа считали HINFO редко используемым на основании наблюдений своего времени. Это оценка, изложенная в 2019 году, а не новая перепись DNS на 2026 год. Редкость объясняет привлекательность заимствования, но не доказывает отсутствие пользователей, для которых старое значение по-прежнему важно.

Небольшой ответ не равен отрицательному

RFC 2308, опубликованный в марте 1998 года, рассматривает отрицательное кэширование. Ошибка имени NXDOMAIN отличается от отсутствия данных запрошенного типа, которое выводится из подходящего ответа с NOERROR. Для отрицательных ответов важны условия содержимого, SOA и область применения сохранённого результата.

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

Есть и третий метод: попытаться угадать интерес инициатора, возвращая имеющиеся CNAME, MX, A и AAAA и исключая другие типы, например TXT или DNSKEY. Такой ответ может оказаться больше. Он остаётся эвристикой, а не гарантией правильного понимания потребностей приложения.

Подпись относится к возвращённому

Минимизация не отменяет соответствующих правил DNSSEC. В варианте с выбранными существующими RRset подписанная зона требует подходящих RRSIG. Для синтетического HINFO при установленной DO и известной отвечающей стороне подписанной зоне требуется действительная RRSIG; при DO, равной нулю, документ рекомендует её не включать. У варианта с предположением о нуждах клиента также есть требования подписей для подписанной зоны при DO.

Нельзя заменить эти условия одной фразой «всегда подписывать» или «маленькие ответы не подписываются». RFC 3225, датированный декабрём 2001 года, помогает отделить ещё один смысл: DO в OPT сообщает о способности принять записи безопасности DNSSEC, а не об уже завершённой проверке подписи.

Мы используем это историческое определение флага, не переносим старые процедуры SIG, KEY и NXT на современные RRSIG. И даже успешная проверка возвращённой группы не создаёт перечень всего, что осталось за её пределами. Подлинность RRset и полнота инвентаризации — разные вопросы.