DNSSEC Bogus NXDOMAIN survives authenticating RR

[Niobos]

On 08 Dec 2009, at 15:18, Hauke Lampe wrote:
> Niobos wrote:
> 
>> 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.
> 
> I cannot reproduce this behaviour with BIND 9.7.0b3. I get a SERVFAIL
> for all lookups to changed/removed records.
> 
> Maybe you can try these with 9.6.1-P1:
> 
> dig +dnssec normal.fnord.dnstest.hauke-lampe.de
> should return 127.0.0.1 and the AD flag (if you use DLV with either
> dlv.isc.org or dnssec.iks-jena.de).
Correct

> dig +dnssec changed.fnord.dnstest.hauke-lampe.de
> should return SERVFAIL and log "error (no valid RRSIG)" for the A record.
Correct (I didn't check the log, but the end result is correct)

> dig +dnssec removed.fnord.dnstest.hauke-lampe.de
> should return SERVFAIL and log validation failures for the SOA as well
> as the A record (because removing the record disrupted the NSEC3 chain).
Correct (didn't check the log), and it keeps SERVFAIL-ing on subsequent tries as well.

While trying this, I noticed something that might give some info to where the problem is located:
As soon as I activate DLV (besides the manual SEP I entered), the "removed" behaviour changes:
* First lookup still returns SERVFAIL
* Subsequent lookups now return NXDOMAIN with the AD flag *set*! (log confirms that my domain is not in the DLV and hence is insecure)

Could you try this lookup?
dig +dnssec removed.dnssec.dest-unreach.be

My keys are not (yet) in any DLV database, so you'll just have to assume my DNSKEYs are correct.

Could the problem be that the authenticating RR somehow considers this domain to be insecure when looking up "removed"?

Thanks,

Niobos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20091208/1cddf0de/attachment.html>