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

Paul Vixie paul at redbarn.org
Tue Dec 2 01:29:59 UTC 2014

> Paul Hoffman <mailto:paul.hoffman at vpnc.org>
> Monday, December 01, 2014 3:48 PM
> People have asked for two things:
> 1) Getting the root zone by means other than AXFR, such as by HTTP
> 2) Being sure that they got the exact root zone, including all of the
> glue records

i think you meant "zone" not "root zone" here.
> A signed hash meets (2) regardless of how the zone was transmitted.

not inevitably. the verification tool would be new logic, either built
into the secondary name server, or as an outboard tool available to the
transfer mechanism. when i compare the complexity-cost of that tool to
the contents of the <ftp://ftp.internic.net/domain> directory, i see
that existing tools whose complexity-cost i already pay would work just
fine. (those being pgp and md5sum). so, a detached signature can in some
cases meet (2) far more easily than an in-band signature.

it's also the case that rsync and similar tools (and AXFR) use TCP which
most of us consider "reliable" even though its checksums aren't nearly
as strong as SCTP's. therefore your problem statement "being sure they
got the exact right zone" would have to refer to an MiTM, possibly
inside the secondary server (if the zone receiver is a tertiary), or
possibly on-path. in either case, to frustrate the MiTM, the proposed
in-band signature would have to be DNSSEC based.

and there is already an in-band DNSSEC-based zone identity/coherency
test -- zone walking. why would we add another way to do the same thing
we could do with existing DNSSEC data?
> ...
> Adding a record that says "here is a hash of this zone", and adding an
> RRSIG for that record, is the simplest solution. There are other
> solutions that are exactly as secure; however, they are all more
> complex, and some involve using the zone signing key for signing
> something other than the contents of an RRSIG.
i think walking the existing zone and verifying that there are no
records between the nsecs and that every signature is valid and that the
nsec chain ends at the apex, is simpler.

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

More information about the dns-operations mailing list