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