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 <esko.dijk@iotconsultancy.nl>

> 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 <dnssd-bounces@ietf.org> *On Behalf Of *David Schinazi
> *Sent:* Monday, April 29, 2024 18:59
> *To:* Ted Lemon <mellon@fugue.com>
> *Cc:* Ray Bellis <ray@bellis.me.uk>; dnssd <dnssd@ietf.org>
> *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 <mellon@fugue.com> 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 <ray@bellis.me.uk> 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
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>
>