FYI Ted Lemon is working on multi-qtypes implementations, and sent these messages he "thought" included DNSOP.
tim ---------- Forwarded message --------- From: Ted Lemon <elemon=40apple....@dmarc.ietf.org> Date: Sun, Mar 16, 2025 at 1:26 AM Subject: [dnssd] Re: Questions that arise as I implement multi-qtypes To: DNSSD <dn...@ietf.org> Following on on this, I notice several other requirements. I don't feel so strongly about this, but why does the server-side implementation need to verify that there aren't any duplicate QTypes. This is a bunch of additional code to get wrong. What are we preventing here? What's the motivation? I'm pretty okay with returning FORMERR if QDCOUNT==0, because that's really easy to implement. I'm okay with rejecting multiple mqtype options, but I'd also be okay with silently ignoring all but the first. Servers that don't implement this option won't return FORMERR. So what's the benefit of this specific choice? I'm inclined to say it's correct, but it is a small amount of additional work. 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. Finally, this never occurred to me until starting to type code, and I don't necessarily think it's wrong, but there's no discussion about QCLASS at all. The document takes a clear position that multi-qtypes uses the QCLASS of the question, but what's the motivation for this choice? Why not have mutli-qtypes be a list of (qtype, qclass, qtype, qclass, ...)? My answer to this would be "qclass is useless and so this wastes space" but I think it's worth talking about this. Possibly the WG already talked about it and concluded it wasn't necessary? On 16 Mar 2025, at 12:15, Ted Lemon <ele...@apple.com> wrote: I'm finally actually starting to do the hackathon project, and given that the whole point of this is to surface issues in the draft prior to publication, I'm going to start a thread here to report my observations. Hopefully this will be useful. Others who are also hackathoning on multi-qtypes are welcome to join in on this thread or start their own. BTW, I'm cross-posting this to dnsop, but have set the Reply-To to dnssd, so that DNSOP folks know this is happening, but don't have to read the whole thread. If you disagree with this choice, no need to argue—just Cc dnsop on your reply. First observation: section 3.2.1 places a requirement on servers to reply with a FORMERR if multi-qtypes is sent and OpCode != 0. My reaction to reading this was "oh great, I have to write a bunch of code to do this for all non-query messages. What a pain." My second response is to not do it, because it's unnecessary. It's perfectly normal (I think, correct me if I am wrong) for a DNS server that gets an unknown EDNS(0) option to ignore it. Why do we need/want different behavior here? I would propose that we change this to "MUST silently ignore" rather than "MUST return FORMERR." IOW this option has no meaning for any other message, but you don't need to write special-case code to punish a DNS implementation that incorrectly sends it. The behavior is defined, and the correct behavior is that it is ignored. _______________________________________________ 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
