IETF Last Call Review of draft-ietf-dnssd-multi-qtypes-11
review-ietf-dnssd-multi-qtypes-11-dnsdir-lc-weber-2026-01-02-00

Moin!

I am an assigned DNS Directorate reviewer for draft-ietf-dnssd-multi-qtypes.

For more information about the DNS Directorate, please see
https://wiki.ietf.org/en/group/dnsdir

I apologise for not paying attention to this draft earlier, but with this being
processed in dnssd I thought it would only apply in the dnssd context, however
reading it it does apply to all the DNS ecosystem and for this I think it has
stuff that needs to be improved before becoming an RFC. I as Vladimir nearly
checked “Not ready”, when reviewing this, but as I do see some benefits I also
didn’t want to hard block this.

There are issues I have with the draft, the first one is this sentence in
section 3.4:

If a recursive server does not yet have those responses available it MUST first
make appropriate outbound queries to populate its caches.

I do understand the motivation behind it, but this a series of attacks waiting
to happen. We recently had a lot of attacks that utilized getting recursive
resolvers to do work and use that to attack victims and all of these also apply
here. So forcing the resolver to go out on each QTYpe IMHO is a non starter. In
reality it also doesn’t matter as for popular domains the resolver will have
stuff in Cache anyway. So this could be easily fixed by a SHOULD, but it would
be good to elaborate on that, which brings me to my next topic limits.

The draft in various sections talks about limits that could have been reached
or configured, but does not supply on definitions what they could be or what
values one could set. As we’ve seen with lots of the DNS protocols not defining
a limit upfront has lead it being abused by attacks or lead to vulnerabilities.
So we should define limits upfront when we create a protocol so that the
expectations are set from the start. For me the natural limit for a mx mqtype
count would be 4, as we currently need three (A, AAAA, SVCB) in the most common
case that would give us one to spare, but I’m open to discussions there, but it
definitely should not be all possible 16 bit values, even if we subtract the
non data RRTYpes.

The last issue is with the definition or usage of sizes, which are a bit
confusing to me or I misunderstood some of it. There are the following sizes: -
Max UDP response size (IMHO 1232, but I know others have different opnions on
that) - Max DNS response size (64k) - Max size the responder wants to answer
with I think all of these are different and if the response is truncated
wouldn’t the TCP connection also issue an multi type dns query as this is
normal DNS behaviour and then the second two limits would apply, though I would
be ok with them being identical (64k) as they only apply to TCP or even newer
transports (DoT,DoH,DoQ). So I would suggest naming them consistently and feel
free to come up with better names for it.

As the recursive resolver behaviour is something I deeply care abut here is 
how I would rephrase that resolver sentence mentioned above:

If a recursive server does not yet have those responses available it SHOULD
first make appropriate outbound queries to populate its caches, though it MAY
just response with entries from its cache, or limit the amount of outbound work
for a single query, and hence reply with not all query types requested.

So long
-Ralf
——-
Ralf Weber