9.7.0-P1 managed-keys.bind issues
I'm trying to setup a new 9.7.0-P1 server in order to (initially) do
DNSSEC validation lookups.
I'm using the Fedora 13 SRPM, recompiled on CentOS 5.4. SELinux is Off
currently.
when I add the following to my options {} section, I get some log
messages I don't understand...
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
Apr 14 12:06:34 dns01 named[4911]: zone managed-keys.bind/IN/_meta: loading
from master file dynamic/managed-keys.bind failed: file not found
Apr 14 12:06:34 dns01 named[4911]: dynamic/managed-keys.bind.jnl: create: file
not found
Apr 14 12:06:34 dns01 named[4911]: zone managed-keys.bind/IN/_meta:
sync_keyzone:dns_journal_open - unexpected error
Apr 14 12:06:34 dns01 named[4911]: zone managed-keys.bind/IN/_meta: loaded
serial 0
Apr 14 12:06:35 dns01 named[4911]: zone managed-keys.bind/IN/_meta: Unable to
fetch DNSKEY set 'dlv.isc.org': failure
Apr 14 12:06:35 dns01 named[4911]: dynamic/managed-keys.bind.jnl: create: file
not found
Apr 14 12:06:35 dns01 named[4911]: zone managed-keys.bind/IN/_meta:
keyfetch_done:dns_journal_open - unexpected error
I can explain the Unable to fetch DNSKEY message; the server currently
has no direct Internet access.
What do the other messages mean, and how can I resolve them?
Mark.
--
Mark Watts BSc RHCE MBCS
Senior Systems Engineer, Managed Services Manpower
www.QinetiQ.com
QinetiQ - Delivering customer-focused solutions
GPG Key: http://www.linux-corner.info/mwatts.gpg
signature.asc
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: CNAME Issue - Whether to use CNAME-data or Response-Flag
At the top of this post I'd first like to thank Jonathan for a great reply (which for some reason never seemed to make it onto the usenet mirror of this group.) - exactly what I was hoping for. S. On 10 April 2010 4:26 AM, Jonathan de Boyne Pollard wrote What I am hoping is that somebody might be able to help point me in the direction of an RFC or specification document that might explain the PROPER response. JdBP It's RFC 2308 ยง2.1 http://tools.ietf.org./html/rfc2308#section-2.1 , and the proper interpretation of the JdBP responses that you are seeing from 81.187.81.32 and 81.187.30.41 is exactly as per JdBP the Type 1 example given in that section of the RFC: [...] JdBP Ignore all of the wittering about cache poisoning, by the way. It's nonsense. JdBP Bailiwick is entirely in the eye of the beholder, so content DNS servers are not required to tailor their responses to it. [...] Time for me to study the RFCs in detail I think ... JdBP The problem is why Microsoft's DNS server is getting this wrong. [...] JdBP The bad news is that you're not going to find this out from the BIND User's mailing list. But perhaps the BIND group will help describe what it should be doing right ... (And it seems that thanks to your post, I've found just the RFC) JdBP It is not where experts on Microsoft's DNS server generally hang out, JdBP as you've probably noticed if you've read any of the back messages before posting JdBP (as you should have http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/read-the-back-mes sages.html ). Oops - my mistake - Although I did read a FEW messages, I probable should have scanned through the archives a bit more before posting. JdBP Post to the microsoft.public.windows.server.dns newsgroup, and knowledgeable people there such as Ace Fekay and others will JdBP show you how to configure Microsoft's DNS server to log the details of its query resolution [...] I had originally tried the Microsoft Technet forums (e.g. http://social.technet.microsoft.com/Forums/en-GB/winserverNIS/thread/53f0798 2-01d4-4c62-b877-9f84f7095cb0) , and suppose that I could also have tried the Microsoft DNS-newgroup aswell.. However, by this time I had already raised a full support incident with Microsoft (after already having captured a number of logs, query-lookups, and network-traces, including those from BIND) so it seemed a bit redundant to post in a Microsoft newsgroup. JdBP By the way, this part of RFC 2308 is a sore point. A lot of content DNS servers get the RFC 1034 algorithm wrong when publishing alias chains, most notably djbdns [...] All good points. Steven. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 9.7.0-P1 managed-keys.bind issues
It would appear that these are all related. Allowing outbound DNS queries fixed these messages. Thanks for the report. If you didn't want to allow outbound DNS queries, then just turn off dnssec-lookaside. What it's doing is trying to refresh the DNSSEC key for dlv.isc.org, but if you weren't going to be supporting outbound queries anyway, there's no need for it to do this. -- 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
Re: Intermittent failures resolving .org domains in BIND 9.7.0 with DLV enabled
On Sun, Mar 28, 2010 at 11:48:37PM +0100, I wrote: A couple of weeks ago I upgraded my BINDs to 9.7.0 and enabled DLV. This is my first time attemting to validate DNSSEC; however, I've been seeing intermittent failures to resolve domains under .org which have been frequent enough to force me to disable DLV again (hence effectively disabling DNSSEC since I have no other trust anchors configured). Well, FWIW I upgraded to 9.7.0-P1 and tried enabling DLV again and I've seen no repeat of the DNSSEC name resolution issues so far; it's early days yet (only been running DLV for three days) but certainly looking promissing. -roy ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Intermittent failures resolving .org domains in BIND 9.7.0 with DLV enabled
Well, FWIW I upgraded to 9.7.0-P1 and tried enabling DLV again and I've seen no repeat of the DNSSEC name resolution issues so far; it's early days yet (only been running DLV for three days) but certainly looking promissing. I spoke too soon. I've now found a query that (at least this evening) is consistently failing for me, even if I restart BIND. The following query gives me SERVFAIL dig www.bbc.net.uk But the following two queries work: dig www.bbc.net.uk a dig www.bbc.net.uk +cd This is particularly odd, because there is absolutely no DNSSEC involved here. No domain above www.bbc.net.uk appears to be in the DLV registry, and BIND must be able to successfully verify the covering NSEC record that proves that in order to be willing to resolve the A query above. So I can't immediately see any way this situation could arise except due to a BIND bug. Anyone else have an IPv6-connected BIND 9.7.0-P1 host with DLV enabled they can try this query on? -roy ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Question about message your system is lacking dev/random (or equivalent)
In message 0808710b26e7e541ad135be9553cfb6896c1b3a...@hq-ec-02.ba.ad.ssa.gov, Khuu, Linh MicroTech writes: I just turned on the dnssec-validation today, and I saw lots of messages: 13-Apr-2010 15:17:17.122 dnssec: debug 3: validating @202be918: 3e77469i4= 8du24agcu5ftfumd6iocmrk.org NSEC3: verify rdataset (keyid=3D47948): You mus= t use the keyboard to create entropy, since your system is lacking /dev/random (or equivalent) This is like the linker stuffed up. You must ... (or equivalent) is not the textual description of a result code. It is a message that can be emitted by the command line tools used to generate keys. Named doesn't call this bit of code. If you are using shared libraries I would be checking that named is finding the right version of the shared library. 13-Apr-2010 15:26:35.016 dnssec: debug 3: validating @202bd638: usps.gov DN= SKEY: verify rdataset (keyid=3D10539): You must use the keyboard to create = entropy, since your system is lacking /dev/random (or equivalent) 13-Apr-2010 15:26:37.385 dnssec: debug 3: validating @202c0e28: usps.gov = SOA: verify rdataset (keyid=3D43133): You must use the keyboard to create e= ntropy, since your system is lacking /dev/random (or equivalent) Is this a problem with dnssec on my DNS server? Linh Khuu Network Security Specialist MicroTech ESS Contract Office: 410-966-0798 Pager: 410-232-2350 Email: linh.k...@ssa.gov =20 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Intermittent failures resolving .org domains in BIND 9.7.0 with DLV enabled
dig www.bbc.net.uk +cd How does the last query work? What I meant by that, in case it wasn't clear, was that setting the CD flag in the query caused it query to succeed, hence strongly suggesting that the cause of the failure in the original query was related to DNSSEC validation. I'm sure my BIND would have logged something as useful as your BIND did if I had set up logging correctly, but I'm afraid I've always found BIND 9 logging configuration to be rather inscrutible... Thanks for the response, in any case. The oddities you've identified may well be the reason why this is consistently failing, but I've seen superficially similar (though intermittent) failures to resolve domains under freebsd.org and isc.org under 9.7.0 (which was my original post) so I think the underlying bug can manifest even for conformant nameservers. I've received a private mail from someone at ISC asking me to try a suggested patch so there's probably little point in investigating further until I've had to opportunity to see what effect that has. And just for comleteness (although I don't think there would be any real doubt about this), I've now commened out again from my config the line dnssec-lookaside auto; and the query mentioned now resolves correctly. -roy ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Intermittent failures resolving .org domains in BIND 9.7.0 with DLV enabled
In message 20100414232855.gp1...@giles.gnomon.org.uk, Roy Badami writes: Well, FWIW I upgraded to 9.7.0-P1 and tried enabling DLV again and I've seen no repeat of the DNSSEC name resolution issues so far; it's early days yet (only been running DLV for three days) but certainly looking promissing. I spoke too soon. I've now found a query that (at least this evening) is consistently failing for me, even if I restart BIND. The following query gives me SERVFAIL dig www.bbc.net.uk But the following two queries work: dig www.bbc.net.uk a dig www.bbc.net.uk +cd This is particularly odd, because there is absolutely no DNSSEC involved here. Actually there *is* DNSSEC involved or the query would not have failed. There is a bug in the BIND 9.7.0-P1 fixes that triggers this. The fix below is in review at the moment. Mark Index: bind9/lib/dns/validator.c diff -u bind9/lib/dns/validator.c:1.188 bind9/lib/dns/validator.c:1.188.4.4 --- bind9/lib/dns/validator.c:1.188 Fri Mar 26 17:12:48 2010 +++ bind9/lib/dns/validator.c Tue Apr 13 08:31:11 2010 @@ -2990,7 +2990,7 @@ return (ISC_R_SUCCESS); } - if (val-authcount == val-authfail) + if (val-authfail != 0 val-authcount == val-authfail) return (DNS_R_BROKENCHAIN); validator_log(val, ISC_LOG_DEBUG(3), nonexistence proof(s) not found); /*% No domain above www.bbc.net.uk appears to be in the DLV registry, and BIND must be able to successfully verify the covering NSEC record that proves that in order to be willing to resolve the A query above. So I can't immediately see any way this situation could arise except due to a BIND bug. Anyone else have an IPv6-connected BIND 9.7.0-P1 host with DLV enabled they can try this query on? -roy ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
