DNSSEC Bogus NXDOMAIN survives authenticating RR

[Niobos]

Hi all,

I'm having some problems with implementing DNSSEC with NSEC3. I'm fairly new to DNSSEC, so it is certainly possible that my understanding of the subject is causing me to miss something. Also, I'm not entirely sure this is the correct mailing list, more accurate pointers are welcome.

The setup contains two BIND nameservers, both version 9.6.1-P1 on a linux OS (ubuntu 9.10 and gentoo). One is configured as authorative name-server for a (test)zone; the other is configured to be an authenticating recursive resolver.

I created a zone with the following entries (besides the standard SOA and NS):
* normal A 127.0.0.1
* changed A 127.0.0.1
* removed A 127.0.0.1
I also have two DNSKEY records (one KSK and one ZSK).

After signing this zone with the keys, I intentionally modify the signed zonefile to simulate a MITM attack:
* I change the "changed" A record to point to 127.0.0.2
* I remove the "removed" A record, along with its RRSIG
I would expect DNSSEC to catch these changes and reject the bogus responses.

When requesting a lookup of "normal", I get a NOERROR and the AuthenticatedData flag is set, along with the requested data.
When requesting a lookup of "changed", I get a SERVFAIL. I'm not sure if this is the expected behaviour, but it seems logical.
When requesting a lookup of "removed", I get a SERVFAIL as well. However, every subsequent request for "removed" gets an NXDOMAIN. (dig outputs below)
Flushing the caches on the RR with "rndc flush" causes the first request to be a SERVFAIL again.

When I look at the debug output of the RR for channel dnssec, I see no additional entries after the initial request. Log in attachement (sorry for the wrong mime-type; if anyone knows how to convince Mail.app to de this decently, let me know)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dnssec.log
Type: application/octet-stream
Size: 14797 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20091207/79d786b2/attachment.obj>
-------------- next part --------------

According to my understanding, this is a bug, probably in the caching. Can anyone confirm this is actually a bug? Point me to the right config-parameter? Or explain to me why this _isn't_ a bug?

Niobos


$ dig +dnssec removed.dnssec.<omitted>

; <<>> DiG 9.6.0-APPLE-P2 <<>> +dnssec removed.dnssec.<omitted>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8658
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;removed.dnssec.<omitted>.	IN	A

;; Query time: 603 msec
;; SERVER: 10.<omitted>.1#53(10.<omitted>.1)
;; WHEN: Sun Dec  6 19:10:05 2009
;; MSG SIZE  rcvd: 59

$ dig +dnssec removed.dnssec.<omitted>

; <<>> DiG 9.6.0-APPLE-P2 <<>> +dnssec removed.dnssec.<omitted>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 65296
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;removed.dnssec.<omitted>.	IN	A

;; AUTHORITY SECTION:
<omitted>.	3599	IN	SOA	serv02.<omitted>. hostmaster.<omitted>. 2009111618 3600 3600 604800 3600

;; Query time: 946 msec
;; SERVER: 10.<omitted>.1#53(10.<omitted>.1)
;; WHEN: Sun Dec  6 19:10:07 2009
;; MSG SIZE  rcvd: 122