*Sigh* Not exactly. If you have no automated applications that will use this, then it depends on the human and I think that's what you mean by "application". Otherwise, I think you'll find that most automated applications will want to (or probably should want to) use the same logic.
I'm sorry, but that continues to make no sense.
If it's an AXFR to a secondary authoritative server you might do one thing, if it's someone collecting stats on TLD zone files, they might do something else.
I actually have automated software doing both of those. As I may have said once or twice, it depends on the context.
"Do the same thing you do now when a zone is invalid."Given that there's no fixed definition of when a "zone" is invalid, I don't think I can do the "same thing"? See below for a screed on data protocol vs transport protocol.
Sheesh. Invalid == contents do not comply with RFC specifications
Now comes ZONEMD which wants to make a zone database wholly coherent - ANY change in the contents of the zone will result in changes to the ZONEMD record and to verify it, you MUST download exactly the same data as was digested previously. Unlike changes to the SOA serial, this record binds the entire zone to be a very specific set of bits.
Right. It's long overdue. If you want to do incremental updates, that's fine, but that's not what this incarnation of ZONEMD binds.
Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
