MIME-Version: 1.0
In-Reply-To: <rt-3.8.6-3602-1408472765-63.36907-5-0@isc.org>
References: <RT-Ticket-36907@isc.org> <53F32F63.40306@redhat.com> <rt-3.8.6-3034-1408446319-301.36907-3-0@isc.org> <20140819182604.GA40936@isc.org> <rt-3.8.6-3602-1408472765-63.36907-5-0@isc.org>
Message-ID: <53F45C6D.7030205@redhat.com>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [ISC-Bugs #36907] BIND returns inconsistent data from cache for DS records
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
Date: Wed, 20 Aug 2014 10:29:33 +0200
To: bind9-bugs@isc.org
Content-Transfer-Encoding: 7bit
From: Tomas Hozza <thozza@redhat.com>
RT-Message-ID: <rt-3.8.6-3456-1408523379-1553.36907-0-0@isc.org>
Content-Length: 1512

On Tue 19 Aug 2014 08:26:05 PM CEST, Evan Hunt via RT wrote:
>> 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 see now. You are right that the domain is misconfigured and violates 
RFC1034 (section 3.6.2) and RFC1912 (section 2.4).

> 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.

I agree.

Thank you very much for your explanation.


Regards,
--
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.                               http://cz.redhat.com