From edmonds@mycre.ws  Wed Mar  9 20:53:31 2016
Delivered-To: bind9-bugs@bugs.isc.org
MIME-Version: 1.0
Subject: Unpresentable records cause AXFR failure?
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0
Return-Path: <edmonds@mycre.ws>
X-Original-To: bind9-bugs@bugs.isc.org
Content-Disposition: inline
Date: Wed, 9 Mar 2016 15:53:25 -0500
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.ams1.isc.org
content-type: text/plain; charset="utf-8"
Message-ID: <20160309205325.GA9403@mycre.ws>
To: bind9-bugs@isc.org
From: "Robert Edmonds" <edmonds@mycre.ws>
X-RT-Original-Encoding: ascii
X-RT-Interface: Email
Content-Length: 5657

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