Shane Kerr <[email protected]> wrote:
> Wessels, Duane:
> >
> > This draft proposes a technique and new RR type for calculating and
> > verifying a message digest over the contents of a zone file. Using
> > this technique, the recipient of a zone containing the new RR type can
> > verify it for completeness and correctness, especially so when the
> > zone is signed. We welcome your feedback on this document.
>
> I think this is a great idea. Certainly one of the things that we were
> missing in the Yeti project was a way to confirm that the contents of
> the root zone transfered from any particular master were actually the
> correct version, so this fills a real need.
Yep, interesting.
A couple of thoughts/questions:
The sorting algorithm specifies CLASS as part of the sort key. This is
fine, but slightly redundant since all records in a zone have the same
class :-)
Regarding efficiency, I wonder if there would be much win from giving it a
bit more of a tree structure, e.g.
; similar ordering to RRSIG calculation
digest_RRset(n,r) = digest_algorithm( RRsig(i,1) | ... | RRsig(i,si) |
RR(i,1) | ... | RR(i,ri) )
digest_owner(n) = digest_algorithm( digest_RRset(n,1) | ... )
digest = digest_algorithm( digest_owner(1) | ... )
So when updating a zone, you can just recalculate the digests for the
affected owner names, then re-digest the string of digests. This should be
faster for signed zones, but it might not be a win for unsigned zones (a
SHA256 is about the same size as an A record).
(Following the hierarcial structure of owner names is probably not worth
it given the flatness of most zones.)
> Is it worth exploring the possibility of including multiple ZONEMD in a
> zone at different names, which digest the part of the zone up to that
> point?
Also a good idea :-) It probably needs to look a bit more like NSEC to
make it explicit which owners are covered.
Tony.
--
f.anthony.n.finch <[email protected]> http://dotat.at/
Plymouth, Biscay: West 5 to 7, occasionally gale 8 at first, backing south 3
or 4, occasionally 5 later. Rough or very rough. Showers, then fair. Good.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
