Bug #41900 for bind9-public: Unpresentable records cause AXFR failure?

Hi, According to the following erratum reported against RFC 6844: https://www.rfc-editor.org/errata_search.php?rfc=6844&eid=4061 Evan Hunt> Since the text representation of the tag field is unquoted, spaces and other whitespace must be explicitly excluded. Otherwise, it is possible to create a CAA record whose text representation cannot be parsed. Kathleen Moriarty> 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. Code has to work if someone creates a RR with a non conformant label, therefore a MUST does not saves any work. And the only circumstance in which the editor can imagine someone using it would be where they wanted a label that could not be inserted through normal zone files. This is kind of surprising. Off hand, I can't think of another DNS RR specification that intentionally created an RR type that "will work just fine" on the wire but has no valid canonical presentation format. I decided to test what would happen if I put a deliberately unrepresentable CAA record in a zone file. I put a CAA record like this in a test zone on a nameserver that doesn't have CAA support: caa TYPE257 \# 03 00 01 20 The tag value is a single ASCII space character, which trips the behavior reported in the erratum. As far as I can tell, this record should "work just fine" on the wire, according to RFC 6844: Tag Length: A single octet containing an unsigned integer specifying the tag length in octets. The tag length MUST be at least 1 and SHOULD be no more than 15. 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. It violates the "SHOULD NOT contain any other characters", which the IETF has apparently determined is definitely a SHOULD NOT and not a MUST NOT. dig, named, and named-checkzone from BIND 9.10.3 all barfed on this record: $ dig +norec @70.89.251.90 -t CAA caa.test.mycre.ws ;; Got bad packet: FORMERR 79 bytes 33 30 84 00 00 01 00 01 00 01 00 01 03 63 61 61 30...........caa 04 74 65 73 74 05 6d 79 63 72 65 02 77 73 00 01 .test.mycre.ws.. 01 00 01 c0 0c 01 01 00 01 00 00 0e 10 00 03 00 ................ 01 20 c0 10 00 02 00 01 00 00 0e 10 00 06 03 62 ...............b 73 74 c0 15 00 00 29 04 c4 00 00 00 00 00 00 st....)........ $ dig +norec @70.89.251.90 -t AXFR test.mycre.ws ;; Got bad packet: FORMERR 170 bytes b4 11 80 00 00 01 00 05 00 00 00 00 04 74 65 73 .............tes 74 05 6d 79 63 72 65 02 77 73 00 00 fc 00 01 c0 t.mycre.ws...... 0c 00 06 00 01 00 00 0e 10 00 23 c0 11 0a 68 6f ..........#...ho 73 74 6d 61 73 74 65 72 c0 11 78 2a 30 bc 00 00 stmaster..x*0... 1c 20 00 00 0e 10 00 09 3a 80 00 00 0e 10 c0 0c ........:....... 00 02 00 01 00 00 0e 10 00 06 03 62 73 74 c0 11 ...........bst.. 03 63 61 61 c0 0c 01 01 00 01 00 00 0e 10 00 03 .caa............ 00 01 20 02 6e 73 c0 0c 00 01 00 01 00 00 0e 10 ....ns.......... 00 04 46 59 fb 5a c0 0c 00 06 00 01 00 00 0e 10 ..FY.Z.......... 00 18 c0 11 c0 2d 78 2a 30 bc 00 00 1c 20 00 00 .....-x*0....... 0e 10 00 09 3a 80 00 00 0e 10 ....:..... $ named-checkzone test.mycre.ws /tmp/test.mycre.ws dns_rdata_fromtext: /tmp/test.mycre.ws:19: near eol: FORMERR zone test.mycre.ws/IN: loading from master file /tmp/test.mycre.ws failed: FORMERR zone test.mycre.ws/IN: not loaded due to errors. $ named -g [...] [...] 09-Mar-2016 15:10:08.883 zone test.mycre.ws/IN: Transfer started. 09-Mar-2016 15:10:08.883 transfer of 'test.mycre.ws/IN' from 70.89.251.90#53: connected using 70.89.251.89#55534 09-Mar-2016 15:10:08.883 transfer of 'test.mycre.ws/IN' from 70.89.251.90#53: failed while receiving responses: FORMERR 09-Mar-2016 15:10:08.883 transfer of 'test.mycre.ws/IN' from 70.89.251.90#53: Transfer status: FORMERR 09-Mar-2016 15:10:08.883 transfer of 'test.mycre.ws/IN' from 70.89.251.90#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.001 secs (0 bytes/sec) This is surprising. I was expecting named-checkzone to fail, and it's not too surprising that dig refused to print the message, but having the AXFR fail is quite interesting, because there is no presentation format involved (AFAIK), because named uses the "raw zone format" to store XFR'd zones. Just for chuckles, I violated a different key word in RFC 6844: "The tag length MUST be at least 1 and SHOULD be no more than 15" with the following record data: TYPE257 \# 18 00 10 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 This one has a 16 octet tag (consisting of 16 presentable "a"'s), and thus a tag length of 16 (which is one more than 15), thus it violates the SHOULD. This record is processed and presented just fine by BIND. Of course, this violation doesn't actually result in something impossible to parse. So, I'm kind of curious why violating a "SHOULD NOT" causes a red alert, up to and including causing zone transfers to fail, while violating a "SHOULD" is no big deal. (I realize SHOULD and SHOULD NOT are not quite symmetrical, but they are darn close.) -- Robert Edmonds

---

On Wed, Mar 09, 2016 at 10:14:48PM +0000, Robert Edmonds via RT wrote: > In the case where you have to render an unpresentable CAA record (for > instance because you might be writing a text master file format zone to > disk), couldn't you just fall back on RFC 3597 generic presentation > format for the record data? E.g., > > caa.example. IN CAA \# 03 00 01 20 Very smart suggestion, thank you.

---

People also expect nameservers to reject garbage in records which is what named and dig are doing when they can. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

---

In message <rt-4.2.8-32120-1457569482-131.41900-4-0@isc.org>, "Robert Edmonds v ia RT" writes: > Mark Andrews via RT wrote: > > I don't care what RFC 6844 says here. Once the code point is > > allocated the code point format is frozen. I also asked PHB about it and he confirmed it was ASCII only. This needs a erratra to say it is ASCII only. > Hi, Mark: > > In that case, why does BIND implement the URI RR format as specified by > RFC 7553 (actually, draft-faltstrom-uri-08), and not the URI RR format > as specified by the I-D at the point in time the URI RR type code point > was allocated? > > 3906. [protocol] Update URI record format to comply with > draft-faltstrom-uri-08. [RT #36642] Yes, I'm aware of that. I also don't like the change. One of the problems with expert review is that sloppy specs get through. > -- > Robert Edmonds > > > > -- > Ticket History: https://bugs.isc.org/Ticket/Display.html?id=41900 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

---

In message <rt-4.2.8-31497-1457575127-736.41900-4-0@isc.org>, "Evan Hunt via RT " writes: > On Thu, Mar 10, 2016 at 12:18:34AM +0000, Mark Andrews via RT wrote: > > People also expect nameservers to reject garbage in records which is > > what named and dig are doing when they can. > > See my previous statement about obvious correctness. However, since > other implementors are likely to follow the RFC and allow nonalphanumeric > characters, and this will affect interoperability, I think Robert's > suggestion of allowing such records in wire-format but switching to > unknown-type format when rendering them to text is a pretty good one. No, it won't. You need people to publish non ASCII tags which means first people need to decide to use a non ASCII tag in contravention of lots of text saying to only use ASCII. You also need to get them added to the Certification Authority Restriction Properties registry run by IANA. They then will be published as \DDD encoded strings by all the DNS tools if we were to permit non ASCII to pass. DNS developers testing ambigious corner cases will do this but no one else ever will. There is no need for non ASCII here. Tags are like SMTP commands. They don't need to be anything other than ASCII as they are not for human consumption. These records are designed to be consumed by machines automatically checking if particular operations are permitted. The RFC itself needs to be fixed. It is self contradictory. One of the following needs to be changed. 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. or Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower case. We don't need to do anything until that is decided. Mark > -- > Ticket History: https://bugs.isc.org/Ticket/Display.html?id=41900 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

---