Hi, Dick Franks wrote: > On 11 March 2016 at 17:47, Robert Edmonds <edmo...@mycre.ws> 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. > 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: $ 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
