Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[Shane Kerr <[e-mail]>]

Wessels, Duane:
> 
>> On May 25, 2018, at 11:33 AM, 神明達哉 <[e-mail]> wrote:
>>
>> At Wed, 23 May 2018 15:32:11 +0000,
>> "Weinberg, Matt" <mweinberg=[e-mail]> 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