managed-keys.bind's directory problem
I'm using BIND 9.7.0b3 an DLV (dns-lookaside auto;). The named tried to write "managed-keys.bind" file into the named's working directory. The current BIND 9 requires the working directory is writable by named (From ARM). But I think the working directory should not be writable by named and some OSs' default configuration set the working directory not writable. It is usable to avoid named's unknown BUG which may break the working directory. For example, FreeBSD changes the working directory's owner/group/permission configured by /etc/mtree/BIND.chroot.dist and it sets the working directory not writable by named. I changed /etc/mtree/BIND.chroot.dist in my FreeBSD box, but I don't like this solution. I'm very happy if I can change the managed-keys.bind path. -- >From BIND 9.7.0b3 ARM: In the current implementation, the managed keys database is stored as a master-format zone file called managed-keys.bind. When the key database is changed, the zone is updated. As with any other dynamic zone, changes will be written into a journal file, managed-keys.bind.jnl. They are committed to the master file as soon as possible afterward; in the case of the managed key database, this will usually occur within 30 seconds. So, whenever named is using automatic key maintenace, those two files can be expected to exist in the working directory. (For this reason among others, the working directory should be always be writable by named.) If the dnssec-lookaside option is set to auto, named will automatically initialize a managed key for the zone dlv.isc.org. The key that is used to initialize the key maintenance process is built into named, and can be overridden from bindkeys-file. --- -- Kazunori Fujiwara, JPRS ___ 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 > > unbound: [968:0] info: ce candidate 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: Bonjour! I wish to compile 9.7.0b3
Thank you! Evan, I have not VisualStudio which is commercial. Do you think I can use an other compiler or do you think VisualStudio light is enough (Version 2008 seems available). Best 2009/12/9 Evan Hunt > > > This is my first mail on this list. I hope I am at the right place. I > have > > loaded BIND 9.7.0b3 under Windows. Now I would like to compile it. Could > > someone help me with what is exactly to be done (and if I should install > a > > special compiler). > > Thank you for your help! > > Instructions are included in the bind9 distribution, in the file > win32utils/win32-build.txt. I'm not entirely sure these instructions > are fully up-to-date, so if you have trouble, feel free to send a bug > report to bind9-b...@isc.org. > > The compiler we currently use for Windows builds is VisualStudio 2005. > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. > -- Joel Verdon ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bonjour! I wish to compile 9.7.0b3
> This is my first mail on this list. I hope I am at the right place. I have > loaded BIND 9.7.0b3 under Windows. Now I would like to compile it. Could > someone help me with what is exactly to be done (and if I should install a > special compiler). > Thank you for your help! Instructions are included in the bind9 distribution, in the file win32utils/win32-build.txt. I'm not entirely sure these instructions are fully up-to-date, so if you have trouble, feel free to send a bug report to bind9-b...@isc.org. The compiler we currently use for Windows builds is VisualStudio 2005. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Bonjour! I wish to compile 9.7.0b3
This is my first mail on this list. I hope I am at the right place. I have loaded BIND 9.7.0b3 under Windows. Now I would like to compile it. Could someone help me with what is exactly to be done (and if I should install a special compiler). Thank you for your help! -- Joel Verdon ___ 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
