Кратко

  • RFC 10029 оставляет один основной вопрос DNS и запрашивает дополнительные QTYPE через EDNS. В ответный список попадают только дополнительные типы, полностью обработанные с тем же RCODE и совместимыми флагами, что и основной ответ.
  • Общий пакет не превращает результаты в атомарный снимок. Для пропущенных типов нужны самостоятельные запросы; возвращённые RRset сохраняют отдельные зоны, подписантов, TTL, историю кэша, проверку и решение приложения.

Предположим, сервису нужны A, AAAA и HTTPS. Резолвер отправляет A как основной тип, два других перечисляет дополнительно. Ответ приходит с NOERROR; в нём есть адрес, а MQTYPE-Response сообщает о полном AAAA. HTTPS в списке нет. Счётчик внешних пакетов уменьшился, однако обязательная работа не исчезла: если HTTPS нужен приложению, его следует запросить отдельно.

Пропуск не объясняет себя. В рекурсивном кэше могло не быть нужной записи. Индивидуальный запрос мог дать другой RCODE или флаг авторитетности. Сервер мог ограничить объём работы. Полный набор данных мог не поместиться. По одной пустой позиции нельзя выбрать причину.

RFC 10029, опубликованный в июле 2026 года как документ Standards Track, вводит способ объединять связанные потребности DNS без нескольких обычных вопросов. Последний путь закрыт RFC 9619: для QUERY значение QDCOUNT не должно превышать единицу, иначе сообщение считается ошибочным.

Поэтому один QNAME, QCLASS и основной QTYPE остаются в Question. Дополнительные типы данных передаются в опции EDNS. Экономия транспорта не меняет того, что каждый тип имеет собственный результат.

Запрос сообщает желание, ответ — завершение

Код MQTYPE-Query равен 20, код MQTYPE-Response — 21. В актуальном реестре параметров DNS IANA обе опции отмечены как необязательные и связаны с RFC 10029.

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

Пустая ответная опция означает поддержку расширения, но отсутствие завершённых дополнительных типов. Если опции ответа нет, вернулась опция запроса, типы повторяются или получен FORMERR, клиент обязан перейти к обычным запросам для всех всё ещё нужных типов.

QTYPE ANY не даёт такой гарантии. RFC 8482 разрешает минимальный ответ на ANY, включая один выбранный сервером RRset. RFC 10029 не обещает «всё» — он перечисляет то, что завершено.

Заголовок принадлежит основному ответу

Сначала сервер строит результат для основного QTYPE и определяет RCODE, AA, AD, TC и другие общие признаки. Если основной ответ уже требует усечения, дополнительные типы для объединения не обрабатываются.

Затем результат каждого дополнительного типа оценивается отдельно. Он может войти в пакет лишь при совпадении RCODE и значимых флагов. Нельзя спрятать SERVFAIL дополнительного типа под NOERROR основного. На границе зоны ответ DS от родительской стороны может быть авторитетным, а видимые там же NS-данные — неавторитетными; единый AA исказил бы один из результатов.

RFC 2181 задаёт контекст ранжирования DNS-данных. Но одинаковый ранг не означает единого издателя, единой операции публикации или единой цепочки доказательств.

Полный тип должен поместиться целиком

Записи дополнительного QTYPE распределяются по тем же разделам, где появились бы при самостоятельном запросе. Дубликаты RR внутри раздела удаляются. Тип попадает в MQTYPE-Response только тогда, когда все необходимые для его результата данные могут быть включены.

Если мешает размер или иной лимит, тип пропускается. Само наличие дополнительных типов не должно вызывать усечённый ответ. Поэтому TC=0 подтверждает целостность построенного пакета, но не полноту исходной потребности клиента.

RFC 6891 добавляет границу пути. OPT не кэшируется, объявленный размер UDP относится к одной транзакции и может превышать фактические возможности маршрута. Фрагменты способен блокировать межсетевой экран; промежуточное оборудование способно повредить опцию, хотя соответствующие стандарту устройства не должны её удалять. Поддержка устанавливается наблюдением на конкретном пути.

Пропуск — не отрицательный ответ

Отсутствие в рекурсивном кэше, несовместимый RCODE или флаги, отказ от дополнительной работы, достижение лимита размера — всё это допустимые объяснения. Сам список не выбирает одно.

Если HTTPS не указан, это не доказывает отсутствие HTTPS RRset. Пропуск не равен полноценному отрицательному ответу по RFC 2308 и не несёт автоматически доказательство DNSSEC из RFC 4035. Он также не доказывает фильтрацию, аварию или ненужность типа.

Обязательный самостоятельный запрос завершает доказательство для приложения. Отказ от него ради красивой метрики пакетов незаметно меняет контракт приложения.

Один момент доставки не означает один момент происхождения

Записи в общем ответе могут происходить из разных DNS-зон, а доказательства отсутствия — иметь разных подписантов. У каждого RRset свой TTL. Рекурсивный резолвер мог получить A раньше, AAAA только что, а HTTPS — через другую ветвь полномочий. Пакет синхронизирует доставку, но не историю публикации и кэширования.

Термины RFC 9499 должны сохраняться в операционных данных: RRset, авторитетный сервер, рекурсивный резолвер и кэш — разные сущности. Их нельзя заменять одним признаком «DNS успешно».

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

Реестр полноты по типам

Для каждой попытки следует хранить QNAME, QCLASS, основной QTYPE, упорядоченный список дополнительных типов, путь и резолвер, размер EDNS, наличие и точное содержимое ответной опции, RCODE, AA, AD и TC. Разница между запрошенным и завершённым множествами должна быть отдельным полем.

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

Так разделяются четыре состояния: пакет получен, QTYPE полностью отвечен, RRset проверен, потребность приложения удовлетворена.

Приоритет работающего кода Хэна Лу не позволяет принимать публикацию RFC и регистрацию IANA за доказательство внедрения. Его модель минимальной начальной спецификации, локального будущего решения и добровольного принятия поддерживает узкий общий формат, локальные лимиты, явную совместимость и обычный DNS как путь выхода. Принцип реальности вместо агитации завершает границу: реестр показывает возможность, фактический путь, список, проверка и результат приложения показывают эксплуатацию.

Один пакет может доставить несколько доказательств, не превращая их в одно полномочие.