Wessels, Duane: > >> On May 25, 2018, at 11:33 AM, 神明達哉 <jin...@wide.ad.jp> wrote: >> >> At Wed, 23 May 2018 15:32:11 +0000, >> "Weinberg, Matt" <mweinberg=40verisign....@dmarc.ietf.org> wrote: >> >>> We’ve posted a new version of draft-wessels-dns-zone-digest. Of note, >> this -01 version includes the following changes: >> [...] >>> We plan to ask for time on the dnsop agenda in Montreal. Your feedback >> is welcome and appreciated. >> >> I've read the draft. I have a few high level comments and specific >> feedback on the draft content: >> >> - It was not really clear exactly what kind of problem this digest >> tries to solve, especially given that the primarily intended usage >> is for the root zone, which is DNSSEC-signed with NSEC. > > Thanks you for the feedback. We will write a clearer problem statement > in the introduction for the next version.
As I mentioned, I have seen zones broken during transfer in production, and having a standard way to check for this seems reasonable. >> - This digest can't be incrementally updated, that is, you'll need to >> calculate the digest over the entire zone even if just a single >> record is modified (am I correct?). That's probably an inevitable >> cost for the motivation of providing cryptographically strong >> integrity check, but that's a pity for me. One case I know of where >> things like "zone digest" is wanted is to ensure consistency for a >> very large zone between primary and secondary servers that are >> synchronized using IXFR. In principle they must be consistent, but >> operators may want to have a lightweight (albeit not >> cryptographically strong) way to confirm no unexpected events (such >> as an implementation bug) quietly broke the consistency. Perhaps >> such usage is just outside the scope of this proposal, but I first >> expected I could use it for this kind of purpose it was a bit >> disappointing and I wanted to mention it. > > Incremental updates could be supported if the working group feels it is > important. We have a working proof-of-concept implementation of this that > hashes individual RRsets and then XORs them into a final message digest > (thanks to Roy Arends for the suggestion). > > However, this complicates the implementation. It almost certainly requires > more CPU processing but probably not to an extent that matters significantly. > We could do some simple benchmarks. > > If there is desire to follow this path, then we should discuss whether or > not to keep having the zone digest algorithms exactly match the DS digest > algorithms. For example, digest alg 2 could mean "SHA256 over the zone > as a whole" while digest alg 3 could mean "SHA-256 digest and XOR individual > RRsets" to support incremental updates. As I mentioned in my review of the first version of this document, I think that inserting digest records periodically throughout the zone could serve to allow incremental updates (as the recipient can cache unchanged values) and also allow a degree of parallelism. I certainly won't push for it. My main concern is that for large-ish zones with frequent updates digest is basically useless without such a mechanism. Cheers, -- Shane _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
