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 ;) > >> ha...@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: > >> ha...@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-b...@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 > _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
