Subject: BIND returns inconsistent data from cache for DS records
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
Date: Tue, 19 Aug 2014 13:05:07 +0200
content-type: text/plain; charset="utf-8"
Message-ID: <53F32F63.40306@redhat.com>
To: bind9-bugs@isc.org
Content-Transfer-Encoding: 7bit
From: Tomas Hozza <thozza@redhat.com>
Content-Length: 2043

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello.

We discovered a inconsistent BIND behavior when querying it for DS
records. The response differs if BIND was queried for a different type
of record for the same domain name.

I reproduced this with BIND 9.9.4 on Fedora 20. I may try the latest
BIND 9.10 beta version.

The BIND was configured with:

dnssec-enable yes;
dnssec-validation auto;
dnssec-lookaside no;

When running:
1. rndc flush
2. dig jsonformat.com @127.0.0.1 +dnssec -t A +cdflag
3. dig jsonformat.com @127.0.0.1 +dnssec -t DS +cdflag
4. dig jsonformat.com @127.0.0.1 +dnssec -t DS +nocdflag

I get different answer in (3.) and (4.).

When running:
1. rndc flush
2. dig jsonformat.com @127.0.0.1 +dnssec -t A +nocdflag
3. dig jsonformat.com @127.0.0.1 +dnssec -t DS +cdflag
4. dig jsonformat.com @127.0.0.1 +dnssec -t DS +nocdflag

or if the (2.) is omitted completely I get the same response in (3.) and
(4.).

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.

Thank you in advance.

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

PGP: 1D9F3C2D
Red Hat Inc.                               http://cz.redhat.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJT8y9jAAoJEMWIetUdnzwtqt8H/iBCEL7xNGyCcCYu8t+llvwM
RBgwpb0ArJVxRO2C37zxHzuNxVVpS9yKk7fi8/fKd4F/Aub1mToCxG6kbx0H437i
kiBTkRI8qAVfBrXGdvKq3V6L01REB/PZtRMdmHjyj/4g63MC9qnvFmaugEg4TMaR
mzvEI+0JrsoJs91d2en3EUC2gYY6YkTuZZjn1XzOET+/rYitFsd7lZ3Rey5yGJIM
GJQpl3zL0uwjrlg4M16EGP18anyDZMfiBds98A9DbQOU5shIHfm4kFZxbJ3SOd2c
yjvVc+9+VR1gou9GEHY9UKKI6Ey5jfxz5KnjqHcaVJ/0OrU9MnesDFJ6Nsp4PDc=
=juDf
-----END PGP SIGNATURE-----