In message <[email protected]>, Robert Edmonds writes: > Hi, > > Dick Franks wrote: > > On 11 March 2016 at 17:47, Robert Edmonds <[email protected]> wrote: > > > > > Dick Franks wrote: > > > > There is no need to resort to doctrinal arguments about > MUST/SHOULD, or > > > > imagine that the RFC6844 tail can wag the RFC1035 dog. > > > > > > > > Mark A's objection really points a fundamental contradiction in > RFC6844 > > > > itself. > > > > > > Hi, Dick: > > > > > > Are you implying that 6844 violates 1035 in some way? > > > > > > 6844 5.1.1 defines the tag field in a way which forbids the (arbitrary) > > characters which MAY (but SHOULD NOT) be present according to the text > in > > 5.1. > > It's clear from the context that 6844 5.1 is talking about the wire > format, while 5.1.1 is talking about the presentation format. If the > rules for the canonical presentation format are stricter than the rules > for the wire format, then there exist wire RRs that cannot be > represented using the canonical presentation format. Which, the > verifier's notes in erratum 4061 claim, is OK, and not a contradiction.
That's only the verifier's opinion (sorry Kathleen). Master files are used for zone transfers (see STD 13). They need to be able to represent all records. Master file parsers need know when they are being presented with garbage or well formed records. The RFC does not do that. Unknown format is for *unknown* records not *know* records. If the text representation cannot represent *every* record for that type then the RFC is *broken*. If CAA want implementations to use unknown format then the RFC should say that. [ There are some other DNS type RFC's that could be updated to say the same thing. ] Note saying that the canonical format is lower case causes potential DNSSEC issues if record get written out in canonical form then get read back in as there is potential for case change which will cause RRSIGs to no longer match. > > This conflicts with the 1035 notion that master files contain text > > representation of RRs. > > Any instance of a cacheable wire RR has a master file compatible text > representation, thanks to the generic text encoding defined in RFC 3597. > > 1035 doesn't distinguish between canonical and generic text > representation because the generic encoding hadn't been invented yet, of > course. > > > I understand the > > > reasoning in the erratum rejection: > > > > > > ... > > > > > > The author believes SHOULD is correct here. The protocol on the > wire > > > will work just fine if someone breaks this advice. > > > > > > Yes, it might well break some zone file parsers. But those aren't > on > > > the wire and that type of incompatibility is exactly what I would > > > expect from violating a SHOULD. > > > > > > ... > > > > > > to be asserting that a valid wire format RR can have no valid > canonical > > > presentation format. > > > > > > But CAA _does_ have a canonical presentation format, defined at 5.1.1. > > Sorry, I meant to say that the erratum rejection asserts that there can > exist instances of valid on-the-wire RRs of known type that don't have a > valid canonical presentation form. > > > The closest requirement I can find in 1035 is this: > > > > > > 5. MASTER FILES > > > > > > Master files are text files that contain RRs in text form. Since > the > > > contents of a zone can be expressed in the form of a list of RRs a > > > master file is most often used to define a zone, though it can be > used > > > to list a cache's contents. > > > > > > > So are you really suggesting flipping between canonical 6844 format and > > 3597 \# format merely because the tag field happens to contain some > > non-alphanumeric character or upper case letter? > > Yes. If a RR can't be presented canonically, how else would you do it? > > This is apparently exactly how BIND handles LOC records whose VERSION > field is not 0, BTW: There are subtle difference between LOC and CAA. While it is forseeable that we may need to define a different version we have no idea what that version will be. For tags we do actually have ideas about what that could be as we have deliberately choosen to restrict the syntax of the tag from the set of all known characters. CAA could have defined the tag to be a UTF-8 string. CAA could have defined it to be a arbitary ASCII string. It could have defined the canonical presentation format to be a printable lowercase ASCII string with a prefered syntax of a-z, 0-9 or escaped UTF-8 with A-Z mapped to a-z. The record is just plainly poorly defined as different implementors have different ideas about what is meant to be supported and that is causing problem. PKIX needs to fix this. Once they fix this the nameserver vendors can fix implementations to match. > $ dig +norec @70.89.251.90 -t AXFR test.mycre.ws > > ; <<>> DiG 9.10.3 <<>> +norec @70.89.251.90 -t AXFR test.mycre.ws > ; (1 server found) > ;; global options: +cmd > test.mycre.ws. 3600 IN SOA mycre.ws. hostmaster.mycre.ws. > 2016031104 7200 3600 604800 3600 > test.mycre.ws. 3600 IN NS bst.mycre.ws. > loc.test.mycre.ws. 3600 IN LOC \# 16 FF0000C0237F0000B02600C0237F0000 > loc2.test.mycre.ws. 3600 IN LOC 42 21 28.764 N 71 0 51.617 W > -100000.00m 2000m 10000m 10m > test.mycre.ws. 3600 IN SOA mycre.ws. hostmaster.mycre.ws. > 2016031104 7200 3600 604800 3600 > ;; Query time: 0 msec > ;; SERVER: 70.89.251.90#53(70.89.251.90) > ;; WHEN: Fri Mar 11 15:58:01 EST 2016 > ;; XFR size: 5 records (messages 1, bytes 197) > > > > RFC6844 offers no justification for case folding, so > > > > specifying exact matching would make the whole issue go away. > > > > > > I would hazard a guess that the "Matching of tag values is case > > > insensitive" sentence is a requirement on applications that consume > the > > > RR, and not to DNS protocol comparisons like RRset data equality or > > > DNSSEC canonical form. (Note the sentence "Applications that interpret > > > CAA records..." a few lines up.) > > > > > > > An unnecessary complication in my view, but maybe that is off-topic > here. > > Well, speaking of unnecessary complications, maybe the practice of > defining data RRTYPEs with canonical presentation formats that can only > represent a subset of valid on-the-wire RRs ought to be explicitly > banned going forward. > > -- > Robert Edmonds > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
