Early Review of draft-ietf-dnssd-multi-qtypes-06
review-ietf-dnssd-multi-qtypes-06-dnsdir-early-cunat-2025-01-29-00

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