[dns-operations] Assuring the contents of the root zone

[George Michaelson]

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 <paul at redbarn.org> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141202/5e4e694f/attachment.html>