From each@isc.org Wed Mar 9 21:46:31 2016 MIME-Version: 1.0 In-Reply-To: Content-Disposition: inline X-RT-Interface: API References: <20160309205325.GA9403@mycre.ws> Message-ID: <20160309214631.GA25960@isc.org> content-type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) by bugs.isc.org (Postfix) with ESMTP id 50A2671B5A8 for ; Wed, 9 Mar 2016 21:46:31 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 2E881216C1C; Wed, 9 Mar 2016 21:46:31 +0000 (UTC) Delivered-To: bind9-bugs@bugs.isc.org User-Agent: Mutt/1.5.23 (2014-03-12) 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 21:46:31 +0000 To: "Robert Edmonds via RT" From: "Evan Hunt" RT-Message-ID: Content-Length: 1210 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);