Re: [DNSOP] Second Working Group Last Call for: Message Digest for DNS Zones

[Dick Franks <[e-mail]>]

draft-ietf-dnsop-dns-zone-digest-04 is still a work in progress, with a
number of internal contradictions to be resolved.


[1.2 para 1]

   ...  The procedures for digest calculation and DNSSEC
   signing are similar (i.e., both require the same ordering of RRs) and
   can be done in parallel.

There is no requirement for the RR collating sequence be the same as
DNSSEC, otherwise it would be impossible for there to be more than one
scheme.

[3.1 para 1]

   In preparation for calculating the zone digest, any existing ZONEMD
+  and covering RRSIG
   records at the zone apex are first deleted.

[3.1 para 1]

   Prior to calculation of the digest, and prior to signing with DNSSEC,
   a placeholder ZONEMD record is added to the zone apex.

reword as follows:

   Prior to calculation of the digest, and prior to signing with DNSSEC,
   exactly one placeholder ZONEMD record is added to the zone apex.

[3.1 para 5]

reword as follows:

   If multiple digests are to be published in the zone, e.g., during an
   algorithm rollover, each digest calculation is performed independently
   using the placeholder for the corresponding Scheme and Hash Algorithm.

[3.2]

s/signature(s)/signature/

There can never be more than one.

[3.3] and [3.3.1]

    This specification adopts DNSSEC's canonical on-the-wire RR format
    (without name compression) as specified in [RFC4034].

       RR(i) = owner | type | class | TTL | RDATA length | RDATA

       where "|" denotes concatenation.

The record collating sequence is scheme specific.

[3.4 bullet 3]

   o  Only one instance of duplicate RRs with equal owner, class, type
      and RDATA SHALL be included ([RFC4034] Section 6.3).

This seems to detract from the idea of a general purpose comparison
advertised in 1.3.5. If unexpected duplicate RRs were to be present in
the original zone, the downstream copy should be expected to match,
warts and all.

[3.5.1 para 5]

Needs to be incorporated into 3.3.

[3.6]

reword:

   Once a zone digest has been calculated, the published ZONEMD record
   is finalised by inserting the digest into the placeholder ZONEMD.
   Repeat for each digest if multiple digests are to be published.

   If the zone is signed with DNSSEC, the RRSIG record covering
   the ZONEMD RRSet MUST then be added or updated.


Dick Franks
________________________