> On 8 Feb 2018, at 9:15 am, 神明達哉 <jin...@wide.ad.jp> wrote: > > At Thu, 8 Feb 2018 08:25:35 +1100, > Mark Andrews <ma...@isc.org> wrote: > >>> I happen to have this question while reading RFC6844: what does the >>> "matching" mean in the following description of Section 5.1? >>> >>> Tag: The property identifier, a sequence of US-ASCII characters. >>> >>> Tag values MAY contain US-ASCII characters 'a' through 'z', 'A' >>> through 'Z', and the numbers 0 through 9. Tag values SHOULD NOT >>> contain any other characters. Matching of tag values is case >>> insensitive. > [...] >>> Does this mean, for example, we should perform case-insensitive >>> comparison of this field when we compare CAA RDATAs? (If so, at least >>> ISC BIND 9 isn't compliant to the spec; it doesn't care about the case >>> of the tag field when loading or serving or updating or signing a CAA >>> RR). >> >> Why should it care about the case? ABC is different to abc as far as >> DNSSEC and handling of unknown record types is concerned. A signer >> that is CAA aware could remove “duplicates” that differ in the case >> of this field but nothing else can. > > I didn't intend to say it (DNS implementation) should care about the > case. My point (or question) was the RFC text can be ambiguous. On > re-reading RFC3597 I now see it would clearly violate Section 6 of > RFC3597: > > specifications for new RR types MUST NOT specify > type-specific comparison rules. > > if it meant case-insensitive RDATA comparison. But the current text > of RFC6844 made me think whether the RFC erroneously violated it or it > meant something else. It would have been clearer if "Matching of tag > values is case insensitive" were somewhere after Section 5.1, or at > least it explicitly said this is about CAs that use the CAA, not for a > DNS implementation. > > I'd also wonder what the "Canonical Presentation Format" means then: > > Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower > case. > > so, for example, we can't always safely dump a validly loaded zone > containing CAA whose tag has an upper-cased letter into a file in the > "canonical presentation format" and then re-load it, since the dump > can result in false duplicates. > > ...and now I see there was almost exactly the same discussion about 2 > years ago: > https://www.ietf.org/mail-archive/web/dnsop/current/msg16810.html > > Perhaps it's pretty clear that the current text of RFC6844 is very > confusing (if not wrong) and worth some errata again? > > -- > JINMEI, Tatuya
Software that processes CAA records returned by the DNS can remove any duplicates detected at that level of processing. The DNS isn’t in a position to do that de-duplication. For UPDATE I would always delete the CAA RRset and re-add it to update it rather than do it at the RR level. I believe the current RFC is enough for the records to be interpreted correctly if you don’t violate the SHOULD NOT. I don’t believe that they ever will contain values that violate that SHOULD NOT except in test suites. -- 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
