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 think we're silly to exclude mechanisms which are understandable by anyone, over what are (for much of their life) represented as files. 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. I don't want to exhaust anyones patience. I've said my bit, I am content if you have some closing last word on this, I won't post any more on this idea just now. I can tell that I am swimming against the tide. On 2 December 2014 at 16:13, Paul Vixie <[email protected]> wrote: > > > George Michaelson wrote: > > Its not designed to handle dynamic updates. Its designed to handle > > being given, or accessing an entire zone state, and having a > > canonicalization method which can be applied by anyone, using POSIX > > tools to determine if its correct and complete > > george, dns is dynamic now. a signature method must address the update > case. here's what i wrote in response to paul-h: > > > i'm imagining a stream cipher that begins as the H(K,zone) and then is > > updated to be H(K,H_old,delta) for each change to the zone, which > > would have to be calculated by the responder in the case of UPDATE, > > but could then be issued as a succession of new "zone signature" RR's > > during IXFR. the "zone signature" RR would have to be like SOA, > > there-can-be-only-one, so what might look like a "set" of them in an > > IXFR, is really a bunch of changes to the one-and-only. ... > > -- > Paul 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
