CC: undisclosed-recipients: ; MIME-Version: 1.0 In-Reply-To: Content-Disposition: inline References: <53F32F63.40306@redhat.com> Message-ID: <20140819182604.GA40936@isc.org> Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Received: from bikeshed.isc.org (bikeshed.isc.org [149.20.48.19]) by bugs.isc.org (Postfix) with ESMTP id DB0AB2D20571 for ; Tue, 19 Aug 2014 18:26:04 +0000 (UTC) Received: by bikeshed.isc.org (Postfix, from userid 10292) id C10C4216C31; Tue, 19 Aug 2014 18:26:04 +0000 (UTC) Delivered-To: bind9-bugs@bugs.isc.org User-Agent: Mutt/1.4.2.3i Subject: Re: [ISC-Bugs #36907] BIND returns inconsistent data from cache for DS records Return-Path: X-Original-To: bind9-bugs@bugs.isc.org Date: Tue, 19 Aug 2014 18:26:04 +0000 To: Tomas Hozza via RT From: Evan Hunt RT-Message-ID: Content-Length: 1155 > It seems like BIND will cache something wrong when doing the first query > with CD flag set, that makes it to answer inconsistently later on. > > This behavior is causing validation to fail when such BIND is used as a > forwarder. > > I'm going to debug BIND to see what's happening. I know it will be like > looking for needle in a haystack, that's why I'm reporting it to you > before I have any more clues. > > I would appreciate any hints where to look for the cause. jsonformat.com is violating protocol. Querying for NS or SOA gets NS or SOA, but all other data types get CNAME. You're not supposed to have CNAME at the zone apex, or have it coexist with other data types at the same node. The nonvalidating query for A put the CNAME record into the cache, and the nonvalidating query for DS found it -- the cache doesn't know there's a zone cut there, so it doesn't know the CNAME shouldn't be used to answer the DS query. I don't think there's anything we can do about this without violating protocol ourselves. jsonformat.com needs to get rid of that CNAME at the apex. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc.