<div dir="ltr">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. <div><br></div><div>I think we're silly to exclude mechanisms which are understandable by anyone, over what are (for much of their life) represented as files. </div><div><br></div><div>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.</div><div><br></div><div>At which point, I can canonicalize it, and apply checks against a published statement of the zones integrity.</div><div><br></div><div>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, </div><div><br></div><div>I won't post any more on this idea just now. I can tell that I am swimming against the tide.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 2 December 2014 at 16:13, Paul Vixie <span dir="ltr"><<a href="mailto:paul@redbarn.org" target="_blank">paul@redbarn.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
George Michaelson wrote:<br>
> Its not designed to handle dynamic updates. Its designed to handle<br>
> being given, or accessing an entire zone state, and having a<br>
> canonicalization method which can be applied by anyone, using POSIX<br>
> tools to determine if its correct and complete<br>
<br>
</span>george, dns is dynamic now. a signature method must address the update<br>
case. here's what i wrote in response to paul-h:<br>
<span class=""><br>
> i'm imagining a stream cipher that begins as the H(K,zone) and then is<br>
> updated to be H(K,H_old,delta) for each change to the zone, which<br>
> would have to be calculated by the responder in the case of UPDATE,<br>
> but could then be issued as a succession of new "zone signature" RR's<br>
> during IXFR. the "zone signature" RR would have to be like SOA,<br>
> there-can-be-only-one, so what might look like a "set" of them in an<br>
</span>> IXFR, is really a bunch of changes to the one-and-only. ...<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Paul Vixie<br>
</font></span></blockquote></div><br></div>