g'day, mate. it's 1030pm here, so likely broad daylight down under. > George Michaelson <mailto:[email protected]> > Monday, December 01, 2014 10:18 PM > I think the use of *must* here is non-normative. You make a strong > case that a canonicalization must understand dynamic update. But you > also chose to ignore a huge world of context where people are > presented with zones as a fait accompli. Not as participants in port > 53, but as files.
i'm sorry, friend, i didn't mean to leave those out. zones held in files which only change when the file is edited or regenerated are a special case of update, as in "zero updates". although BIND9 has a delicious "ixfr-from-differences" feature that can turn successive versions of a "primary zone file" into a stream of IXFR's, that's just gravy in this case. for your proposed use case, where the receiving end transfers a "zone file" and then runs posix tools to canonicalize it, extract its hash, and compare that hash to the hash of the canonicalized (by the way, spell check says i mean "cannibalized" and i'm not sure it's wrong) zone zone, would be entirely possible. i regret that i did not say so before. > > I think we're silly to exclude mechanisms which are understandable by > anyone, over what are (for much of their life) represented as files. yes, we would be, and so i'm not. as it were. > > There is a tool in bind which reads a .jnl. So, if I take the outcome > of a dynamic update, secure it in a transactionally complete .jnl, and > then apply the tool.. I have a file of a zone state, and a given point > in time, for a given serial. > > At which point, I can canonicalize it, and apply checks against a > published statement of the zones integrity. yes, and yes. vixie
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
