MIME-Version: 1.0
content-type: text/plain; charset="utf-8"; format="flowed"
Message-ID: <538EF176.5050302@redhat.com>
Organization: Red Hat
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
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
Content-Transfer-Encoding: 7bit
From: Petr Spacek <pspacek@redhat.com>
Content-Length: 1642

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