Re: [DNSOP] Incremental zone hash - XHASH

[George Michaelson <[e-mail]>]

The intent (to me at least) is to be able to use exterior fetch, *not*
DNS, to source this as a file. curl. wget. ncftp. rsync.

the "thing" is a file object. It almost certainly is in near-canonical
sort order already. Its a stream of characters, probably in
bind-normal form.

If you can compute the path through the labels and the chain of NSEC
regions and the expected hadda-yadda-dadda.. you don't *need* a
digest.

If you have a digest, and its already in near canonical order, then
*cost* to compute "is the file exactly as the publisher wrote it" is
low. And, since its a signature under the ZSK, its not just "its as
the publisher said" its "the publisher knows the ZSK" which is strong
enough to say: "just load it"

So, I ask: is this incremental method applicable to this model?

Sure, works for giant zone. What about a root zone? Do I need this?

Also.. glue.

-G

On Fri, Jul 20, 2018 at 6:31 AM, Mark Andrews <[e-mail]> wrote:
> Rather than having a full zone hash this can be done as a chain
> of hashes (XHASH).
>
> The XHASH would include all records at a signed name (where a signed
> name is NOT an NSEC3 name) up until the next signed name (where a
> signed name is NOT a NSEC3 name) in DNSSEC order similar to ZONEMD.
> If there is a NSEC3 record and its RRSIGs in this range it is included
> in the hash computation.  Where a NSEC3 record matches the name of a
> record that exists in the zone it is hashed with that name. The record
> type appears at both top and bottom of zone similar to NS.
>
> The chain is only deemed to be complete if there is a hash record at
> the zone apex. This allows for incremental construction and destruction
> of the XHASH chain similar to the way the presence of NSEC at the zone
> apex indicates that chain is complete.
>
> If there are records that are not at or under the zone apex they are included
> in the final XHASH of the zone sorting from the zone apex to the end of the
> namespace then from the start of the namespace to the zone apex. Such records
> at not normally visible to queries other than AXFR/IXFR.  AXFR/IXFR permit such
> records.
>
> XHASH would allow for UPDATE to incrementally adjust the chain without
> having to hash the entire zone at once.
>
> XHASH would allow for a slave server to verify a zone is still complete
> after a IXFR by just checking the areas of the zone impacted by the IXFR.
>
> e.g.
>
>         example.com SOA
>         example.com NS ns.example.com
>         example.com DNSKEY …
>         example.com NSEC a.example.com NS SOA RRSIG NSEC DNSKEY XHASH
>         example.com XHASH …
>
>         a.example.com NS ns.a.example.com
>         a.example.com NSEC b.example.com NS RRSIG NSEC XHASH
>         a.example.com XHASH …
>         ns.a.example.com A …
>
>         b.example.com NS ns.b.example.com
>         b.example.com NSEC ns.example.com NS RRSIG NSEC XHASH
>         b.example.com XHASH …
>         ns.b.example.com A …
>
>         ns.example.com A …
>         ns.example.com AAAA …
>         ns.example.com NSEC example.com A AAAA RRSIG NSEC XHASH
>         ns.example.com XHASH …
>
> Each of the groupings shows which records plus RRSIGs that are
> included in the XHASH calculation.
>
> To prevent removal/introduction of RRSIGs of XHASH records a DNSKEY
> flag bit is be needed to indicate which RRSIG(XHASH) should/should not
> be present once the chain is complete.  The same applies to RRSIG(ZONEMD).
>
> Verification of a AXFR would be slightly slower than with ZONEMD as there
> are more RRSIG records to be processed,
>
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]              INTERNET: [e-mail]
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop