TL;DR: while the basic case is simple, I don't think it's worth implementing all the (combinations of) edge cases right.  That makes me unsure how to progress this RFC draft.  (I didn't feel like hard-blocking this, so checked "On the Right Track", but...)

I've been assigned as a dnsdir reviewer.  I additionally looked into "multi-qtype" discussions happening in DNSSD and previously DNSOP.
- - -

Maybe it would be at least worth mentioning what's expected to happen with other EDNS options?  Take just those from original QTYPE?  Or require that all EDNS sets are the same?  (Unless an RFC specifies this for particular EDNS option/s.)


> For the purposes of Section 5.4.1 of [RFC2181] any authoritative answers received MUST be ranked the same as the answer for the primary question.

What's the point of this sentence?  Even without this draft, it's common to have differently ranked records in a single answer (e.g. secure and insecure in a CNAME chain).  This draft adds more variability, e.g. thanks to DS NODATA.


Nit: I'd note that latencies of the answers will get tied, so it depends if the client wanted to wait for all the types before doing anything anyway.  I read that high-performance (HTTP) clients will dislike this, and e.g. the happy eyballs (RFC 8305 sec.3) are against such coupling:
> Implementations SHOULD NOT wait for both families of answers to return before attempting connection establishment.

But at a glance I doubt that this extra latency is practically significant, especially for low-resource clients.
Anyway, I did notice some interest on the mailing list (clients in constrained devices, I suppose).


For responders, I suspect that unless you have a very specialized one, it will be hard to implement this draft in a different way than by producing a full answer for each type and then "compressing" everything together.  In that case you only get savings around packet handling.  My reason for that is that the normal protocol implies special-casing by QTYPE in some places, and it probably won't be easy to "generalize" those parts of code.

For clients this often might not be an issue thanks to lack of DNSSEC validation and/or not using QTYPEs with different processing, so the code added for multi-QTYPE might remain relatively simple.  Though they won't be able to rely on their server (always) supporting this, so the old code sending multiple queries will have to remain as a fallback.  Therefore again, you only get savings around packet handling (in the optimistic case).


There's a minor representability trouble with combining NODATA (RCODE=NOERROR but no RRset exists).  The TTL for those is on SOA in AUTHORITY, but you can only put one in there per zone, probably with TTL as the *minimum* over all the NODATA QTx, though that's not without down-sides either.  This should happen commonly for caching servers.  Some of QTx might be parent-side and therefore getting a different SOA, though that seems like a mixed blessing really (the client would need to be more careful about which SOA belongs to which type).

While I expect this draft to work relatively nicely with basic DNSSEC usage (and save duplication of records there), a really bad case of NODATA comes from the Black Lies -style responses [1].  You'll get multiple NSEC records with the same owner and conflicting information about (non-)existence of the types you ask, so the combined answer will be relatively large and not trivial to disentangle by a validating client.  Still, this RFC draft feels targeted at clients that won't attempt DNSSEC validation, so it would be possible to just hand-wave around such cases (though I'm pretty uncomfortable as an implementer).

[1] for more details around this answer style I'd recommend looking into
 https://datatracker.ietf.org/doc/draft-ietf-dnsop-compact-denial-of-existence/


Generally I'd say that in DNS the individual features tend to be relatively simple, but it may start getting rather hard when you combine them together (at least since wildcards with DNSSEC).  That's the main risk for complexity I see also in this draft.  I'm personally not convinced that it's worth it in this case, but ultimately that choice might be left to every implementer separately.  Maybe an approach that only uses this RFC draft in very simple cases, and everything else falls back to the usual.

--Vladimir | knot-resolver.cz