[dnssd] Re: WGLC for draft-ietf-dnssd-multi-qtypes

[Ray Bellis <[e-mail]>]

On 2025/06/16 23:41, [e-mail] wrote:

> (1) It seems to go without saying, but Section 3.3 for Client 
> Response Processing never actually says that clients MUST/SHOULD NOT 
> cache record types it receives that it didn't request. Should we? It 
> seems like an attack vector if we are treating this response as the 
> set as if every type was the QTYPE. This is expected for meta types, 
> but in the case of querying for {AAAA, SVCB}, no client would expect 
> A records to come back which could be cache poisoning for a name 
> that was intended to be IPv6-only.

Responses *often* contain records that were not for the specific type 
requested, e.g. CNAME chains, NSEC records, etc.   There's also the 
example of proposals such as SRV automatically returning the A / AAAA 
records associated with the hostnames in the SRV.

I'd have to defer to an actual implementor, but I expect the normal 
implementation would be for a resolver to look in the question section 
for the types it actually asked for, any other records that are 
necessary for the answer, and ignore any others.

I'm therefore unsure how to handle this one, if at all.

> (2) The security considerations section acknowledges the 
> amplification attack this could enable, but it does not mention what 
> Section 3.3's first bullet says about the server choosing to not 
> process a request because it had too many types. I think it should 
> in the spirit of giving obvious advice to implementors as it is 
> currently implied but not stated. In fact, Section 3.2.2's 
> normatives don't leave much room for an RFC novice to read "but you 
> can also choose to defend against complex queries" from it.

I've added this text to the Security Considerations:

"Implementors SHOULD allow operators to configure limits on the number
of QTx values specified and/or the resulting response size."

I've also updated the draft to include the new IANA registrations.

Ray