At Wed, 23 May 2018 15:32:11 +0000, "Weinberg, Matt" <mweinberg=40verisign....@dmarc.ietf.org> 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop