[dns-operations] cool idea regarding root zone inviolability

[Paul Vixie]

> Matthew Pounsett <mailto:matt at conundrum.com>
> Saturday, November 29, 2014 12:56 PM
>
> People move zone data around using mechanisms other than *XFR (scp,
> database replication, etc.). A signature on the complete zone, as part
> of the zone, also covers those mechanisms.

can you tell me the use case for having this signature be in-band? that
is, i know that detached signatures like pgp or detached strong hashes
like md5 can be used to verify zone content in an out-of-band transfer
(not using *XFR, as you describe.) you're intimating a need for an
in-band signature so that the local secondary server can know, when
loading the zone, that the zone is complete. since some extant
out-of-band transfer methods (copying an mmap file, or updating an HA
database) do not require that the secondary server fully read the zone
before they begin serving that zone, it strikes me that for zones
containing tens or hundreds of millions of records, adding per-zone
signature would imply such a high burden for these sparse-access
secondary implementations (that is, we didn't have to read the whole
zone to verify the signature before, but, now that there's a zone
signature to be verified, we have to read the whole thing and verify the
signature before we can start serving it) that it would not be used.

my supposition has always been that if you're using an out-of-band
transport (not IXFR/AXFR) to move zones around, then your out-of-band
transport will do its own signing and verification.

let me please note for the record that i long for a secure hash of zone
content, but i don't know how to create one that can be updated (when an
UPDATE is received at the primary server or an IXFR is received at the
secondary server) and still have that hash be secure.

-- 
Paul Vixie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141129/8c763f5f/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/20141129/8c763f5f/attachment.jpg>