Here is a strawman, to try and understand the discussion. If we imagine some datastream which is the result of an AXFR or HTTP request.
<cmd> | tr 'AZ' 'az'| sort -u | <checker> this takes the stream, does LWSP replacement, and sorts the lines alphabetically and generates eg SHA256 the tr phase is just for example. presumably a more complex set of rules are required to DeMangLE the case conversion and punycode but the sense is, that we have a deterministic state of any label in the zone and its attributes as an encoding. The sort phase generates a single understood (POSIX sort) order of bytes. These can then be compared. Why is this worse than eg an RR by RR comparison, walking the NSEC chains? What I like about it, is that its applicable to being given the data OOB. if you have what is a putative zone, then you can apply this logic, and determine if the zone matches what is published elsewhere as a canonical state of the zone. The RR by RR and NSEC walk feels like a DNS experts approach. Not a systems/generic approach. -G On 2 December 2014 at 11:29, Paul Vixie <[email protected]> wrote: > > > Paul Hoffman <[email protected]> > 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> > <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. > > 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
