Summary

  • RFC 10029 preserves one primary DNS question and uses EDNS to request additional QTYPEs. The response option lists only the additional types that were completely processed under the primary answer's RCODE and flags.
  • A successful packet is not an atomic cross-type snapshot. Omitted types require standalone queries, while returned RRsets can come from different zones, signers, TTL epochs and cache states. Application authority should wait for its own required evidence set.

The failure begins with a perfectly ordinary success code. A client needs A, AAAA and HTTPS records for one name. It sends A as the primary question and asks for the other two through the new option. The resolver replies NOERROR, includes an A answer and lists AAAA in MQTYPE-Response. HTTPS is absent from that list.

Nothing in that packet says HTTPS does not exist. The resolver may not have held it in cache. Its individual lookup may have produced a different RCODE or authority flag. A configured work limit may have stopped processing. The complete HTTPS RRset may not have fit. RFC 10029 requires another standalone query if the application still needs it.

The transport finished; the evidence set did not.

RFC 10029, published on the Standards Track in July 2026, solves a narrow problem. Applications commonly want related DNS types together—A, AAAA and HTTPS, or DS and DNSKEY—yet the ordinary DNS QUERY mechanism cannot safely carry several questions. RFC 9619 removed the remaining ambiguity: opcode QUERY cannot use a QDCOUNT greater than one. RFC 10029 therefore retains a single primary (QNAME, QCLASS, QTYPE) and places an ordered list of extra data RRTYPEs in an EDNS option.

That design is efficient because it is disciplined. It does not pretend several questions became one question.

The response list is the receipt

The query option is assigned code 20. The response uses a different option, code 21, partly to avoid being fooled by middleboxes that echo EDNS options. The current IANA DNS Parameters registry lists both MQTYPE-Query and MQTYPE-Response as Optional.

The requested list is desire, not delivery. The response list is the receipt. Together with the primary Question section, it identifies the QTYPE combinations completely answered in that packet. A server must return the response option when it supports the extension, even when the list is empty. A client that receives no response option, an echoed query option or a malformed result must fall back to ordinary standalone queries.

This is not equivalent to ANY. RFC 8482 allows a responder to answer an ANY query minimally, including with one RRset of its choice. It is also not a way to smuggle several Question entries into a packet. RFC 9619 requires such an ordinary multi-question QUERY to fail as malformed. RFC 10029 gains efficiency by making the completed set explicit rather than weakening either rule.

The primary answer controls the common header

The server constructs the primary response first. At that point it determines the RCODE and flags such as AA and AD. If the primary answer already triggers truncation, the server does not process additional QTYPEs for the bundle.

Each extra QTYPE is then evaluated as though it had been queried individually. It can join the packet only if its RCODE and relevant flags match the primary result. The RFC's zone-cut example is revealing: a parent can answer DS authoritatively, with AA set, while the NS data at the parent side is not authoritative. The two useful RRsets cannot be merged under one header without lying about at least one. NS is therefore omitted from MQTYPE-Response.

The same boundary applies when the primary lookup is NOERROR and another type produces SERVFAIL. A single DNS header has one RCODE. Bundling must not erase the mismatch.

RFC 2181 supplies the ranking context used by the new specification, but equal ranking inside the combined answer does not turn every RRset into one administrative act. The header can be common while provenance remains plural.

Complete means the whole type combination fits

For one added QTYPE, inclusion is all-or-nothing at the required-record level. The server combines records into the same sections where they would appear in an ordinary answer and removes duplicate RRs within a section. If size or another resource limit prevents all required material for that QTYPE from fitting, the server leaves the QTYPE out of the response list. It must not trigger truncation merely because an additional type was requested.

That difference matters to telemetry. A TC=0 packet can still be incomplete relative to the client's original wish list. Conversely, an empty MQTYPE-Response can be a valid, explicit signal that the server understood the extension but completed none of the additional types. Packet integrity and requested-set completeness are different fields.

EDNS adds another path boundary. The OPT record is not cached. The advertised UDP payload size belongs to the transaction and can exceed what an intervening path actually carries. Firewalls, proxies and load balancers are required not to strip conforming OPT data when merely forwarding, but deployed paths cannot be assumed from the standard. A resolver must associate option support, response size, truncation and fallback with the observed path rather than with a permanent label on the server.

Omission is deliberately ambiguous

RFC 10029 names several reasons why a requested type can be missing from the completed list: a recursive server lacks the records in cache; its individual answer has incompatible flags or RCODE; it declines the work or hits a configured limit; or the resulting response would be too large. The list does not encode which reason applied.

That restraint is important. An omitted HTTPS type is not proof that no HTTPS RRset exists. It is not proof that the authority refused it. It is not a negative answer and does not carry the denial material required by RFC 2308 or the authenticated-denial rules in RFC 4035. It is unfinished work from the client's perspective.

The client must issue standalone queries for every omitted type it still requires. This fallback is not a performance afterthought. It is the correctness rule that prevents a transport optimization from silently narrowing the application's evidence.

One envelope can contain several authorities

The RFC expressly warns that individual records can originate in different DNS zones and that proofs of nonexistence can be produced by different signers. Their TTLs may differ. A recursive resolver may have inserted them into cache at different times. One may be freshly fetched while another has been counting down locally. The fact that they arrived in one response does not synchronize those histories.

This is where operational dashboards easily overstate certainty. “DNS lookup succeeded” collapses at least six claims:

  • the server understood the extension;
  • the packet passed syntax and transport checks;
  • a particular QTYPE was completely included;
  • each RRset and denial proof validated under its own authority;
  • the data were current enough for the application's policy;
  • the application actually selected and used one returned alternative.

RFC 9499 gives precise vocabulary for resolvers, authoritative servers, RRsets and caches. That vocabulary should survive into evidence storage. A bundle ID is not a replacement for per-RRset provenance.

The A, AAAA and HTTPS example also touches a separate decision surface. RFC 9460 defines SVCB and HTTPS records, including client handling of priorities and parameters. Receiving an HTTPS RRset does not prove that a client understood its mandatory keys, used its hints, selected its target or completed a connection. DNS delivery and application authority remain separate stages.

Build a type-completeness ledger

For each attempted bundle, retain the QNAME, QCLASS and primary QTYPE; ordered additional requested types; resolver path and EDNS payload size; exact response-option presence and returned-type list; RCODE, AA, AD and TC; and the reason code available locally for every omission or fallback.

For every returned type, retain the complete RRsets and denial proofs, origin zone, authoritative status, signer identity, DNSSEC validation result, TTL, cache source and observation time. Then bind standalone fallback attempts to the same application request. Finally record which address or service record the application selected and whether the connection or service action succeeded.

That ledger preserves four independent completion states: packet received, QTYPE completely answered, RRset validated, application requirement satisfied.

Heng Lu's Running-Code Primacy supplies the governing test. Publication and registry assignment matter, but they do not establish a resolver path's support or an application's behaviour. His Minimum Initial Specification, Localized Future Decision and Voluntary Adoption supports exactly this shape: a narrow, deterministic shared format; locally chosen limits; explicit compatibility and fallback; and adoption proved by running implementations. His argument for reality rather than advocacy sets the reporting boundary. The option registry describes possibility. Only path evidence, returned type lists, validation and application outcomes describe reality.

One packet can carry several completed facts. It cannot make them one fact.