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

[George Michaelson]

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 <paul at redbarn.org> wrote:

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