Re: DNSSEC Bogus NXDOMAIN survives authenticating RR
On 2009-12-10 08:49, Niobos wrote: 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 This has been confirmed as a security-bug by ISC a while back. Due to the potential exploit, they asked me not to release this information until the fix was released. BIND 9.6.1-P3 now contains the fix: 827. [security] Bogus NXDOMAIN could be cached as if valid. [RT #20712] I can confirm that this version behaves as expected: keeps returning SERVFAIL on bogus NXDOMAIN response. Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC Bogus NXDOMAIN survives authenticating RR
Could you try this lookup? dig +dnssec removed.dnssec.dest-unreach.be I see now what you mean. Even though I have added your DNSKEY as trusted key, I get SERVFAIL on the first query and NXDOMAIN on the second, without BIND doing any additional outgoing queries. This is the same behavior I'm observing. One of your name servers returns unsigned NXDOMAIN responses with a higher serial number than the master server: I didn't configure the zone by the book; I corrected that now, but the results remain the same. serv02.imset.org returns a signed NXDOMAIN response with serial 2009081781. That corresponds to BIND's error message: | error (insecurity proof failed) resolving 'removed.dnssec.dest-unreach.be/A/IN': 213.251.188.140#53 The response is indeed signed, but the signature should *fail* validation, since there is no covering NSEC3 for the looked-up record. Do I understand the error correctly like this: BIND failed to prove the domain to be insecure, hence, the NXDOMAIN response should have a correct signature, hence, the response it got is bogus? Could the problem be that the authenticating RR somehow considers this domain to be insecure when looking up removed? That might well be the case, although I would expect BIND not to return unsigned queries for names below a manually configured trust anchor. I removed DLV-validation and manually added your KSK DNSKEY as a SEP, without change in behavior: removed.fnord.dnstest.hauke-lampe.de keeps returning SERVFAIL (as it should). It seems that my resolver is configured identical for both my and your domain; so it's possibly some difference in the served zone that causes this behaviour. What did you change for the removed record? Did you remove only the A and RRSIG? Or also the corresponding NSEC3? In attachement my full (signed) zone-file. It's a test-zone anyway, so I don't think this is a security issue. dnssec.dest-unreach.be.zone.signed Description: Binary data Maybe others have an idea what's happening here and why BIND returns NXDOMAIN responses. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC Bogus NXDOMAIN survives authenticating RR
[I finally gave up on trying to get Thunderbird *not* to wrap long lines. Prefixing them with seems to be the only way, even if confusing] Niobos wrote: dig +dnssec removed.dnssec.dest-unreach.be Even though I have added your DNSKEY as trusted key, I get SERVFAIL on the first query and NXDOMAIN on the second, without BIND doing any additional outgoing queries. This is the same behavior I'm observing. I think I see it clearer now. The inner workings of the NSEC/3 mechanisms are a bit of a mystery to me, so the following is mostly based on guesswork. Maybe I broke my test zone in a different way and that's why we don't see the same results. Your SOA record validates, mine doesn't: validating @0xb91c7968: fnord.dnstest.hauke-lampe.de SOA: no valid signature found And there lies the problem. 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 Do I understand the error correctly like this: BIND failed to prove the domain to be insecure, hence, the NXDOMAIN response should have a correct signature, hence, the response it got is bogus? Yes, domains below a trust anchor (configured manually or through DLV) must either be signed or proven to be insecure at the delegation point. What did you change for the removed record? Did you remove only the A and RRSIG? Or also the corresponding NSEC3? I removed A and RRSIG only. Here's what I did, using 9.7 defaults and smart-signing feature: dnssec-keygen -r /dev/urandom -3 -f ksk $zone; dnssec-keygen -r /dev/urandom -3 $zone; dnssec-signzone -x -S -3 - -o $zone db.test (/dev/urandom because it's faster and this was only a test zone) Then I edited db.test.signed, changed the changed record and removed removed and its RRSIG. Why we see different kinds of failures, I don't know. It's probably got to do with some of the signey-wimey DNSSEC voodoo stuff I hope I never have to understand in all its details. Hauke. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC Bogus NXDOMAIN survives authenticating RR
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). dig +dnssec changed.fnord.dnstest.hauke-lampe.de should return SERVFAIL and log error (no valid RRSIG) for the A record. 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). Hauke. signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC Bogus NXDOMAIN survives authenticating RR
Niobos wrote: 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) That is weird. I haven't seen that before and have no good explanation at hand. Could you try this lookup? dig +dnssec removed.dnssec.dest-unreach.be I see now what you mean. Even though I have added your DNSKEY as trusted key, I get SERVFAIL on the first query and NXDOMAIN on the second, without BIND doing any additional outgoing queries. One of your name servers returns unsigned NXDOMAIN responses with a higher serial number than the master server: | $ dig +dnssec removed.dnssec.dest-unreach.be @sdns1.ovh.net. | | ;; Got answer: | ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 32510 | ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 | ;; WARNING: recursion requested but not available | | ;; OPT PSEUDOSECTION: | ; EDNS: version: 0, flags: do; udp: 4096 | ;; QUESTION SECTION: | ;removed.dnssec.dest-unreach.be. IN A | | ;; AUTHORITY SECTION: | dest-unreach.be. 3600IN SOA serv02.imset.org. hostmaster.dest-unreach.be. 2009111619 3600 3600 604800 3600 serv02.imset.org returns a signed NXDOMAIN response with serial 2009081781. That corresponds to BIND's error message: | error (insecurity proof failed) resolving 'removed.dnssec.dest-unreach.be/A/IN': 213.251.188.140#53 Could the problem be that the authenticating RR somehow considers this domain to be insecure when looking up removed? That might well be the case, although I would expect BIND not to return unsigned queries for names below a manually configured trust anchor. Maybe others have an idea what's happening here and why BIND returns NXDOMAIN responses. Hauke. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNSSEC Bogus NXDOMAIN survives authenticating RR
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) dnssec.log Description: Binary data 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. 3599IN 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
