> Matthew Pounsett <mailto:[email protected]> > 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
_______________________________________________ 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
