Report information
The Basics
Id:
36907
Status:
resolved
Priority:
Medium/Medium
Queue:
bind9-public
People
Owner:
Nobody in particular
Requestors:
Tomas Hozza <thozza@redhat.com>
Cc:
AdminCc:
BugTracker
Version Fixed:
(no value)
Version Found:
(no value)
Versions Affected:
(no value)
Versions Planned:
(no value)
Priority:
(no value)
Severity:
(no value)
CVSS Score:
(no value)
CVE ID:
(no value)
Component:
(no value)
Area:
(no value)
Dates
Created:Tue, 19 Aug 2014 07:05:19 -0400
Updated:Fri, 07 Jul 2017 20:13:35 -0400
Closed:Wed, 20 Aug 2014 13:09:39 -0400

This bug tracker is no longer active.

Please go to our Gitlab to submit issues (both feature requests and bug reports) for active projects maintained by Internet Systems Consortium (ISC).

Due to security and confidentiality requirements, full access is limited to the primary maintainers.

History
  Tue, 19 Aug 2014 07:05:19 -0400 Tomas Hozza <thozza@redhat.com> - Ticket created
Subject: BIND returns inconsistent data from cache for DS records
Date: Tue, 19 Aug 2014 13:05:07 +0200
To: bind9-bugs@isc.org
From: Tomas Hozza <thozza@redhat.com>

-----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-----
  Tue, 19 Aug 2014 14:26:05 -0400 Evan Hunt <each@isc.org> - Correspondence added
CC: undisclosed-recipients: ;
Subject: Re: [ISC-Bugs #36907] BIND returns inconsistent data from cache for DS records
Date: Tue, 19 Aug 2014 18:26:04 +0000
To: Tomas Hozza via RT <bind9-bugs@isc.org>
From: Evan Hunt <each@isc.org>

> 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.
Tue, 19 Aug 2014 14:26:05 -0400 The RT System itself - Status changed from 'new' to 'open'
  Wed, 20 Aug 2014 04:29:39 -0400 Tomas Hozza <thozza@redhat.com> - Correspondence added
Subject: Re: [ISC-Bugs #36907] BIND returns inconsistent data from cache for DS records
Date: Wed, 20 Aug 2014 10:29:33 +0200
To: bind9-bugs@isc.org
From: Tomas Hozza <thozza@redhat.com>

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
Wed, 20 Aug 2014 13:09:39 -0400 Evan Hunt <Evan_Hunt@isc.org> - Status changed from 'open' to 'resolved'
Fri, 07 Jul 2017 20:13:35 -0400 Vicky Risk <vicky@isc.org> - Queue changed from #6 to bind9-public