DNSSEC Bogus NXDOMAIN survives authenticating RR

Niobos niobos at dest-unreach.be
Thu Dec 10 07:49:37 UTC 2009


Thank you very much for your help; I'll forward the conversation to the bug-tracking list.

Since these are my first DNSSEC experiments, I just wanted to make sure that it wasn't a problem with my understanding of the concept.

Niobos

On 10 Dec 2009, at 00:59, Hauke Lampe wrote:
> The signatures on your SOA and NSEC3 records in the NXDOMAIN response
> are all valid. It's their meaning, the proof of nonexistence for the
> removed record, that cannot be established:
> 
>> validating @0xb4e01470: removed.dnssec.dest-unreach.be A: attempting negative response validation
>>  validating @0xb4e01ee0: dnssec.dest-unreach.be SOA: verify rdataset (keyid=33827): success
>>  validating @0xb8e98b60: 67152CME7SOELFT0OOTFB03FQ968LOM1.dnssec.dest-unreach.be NSEC3: verify rdataset (keyid=33827): success
>>  validating @0xb8e98b60: OKIU30OTQ4ETK8K4VP0L3MM20HUNI5R2.dnssec.dest-unreach.be NSEC3: verify rdataset (keyid=33827): success
>> validating @0xb4e01470: removed.dnssec.dest-unreach.be A: NSEC3 proves name exists (owner) data=1
>> validating @0xb4e01470: removed.dnssec.dest-unreach.be A: nonexistence proof(s) not found
> 
> BIND seems to cache the validation state of the signatures, not the
> failed nonexistence proof. At least it doesn't re-validate cached answers:
> 
>> client 127.0.0.1#47401: UDP request
>> client 127.0.0.1#47401: using view '_default'
>> client 127.0.0.1#47401: request is not signed
>> client 127.0.0.1#47401: recursion available
>> client 127.0.0.1#47401: query
>> client 127.0.0.1#47401: query (cache) 'removed.dnssec.dest-unreach.be/A/IN' approved
>> client 127.0.0.1#47401: send
>> client 127.0.0.1#47401: sendto
>> client 127.0.0.1#47401: senddone
>> client 127.0.0.1#47401: next
>> client 127.0.0.1#47401: endrequest
> 
> So, while the first query returns SERVFAIL as expected, subsequent
> responses from the cache even have the AD flag set. This is the one
> thing that *really* puzzled me (otherwise I probably wouldn't have begun
> looking at long debug logs ;)
> 
>> hauke at pope:~$ dig +dnssec removed.dnssec.dest-unreach.be 
> [...]
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46781
>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
> 
> The response doesn't validate:
> 
>> hauke at pope:~$ dig +sigchase +trusted-key=./dnskey-dnssec.dest-unreach.be +dnssec removed.dnssec.dest-unreach.be 
> [...]
>> ;; Impossible to verify the Non-existence, the NSEC RRset can't be validated: FAILED
> 
> I think this is a bug in BIND's resolver part. You should forward a bug
> report to bind9-bugs at isc.org.
> 
> Unbound returns SERVFAIL to all queries for
> removed.dnssec.dest-unreach.be and keeps logging the failed NSEC3 test:
> 
>> unbound: [968:0] debug: Validating a nxdomain response
>> unbound: [968:0] debug: nsec3: keysize 1024 bits, max iterations 150
>> unbound: [968:0] info: start nsec3 nameerror proof, zone <dnssec.dest-unreach.be. TYPE0 CLASS0>
>> unbound: [968:0] info: ce candidate <removed.dnssec.dest-unreach.be. TYPE0 CLASS0>
>> unbound: [968:0] debug: nsec3 proveClosestEncloser: proved that qname existed, bad
>> unbound: [968:0] debug: nsec3 nameerror proof: failed to prove a closest encloser
>> unbound: [968:0] debug: NameError response failed nsec, nsec3 proof was sec_status_bogus
>> unbound: [968:0] info: validate(nxdomain): sec_status_bogus
> 




More information about the bind-users mailing list