> On Jul 4, 2024, at 1:55 AM, Petr Špaček <pspa...@isc.org> wrote: > > > Unrelated thoughts: > > ### OPCODE > Currently the document sorta implicitly talks about DNS queries - mainly > implied by the structure of section 3.2 and listed possible answer types and > RCODEs. > > Should the document be explicitly limited to OPCODE=QUERY, or is there value > in allowing other opcodes? > > E.g. RCODE=YXRRSET comes to mind, where it could be useful for OPCODE=UPDATE > as well as OPCODE=QUERY.
You’re right that the document was written with QUERY in mind. As you say, it might also work for UPDATE and maybe even NOTIFY. UPDATE presents a slight complication in that some implementations probably increment the serial/version shortly after processing the update, but perhaps after sending the response. If UPDATE were to be supported, then we’d probably have to specify that the server returns the pre-update zone version. Since the entire thing is optional to implement anyway, maybe just leave it up to individual implementors which opcodes they want to support? > > > > ### Error handling advice > While re-reading it once more I wonder if sections 3.1 Initiators and 3.2 > Responders should have some more words about when to do when various > MUST/SHOULDs are violated? > > Say initiator gets answer with exactly duplicated ZONEVERSION. What now? > And what if LABEL and TYPE are duplicate but with different SERIAL values? > What now? > > Drop it on the floor as signal FORMERR in both cases? Or process and display > as usual in the first but drop the second case? Or what? I think both of those options are fine because it probably depends on the client. Would you like to see text in the document saying so? > > > This is my generic complains with dnsop documents - they often do not say > what's expected behavior when constraints are violated. We can take it as a > though experiment and see where we get. > > > Ad one specific case which _is_ defined: > > A name server MUST ignore invalid ZONEVERSION options present in the query > > message. > > Does that mean that server MUST ignore ZONEVERSION query with 60 000 bytes of > payload and proceed as usual? I would say it warrants FORMERR :-) This will be changed to say that a server MUST return FORMERR, instead of just ignoring. DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
