Re: [DNSOP] meaning of tag "match" for CAA RDATA

[Mark Andrews <[e-mail]>]

> On 8 Feb 2018, at 9:15 am, 神明達哉 <[e-mail]> wrote:
> 
> At Thu, 8 Feb 2018 08:25:35 +1100,
> Mark Andrews <[e-mail]> 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: [phone]              INTERNET: [e-mail]