> On Apr 4, 2018, at 6:15 AM, Tony Finch <[email protected]> wrote: > > 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 :-)
Okay. I managed to convince myself that zone files could contain multiple classes, but looking now I see in 1035 it says "All RRs in the file should 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. My initial reaction is that I'm not fond of the complexity, but would like to hear if people think zone digest is useful for the types of zones where recalculation is a significant concern. DW _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
