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

[Paul Vixie]

g'day, mate. it's 1030pm here, so likely broad daylight down under.

> George Michaelson <mailto:ggm at apnic.net>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141201/0ab949b2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141201/0ab949b2/attachment.jpg>