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

[神明達哉 <[e-mail]>]

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.  In that
   primary case we should be able to check the integrity of the
   entire zone with DNSSEC (including a complete list of authoritative
   names and RR types for each name), right?  One thing I can think of
   is integrity including glue records, but it's not clear from the
   draft whether the digest includes these records (see also below),
   and even if so, it seems to be a relatively minor addition.  So I'm
   wondering I'm missing something very trivial.  Even so, it would be
   nice to clarify the intended advantage(s) over DNSSEC-based
   integrity check for the root zone case.

- 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.

Specific comments:

- Section 4.1

    This specification adopts DNSSEC's canonical ordering for names
    (Section 6.1 of [RFC4034]), and canonical ordering for RRs within an

   This means upper case letters in owner names are converted to lower
   case ones.  It could be considered a feature, but I guess some
   operators might want to check integrity including letter case of
   names.  For example, recent versions of ISC BIND 9 tries quite hard
   to preserve the letter case of owner names per RRset basis, which I
   think suggests operator needs for preserving the case as much as
   possible.

- Section 4.1.2

    [...]  However, according to the
    requirement to sort RRsets with the same owner name by type, the SOA
    RR (type value 2) might not be first in the digest calculation.  If
    the zone has an A RR (type value 1) at the apex, it MUST be processed
    before the SOA RR.

   SOA's type value is 6, not 2.  This also means you might rather want
   to use NS (type value 2) instead of A, since you don't need to add
   'if', as long as the zone is reasonably valid to have both SOA and
   NS.

- Section 4.4

    The zone digest is calculated by concatenating the canonical on-the-
    wire form of RRs in the zone, in the order described above, subject
    to the inclusion/exclusion rules described below, and then applying
    the digest algorithm:

   I wonder whether glue records are included in these RRs.  Either
   way, it would be better to clarify the point.

- Section 4.5

    If the zone is signed with DNSSEC, the appropriate RRSIG records
    covering the ZONEMD record MUST then be added.  Because the ZONEMD
    placeholder was added prior to signing, the zone will already have
    the appropriate denial-of-existence (NSEC, NSEC3) records.

   I would suggest clarifying that this 'resigning' MUST NOT change the
   SOA serial (it MUST NOT, right?).  It may depend on specific
   implementation or operational practices, but I know of
   implementations that increase the serial for every such incremental
   resigning.  So it would be prudent to explicitly note that this case
   is an exception for such practices.

--
JINMEI, Tatuya