At Thu, 31 May 2018 18:18:16 +0000, "Wessels, Duane" <dwessels=40verisign....@dmarc.ietf.org> wrote:
> > - This digest can't be incrementally updated, [...] > > Incremental updates could be supported if the working group feels it is > important. We have a working proof-of-concept implementation of this that > hashes individual RRsets and then XORs them into a final message digest > (thanks to Roy Arends for the suggestion). It's just an observation, not a blocking issue. But I think it's worth discussing in the WG if and when this document is adopted. > > 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. > > We do not propose that owner names be permanently converted. DNSSEC has this > same characteristic, does it not? The validator canonicalizes the owner names > upon validation, but does not cache them canonicalized. Perhaps I wasn't clear. What I tried to say is that we can't notice that using this digest if 'WWW.EXAMPLE.COM. IN AAAA 2001:db8::1' is magically changed to 'www.example.com. IN AAAA 2001:db8::1' in the zone. This is also slightly related to the "problem statement". If the digest can detect this kind of change, it will be another new feature that DNSSEC-based integrity check can't detect. Of course, whether we want this feature is a different question. I wonder there might be a need for this by referring to the BIND 9 changes, but I don't know if it's real or just imaginary. > > - 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. > > If we say "calculated by concatenating ... all RRs in the zone" is that > sufficient? I'd be even more explicit, like 'all RRs in the zone including glue records' or 'all RRs in the zone including those on and below a zone cut'. BTW, there may be some interesting corner cases related to this point. If we configure the 'example.com' zone with the following records: d.example.com. IN DNAME d.example.org. a.d.example.com. IN AAAA 2001:db8::1 then, should the AAAA record be included in the digest? BIND 9 doesn't consider it an error, does load it into memory and transfer it via AXFR, and, IIRC, would use it to answer queries if the DNAME is removed via DDNS or IXFR. So this question has a practical implication at least for such an implementation. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
