Report information
The Basics
Id:
36196
Status:
open
Priority:
Medium/Medium
Queue:

People
Owner:
Nobody in particular
Requestors:
Cc:
AdminCc:

BugTracker
Version Fixed:
(no value)
Version Found:
(no value)
Versions Affected:
(no value)
Versions Planned:
(no value)
Priority:
P1 High
Severity:
S1 High
CVSS Score:
(no value)
CVE ID:
(no value)
Component:
(no value)
Area:
bug

Dates
Created:Wed, 04 Jun 2014 06:14:20 -0400
Updated:Fri, 07 Jul 2017 21:14:17 -0400
Closed:Not set



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.

Subject: in-line signing: raw and secure zones getting out-of-sync
Date: Wed, 04 Jun 2014 12:14:14 +0200
To: bind9-bugs@isc.org
From: Petr Spacek <pspacek@redhat.com>
Hello, I have found a bug in in-line signing. Raw and secure zones can get out-of-sync in one (weird) corner case. Version: bind-9.9.4-12.P2.fc20.x86_64 Steps to reproduce the problem ============================== 1) Configure insecure master zone "inline.test." and allow dynamic updates for it. 2) Do a dynamic update: # nsupdate << EOF update add a.inline.test. 3600 IN A 10.0.0.1 send EOF 3) Shutdown server: # rndc halt 4) Enable in-line signing for zone "inline.test." and start server. 5) Shutdown server again. # rndc halt 6) Disable in-line signing for zone "inline.test." and start server. 7) Do more dynamic updates: # nsupdate << EOF update del a.inline.test. 3600 IN A 10.0.0.1 send update add a.inline.test. 3600 IN A 10.0.0.2 send EOF 8) Shutdown server once again. # rndc halt 9) Enable in-line signing for zone "inline.test." and start server. 10) See what happened: dig a.inline.test ;; ANSWER SECTION: a.inline.test. 3600 IN A 10.0.0.1 a.inline.test. 3600 IN A 10.0.0.2 Problem analysis ================ IMHO the problem is that receive_secure_db() doesn't record source serial to secure zone's journal. Consequently, receive_secure_serial() re-reads more journal records than it should. As a result, dns_diff_appendminimal() calls in sync_secure_journal() coalesce changes which should not be coalesced. In the example above it means that sequence: update add a.inline.test. 3600 IN A 10.0.0.1 update del a.inline.test. 3600 IN A 10.0.0.1 is deleted from to-be-applied diff. Is this analysis correct? Are you planning to fix it in 9.9 or 9.10? Thank you for answer! -- Petr Spacek @ Red Hat