There was some earlier discussion on this text: see
https://mailarchive.ietf.org/arch/msg/dnssd/lc-32cYA0_YONaVZcx7uAGvU1y4/
For an implementer it must be clear when to return FORMERR. The implementers
will not be only DNS experts, or people managing existing DNS codebases, but
also implementers new to the field e.g. as we have in the OpenThread project.
If we can change the "such as" to "which are" or similar, that would be more
clear. And in Section 3.2.1 the wording "any invalid QTx" is used; it could be
enhanced by saying "any QTx that does not meet the requirement in Section 3.1".
Esko
-----Original Message-----
From: Ted Lemon <mel...@fugue.com>
Sent: dinsdag 18 maart 2025 09:58
To: DNSSD <dn...@ietf.org>
Cc: dnsop@ietf.org
Subject: [dnssd] Multi-QTypes and Meta-RRs
On 16 Mar 2025, at 12:26, Ted Lemon <ele...@apple.com> wrote:
>
>
> The text on invalid QTx seems like [citation needed]. An example invalid type
> of QTx is given, but I don't actually know of a list of meta-qtypes. Where is
> this defined? I'm assuming this means "ANY" but I don't actually know that
> this assumption is correct.
Peter Thomassen pointed out online that there is text in the draft that
explains this:
QT: a (potentially empty) list of 2 byte fields (QTx) in network
order (MSB first) each specifying a DNS RRTYPE. The RRTYPEs MUST be
for real resource records, and MUST NOT refer to Meta RRTYPEs such as
"OPT" and those from the reserved range 128 - 255, e.g. "IXFR",
"TSIG", "*", etc.
Here is the text I was commenting on:
If any invalid QTx is received in the query (e.g. one corresponding
to a meta-RR) the server MUST return a FORMERR response.
Both of these bits of text exist in the document. I think that the text Peter
pointed out should be moved down to the bit about server behavior, or at least
there should be a back pointer. However, also that text still says "such as
..." which implies that what is said here is not complete. If that were
actually the case, normative language would be inappropriate, since the
implementor doesn't know precisely what to exclude.
So I went hunting for this. This is, perhaps unsurprisingly, defined in RFC
2929. There is no reference to RFC 2929 in the IANA registry under the
unassigned meta RRtypes, which perhaps should be fixed. The private and
unassigned sections also don't reference RFC2929 and perhaps should.
Anyway, my point is that this text should be explicit about what is required. I
think it's the OPT RRtype and all RRtypes numbered 128-255. And nothing else.
And there should be a reference to the section in RFC2929 that explains what a
Meta RRtype is. But implementations can't exclude any other meta RRtypes,
because the document doesn't list them, and since there is a reserved number
space for meta RRtypes, there is no need for leaving this open-ended.
I suspect that this is actually what Ray intended, and I read "such as"
differently than he intended, but I think this change is still necessary,
because although I am a bit of a weirdo, there are one or two other weirdos who
implement stuff like this, so this could happen again. :)
I also think that it would be better to specify this in the server behavior
section rather than in the description of what a QType is, but that might just
be because when I was implementing this I was in a hurry and missed the initial
text about meta RRtypes.
_______________________________________________
dnssd mailing list -- dn...@ietf.org
To unsubscribe send an email to dnssd-le...@ietf.org
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
