Shane Kerr <sh...@time-travellers.org> 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 <d...@dotat.at> 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop