> On 9 Mar 2020, at 17:10, Dick Franks <rwfra...@gmail.com> wrote:
>
> 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.
I see no proof for this claim.
> [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.
para 5 is about filling out the RRset to have a ZONEMD placeholder record
for each <Scheme,Hash Algorithm> pair.
> [3.2]
>
> s/signature(s)/signature/
>
> There can never be more than one.
Actually there can be multiple RRSIG for ZONEMD so plural is correct.
> [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.
Do you really want to update every AXFR implementation on the planet?
RFC 5936
Each RR SHOULD be transmitted only once, and
AXFR clients MUST ignore any duplicate RRs received.
> [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
> ________________________
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
