From edmonds@mycre.ws Wed Mar 9 22:14:47 2016 MIME-Version: 1.0 In-Reply-To: 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 Content-Disposition: inline X-RT-Interface: API References: <20160309205325.GA9403@mycre.ws> <20160309214631.GA25960@isc.org> Message-ID: <20160309221444.GA13890@mycre.ws> content-type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by bugs.isc.org (Postfix) with ESMTP id A6DF071B5A8 for ; Wed, 9 Mar 2016 22:14:47 +0000 (UTC) Received: from chase.mycre.ws (chase.mycre.ws [70.89.251.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "chase.mycre.ws", Issuer "mycre.ws" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id E7F343493BB for ; Wed, 9 Mar 2016 22:14:45 +0000 (UTC) Received: by chase.mycre.ws (Postfix, from userid 1000) id ABD2712C1CFA; Wed, 9 Mar 2016 17:14:44 -0500 (EST) Delivered-To: bind9-bugs@bugs.isc.org Subject: Re: [ISC-Bugs #41900] Unpresentable records cause AXFR failure? Return-Path: X-Original-To: bind9-bugs@bugs.isc.org Date: Wed, 9 Mar 2016 17:14:44 -0500 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.pao1.isc.org To: "Evan Hunt via RT" From: "Robert Edmonds" RT-Message-ID: Content-Length: 2431 Hi, Evan: It does seem pretty bizarre that an RR would be defined that can have valid on-the-wire RRs that have no corresponding canonical presentation format. 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 That would be a lot better than failing the zone transfer entirely. If the argument is that an on-the-wire RR might eventually make its way into a code path that might cause the wire RR to be rendered to its canonical presentation format, then maybe the erratum should be approached from the other direction: instead of trying to ban unpresentable characters from the wire format (like in your original erratum) in section 5.1, relax the requirements on the canonical presentation format in section 5.1.1 so that the presentation format can encompass all possible wire values. (Maybe require \DDD escapes for non-alphanumeric characters, so you would write ASCII space as "\032".) Evan Hunt via RT wrote: > I did that RR type implementation several months before I got the response > from the author on the proposed erratum. Under the supposition that the > author would agree with my obvious correctness, I put in a requirement > that all characters in labels be alphanumeric. > > As it turned out my correctness wasn't obvious to the author after all, > and perhaps I should have revisted the coding decision then. > > The problem is, if BIND receives a zone transfer containing a record like > this, it's quite likely to dump a copy of the zone to disk, and if it's > using masterformat "text", then it won't be able to reload the zone > afterward. This admittedly isn't a huge problem -- it wastes time on > unnecessary retransfers, and wastes disk space on copies of the "bad" > zone file left around for inpsection, but it doesn't prevent the server > from working -- but it is a problem. It really should've been caught > before the CAA code point was issued. > > Anyway, removing the following lines from lib/dns/rdata/generic/caa_257.c > should make the FORMERR go away: > > /* Check the Tag's value */ > for (i = 0; i < len; i++) > if (!alphanumeric[sr.base[i]]) > RETERR(DNS_R_FORMERR); -- Robert Edmonds