[dnssd] Re: Progressing with multi-qtypes

[Esko Dijk <[e-mail]>]

If the query receiver is a recursive resolver, and the auth server is elsewhere, then my argument of easily iterating over 300 QTYPEs in the request falls apart.
Whether the resolver is resource-constrained or not: sending out 300 individual DNS queries to the auth server based on a single request sounds problematic – risk of amplification attacks?

In this case David’s proposal could be applied by the resolver: it MAY ignore most of the requested QTYPEs.
However, are we okay to leave the number of handled questions completely up to the implementation? What is reasonable/expected - 3, 7 (0b111 – current draft), 10, 100 … ?  Or could the resolver/server pick preferably those QTYPEs that it knows about?  (to avoid 100s of requests for undefined ‘bogus’ QTYPE numbers).
Or MUST it process QTYPEs sequentially before deciding to drop the rest?

Esko

From: Ted Lemon <[e-mail]>
Sent: Tuesday, April 30, 2024 00:27
To: Esko Dijk <[e-mail]>
Cc: David Schinazi <[e-mail]>; Ray Bellis <[e-mail]>; dnssd <[e-mail]>
Subject: Re: [dnssd] Progressing with multi-qtypes

I suppose the reason for the MUsT is that we want a recursive resolver to actually try to fetch all the requested records.  But if the auth server doesn’t support multi-qtype, that might mean a lot of queries.  Was that the motive for the limit?

Op ma 29 apr 2024 om 16:40 schreef Esko Dijk <[e-mail]<mailto:[e-mail]>>
Agree with the proposed changes.

About David’s comment:

> the server is allowed to only handle some of them if it is resource constrained

I see the point. But the present draft also has the requirement “MUST attempt to return all specified RR types except where that would result in truncation”. This seems more strict than the “SHOULD” requirement that is quoted.
If the intention is that a “MUST attempt” is at equal level to a “SHOULD”, then it’s compatible, but it’s too fuzzy for my taste. So: can be clarified in whatever way we intended this to be.

Considering the situation of a resource constrained server that only has a few RR types for a given (query) name – there may be no need for this server to ignore any of the QTYPES in the request.
Suppose that for example the client asks for 300 QTYPES, really a lot, but the server stores only 4 RR types for the name. In that case the server can just keep iterating over the 300 QTYPES in the request and only add the 4 records that it recognizes by type. Its response Multi-QTYPE option would be small, and no resources are spent on the server side apart from storing the request packet which I assume it can do anyway (otherwise it wouldn’t have received the packet in the first place.)
So the only resource spent here by the server is some iteration and comparison time in memory, which should be really fast on any platform nowadays. No extra memory allocation is needed.

If the server is resource constrained and also stores many different RR types per name, then it’s another story, but in this case it would be rather unlikely to have this hosted on a resource constrained server I think.  But even so, such a server could still perform the truncation as already described in the current -00 draft. (when it’s not able to complete the “SHOULD” or “MUST attempt” part discussed above.)

So what I’m trying to say with many words is that if we remove QTCOUNT, no special provisions for a “resource constrained server” are needed in addition to what we already have in -00 – only some clarification or language harmonization of this SHOULD-behavior is needed.

Esko

From: dnssd <[e-mail]<mailto:[e-mail]>> On Behalf Of David Schinazi
Sent: Monday, April 29, 2024 18:59
To: Ted Lemon <[e-mail]<mailto:[e-mail]>>
Cc: Ray Bellis <[e-mail]<mailto:[e-mail]>>; dnssd <[e-mail]<mailto:[e-mail]>>
Subject: Re: [dnssd] Progressing with multi-qtypes

[ Speaking as individual contributor ]

+1 to removing the QTD bit in favor of two option codes

+1 to removing the type number limit entirely. Since the server handling of these is a SHOULD, the server is allowed to only handle some of them if it is resource constrained. We already have the server send the list of types it handled in the response option, so we could just say that the server MAY ignore some of the requested types, but in that case it MUST NOT include them in the response options?

David

On Mon, Apr 29, 2024 at 6:21 AM Ted Lemon <[e-mail]<mailto:[e-mail]>> wrote:
I think I may have already argued for some of these points, but I think I was a bystander for the multi-option versus QTD question. I do agree with the approach you've stated—just burn two option codes. We have plenty. I'm sure someone will curse our memory 2000 years from now, but how else will we be remembered if we don't do this?

I may have been one of the people who argued for getting rid of QTCOUNT, and I still think that's right—it's redundant, and if we send it, we have to validate it. That seems like needless complexity.

As for the limit on the number of qtypes, I also don't see the need for that. There will no doubt be practical limits; the most likely of these is simply that there aren't actually that many rrtypes that will likely be represented on any given name. So I'm not sure what an explicit limit here accomplishes. At the very least we should articulate a reason for the limit if we impose one.

On Mon, Apr 29, 2024 at 6:17 AM Ray Bellis <[e-mail]<mailto:[e-mail]>> wrote:
With apologies for the delay (caused by other travel since the Brisbane
meeting) the proposal during the session there was to:

- remove the QTD bit and use a pair of EDNS option codes instead
   (one for queries, and another for responses).

- remove the QTCOUNT field

- either impose a fixed limit on the number of additional QTYPES (in the
   range of 3 - 8?) or remove the limit altogether.

We need to get formal WG consensus on these points so please send your
thoughts to the list...

thanks

Ray

_______________________________________________
dnssd mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dnssd
_______________________________________________
dnssd mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dnssd