At Wed, 23 May 2018 15:32:11 +0000,
"Weinberg, Matt" <[email protected]> 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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
