[DNSOP] Re: Last Call: <draft-ietf-dnsop-zoneversion-09.txt> (The DNS Zone Version (ZONEVERSION) Option) to Informational RFC

["Wessels, Duane" <[e-mail]>]

> On Jul 4, 2024, at 1:55 AM, Petr Špaček <[e-mail]> 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