Bug 577639 - bind Stopped Resolving (broken trust chain resolving)
bind Stopped Resolving (broken trust chain resolving)
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
12
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Adam Tkac
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-28 09:59 EDT by Richi Plana
Modified: 2013-04-30 19:46 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-09 09:23:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Al's main named config file (977 bytes, text/plain)
2010-04-20 20:12 EDT, Al Dunsmuir
no flags Details
Al's named config - included from /var/named/slaves/ (446 bytes, text/plain)
2010-04-20 20:15 EDT, Al Dunsmuir
no flags Details
Al's named config - included from /var/named/slaves/ (596 bytes, text/plain)
2010-04-20 20:16 EDT, Al Dunsmuir
no flags Details
dnssec debug output (11.60 KB, text/plain)
2010-04-21 05:34 EDT, Al Dunsmuir
no flags Details

  None (edit)
Description Richi Plana 2010-03-28 09:59:08 EDT
Description of problem:
After updating to bind-9.6.2-2.P1.fc12.x86_64 (from 32:bind-9.6.2-1.fc12.x86_64), bind stopped resolving hostnames. The only indication of a problem I could discern was in /var/log/messages:

Mar 28 03:13:58 legacy named[26790]: broken trust chain resolving 'api.facebook.com.dlv.isc.org/DLV/IN': 208.67.220.220#53
Mar 28 03:13:58 legacy named[26790]: broken trust chain resolving 'api.facebook.com/A/IN': 208.67.220.220#53
Mar 28 03:13:58 legacy named[26790]: validating @0x7fc01c0078e0: api.facebook.com A: bad cache hit (api.facebook.com.dlv.isc.org/DLV)
M

Version-Release number of selected component (if applicable):
32:bind-9.6.2-2.P1.fc12.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Upgrade to bind-9.6.2-2.P1.fc12.x86_64
2. nslookup <valid-domain-name> <bind-host-ip>
  
Actual results:
# nslookup   mozcom.com 192.168.1.254
Server:		192.168.1.254
Address:	192.168.1.254#53

** server can't find mozcom.com: NXDOMAIN


Expected results:
# nslookup   mozcom.com 
Server:		64.59.135.133
Address:	64.59.135.133#53

Non-authoritative answer:
Name:	mozcom.com
Address: 202.47.132.17


Additional info:
Comment 1 Richi Plana 2010-03-31 00:00:22 EDT
I determined that this is only happening when I use the forwarders option (which, in turn, points to my ISP's DNS servers). Now I can't be sure if the reason for it failing was because of the update to the new version of bind or if my ISP changed something in their configuration, but I first noticed this problem a few hours after I did the update of BIND.

So if I remove forwarders, BIND correctly resolves non-authoritative host names
Comment 2 Adam Tkac 2010-04-02 07:00:16 EDT
(In reply to comment #0)
> Description of problem:
> After updating to bind-9.6.2-2.P1.fc12.x86_64 (from
> 32:bind-9.6.2-1.fc12.x86_64), bind stopped resolving hostnames. The only
> indication of a problem I could discern was in /var/log/messages:

Interesting. Did 9.6.2-1.fc12 really work fine and 9.6.2-2.P1.fc12 is broken? I don't see any change in source code which might cause such problems.

About your forwarders issue. Would it be possible to check if your ISP's servers returns "correct" answers, please? Run "dig @<address_of_ISP_nameserver> dlv.isc.org SOA +dnssec" and attach output here.
Comment 3 Richi Plana 2010-04-03 09:52:16 EDT
I wanted to test with 9.6.2-1.fc12, but I don't know how to get the archived version. You're right in that it could have been coincidence. It's possible that something changed externally to my system at approximately the same time bind got updated.

Here's one more thing: my ISP gives me access to several of their DNS servers and I recently tried a second set and was able to forward DNS requests to it. This is the output of dig (from bind-utils-9.6.2-2.P1.fc12.x86_64) where 208.67.222.222 is the faulty server and 64.59.135.133 is the good one:

$ dig @208.67.222.222 dlv.isc.org SOA +dnssec

; <<>> DiG 9.6.2-P1-RedHat-9.6.2-2.P1.fc12 <<>> @208.67.222.222 dlv.isc.org SOA +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22171
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;dlv.isc.org.			IN	SOA

;; ANSWER SECTION:
dlv.isc.org.		3600	IN	SOA	ns-int.isc.org. hostmaster.isc.org. 2010040200 7200 3600 2419200 3600

;; Query time: 261 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Sat Apr  3 07:43:02 2010
;; MSG SIZE  rcvd: 94

$ dig @64.59.135.133 dlv.isc.org SOA +dnssec

; <<>> DiG 9.6.2-P1-RedHat-9.6.2-2.P1.fc12 <<>> @64.59.135.133 dlv.isc.org SOA +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55325
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;dlv.isc.org.			IN	SOA

;; ANSWER SECTION:
dlv.isc.org.		3429	IN	SOA	ns-int.isc.org. hostmaster.isc.org. 2010040200 7200 3600 2419200 3600

;; Query time: 9 msec
;; SERVER: 64.59.135.133#53(64.59.135.133)
;; WHEN: Sat Apr  3 07:51:08 2010
;; MSG SIZE  rcvd: 83
Comment 4 Freddy Willemsen 2010-04-09 03:02:07 EDT
I can confirm that bind-9.6.2-3.P1.fc12 has a problem when forwarders are used. I downloaded and installed bind-9.6.2-1.fc12 from http://koji.fedoraproject.org, that version works WITH forwarders.
Comment 5 Al Dunsmuir 2010-04-17 15:40:06 EDT
Same error occurs on both:
bind.i686    9.7.0-9.P1.fc13
bind.x86_64  9.6.2-3.P1.fc12

ISP is sympatico.ca - DNS server 207.164.234.193
- Only supports IP V4, so am using /etc/sysconfig/named OPTIONS="-4"
Comment 6 Al Dunsmuir 2010-04-18 15:13:42 EDT
A bit of inconsistency, on removal of the forward and forwarders stanzas.

The x86_64 system (f12) now resolves host names reliably and securely.

The 386 system (f13 Beta + all updates) still fails to resolve any queries.
The attached is the named syslog output for that system:

Apr 18 14:59:24 wallace named[3741]: starting BIND 9.7.0-P1-RedHat-9.7.0-9.P1.fc13 -u named -4
Apr 18 14:59:24 wallace named[3741]: built with '--build=i386-redhat-linux-gnu' '--host=i386-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--with-pic' '--disable-static' '--disable-openssl-version-check' '--with-pkcs11=/usr/lib/pkcs11/PKCS11_API.so' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' 'build_alias=i386-redhat-linux-gnu' 'host_alias=i386-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables' 'CPPFLAGS= -DDIG_SIGCHASE'
Apr 18 14:59:24 wallace named[3741]: adjusted limit on open files from 1024 to 1048576
Apr 18 14:59:24 wallace named[3741]: found 2 CPUs, using 2 worker threads
Apr 18 14:59:24 wallace named[3741]: using up to 4096 sockets
Apr 18 14:59:24 wallace named[3741]: loading configuration from '/etc/named.conf'
Apr 18 14:59:24 wallace named[3741]: using default UDP/IPv4 port range: [1024, 65535]
Apr 18 14:59:24 wallace named[3741]: using default UDP/IPv6 port range: [1024, 65535]
Apr 18 14:59:24 wallace named[3741]: no IPv6 interfaces found
Apr 18 14:59:24 wallace named[3741]: listening on IPv4 interface lo, 127.0.0.1#53
Apr 18 14:59:24 wallace named[3741]: listening on IPv4 interface eth0, 192.168.1.2#53
Apr 18 14:59:24 wallace named[3741]: generating session key for dynamic DNS
Apr 18 14:59:24 wallace named[3741]: automatic empty zone: 127.IN-ADDR.ARPA
Apr 18 14:59:24 wallace named[3741]: automatic empty zone: 254.169.IN-ADDR.ARPA
Apr 18 14:59:24 wallace named[3741]: automatic empty zone: 2.0.192.IN-ADDR.ARPA
Apr 18 14:59:24 wallace named[3741]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA
Apr 18 14:59:24 wallace named[3741]: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
Apr 18 14:59:24 wallace named[3741]: automatic empty zone: D.F.IP6.ARPA
Apr 18 14:59:24 wallace named[3741]: automatic empty zone: 8.E.F.IP6.ARPA
Apr 18 14:59:24 wallace named[3741]: automatic empty zone: 9.E.F.IP6.ARPA
Apr 18 14:59:24 wallace named[3741]: automatic empty zone: A.E.F.IP6.ARPA
Apr 18 14:59:24 wallace named[3741]: automatic empty zone: B.E.F.IP6.ARPA
Apr 18 14:59:24 wallace named[3741]: command channel listening on 127.0.0.1#953
Apr 18 14:59:24 wallace named[3741]: the working directory is not writable
Apr 18 14:59:24 wallace named[3741]: zone 0.in-addr.arpa/IN: loaded serial 0
Apr 18 14:59:24 wallace named[3741]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
Apr 18 14:59:24 wallace named[3741]: zone 1.168.192.IN-ADDR.ARPA/IN: loaded serial 2
Apr 18 14:59:24 wallace named[3741]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0
Apr 18 14:59:24 wallace named[3741]: zone fernbank.whitby.ca/IN: loaded serial 2
Apr 18 14:59:24 wallace named[3741]: zone localhost.localdomain/IN: loaded serial 0
Apr 18 14:59:24 wallace named[3741]: zone localhost/IN: loaded serial 0
Apr 18 14:59:24 wallace named[3741]: running
Apr 18 14:59:36 wallace named[3741]: validating @0xb4735bf8: dlv.isc.org DNSKEY: must be secure failure,  . is under DLV (startfinddlvsep)
Apr 18 14:59:36 wallace named[3741]: error (must-be-secure) resolving 'dlv.isc.org/DNSKEY/IN': 149.20.64.4#53
Apr 18 14:59:37 wallace named[3741]: validating @0xb4509650: dlv.isc.org DNSKEY: must be secure failure,  . is under DLV (startfinddlvsep)
Apr 18 14:59:37 wallace named[3741]: error (must-be-secure) resolving 'dlv.isc.org/DNSKEY/IN': 199.6.1.29#53
Apr 18 14:59:37 wallace named[3741]: validating @0xb4509650: dlv.isc.org DNSKEY: must be secure failure,  . is under DLV (startfinddlvsep)
Apr 18 14:59:37 wallace named[3741]: error (must-be-secure) resolving 'dlv.isc.org/DNSKEY/IN': 199.6.0.29#53
Apr 18 14:59:37 wallace named[3741]: validating @0xb4509650: dlv.isc.org DNSKEY: must be secure failure,  . is under DLV (startfinddlvsep)
Apr 18 14:59:37 wallace named[3741]: error (must-be-secure) resolving 'dlv.isc.org/DNSKEY/IN': 156.154.100.23#53
Apr 18 14:59:37 wallace named[3741]: validating @0xb4509650: dlv.isc.org DNSKEY: must be secure failure,  . is under DLV (startfinddlvsep)
Apr 18 14:59:37 wallace named[3741]: error (must-be-secure) resolving 'dlv.isc.org/DNSKEY/IN': 156.154.101.23#53
Apr 18 14:59:37 wallace named[3741]: validating @0xb4509650: dlv.isc.org DNSKEY: must be secure failure,  . is under DLV (startfinddlvsep)
Apr 18 14:59:37 wallace named[3741]: error (must-be-secure) resolving 'dlv.isc.org/DNSKEY/IN': 199.254.63.254#53
Apr 18 14:59:37 wallace named[3741]:   validating @0xb4510688: fa-mi.org.dlv.isc.org NSEC: bad cache hit (dlv.isc.org/DNSKEY)
Apr 18 14:59:37 wallace named[3741]:   validating @0xb4510688: org.dlv.isc.org NSEC: bad cache hit (dlv.isc.org/DNSKEY)
Apr 18 14:59:37 wallace named[3741]:   validating @0xb450c668: dlv.isc.org NSEC: bad cache hit (dlv.isc.org/DNSKEY)
Apr 18 14:59:37 wallace named[3741]: error (broken trust chain) resolving 'dlv.isc.org/DLV/IN': 199.6.0.29#53
Apr 18 14:59:37 wallace named[3741]: error (broken trust chain) resolving 'www.fedora.org.dlv.isc.org/DLV/IN': 199.6.1.29#53
Apr 18 14:59:37 wallace named[3741]: error (broken trust chain) resolving 'www.fedora.org/A/IN': 67.40.49.163#53
Apr 18 14:59:37 wallace named[3741]: error (broken trust chain) resolving './NS/IN': 128.63.2.53#53
Apr 18 15:07:39 wallace named[3741]:   validating @0xb4514118: dlv.isc.org SOA: bad cache hit (dlv.isc.org/DNSKEY)
Apr 18 15:07:39 wallace named[3741]:   validating @0xb4514118: gov.dlv.isc.org NSEC: bad cache hit (dlv.isc.org/DNSKEY)
Apr 18 15:07:39 wallace named[3741]: error (broken trust chain) resolving 'noaa.gov.dlv.isc.org/DLV/IN': 199.6.0.29#53
Apr 18 15:07:39 wallace named[3741]: error (broken trust chain) resolving 'weather.noaa.gov/AAAA/IN': 140.90.33.240#53
Apr 18 15:07:39 wallace named[3741]:   validating @0xb4511100: dlv.isc.org SOA: bad cache hit (dlv.isc.org/DNSKEY)
Apr 18 15:07:39 wallace named[3741]:   validating @0xb4511100: gov.dlv.isc.org NSEC: bad cache hit (dlv.isc.org/DNSKEY)
Apr 18 15:07:39 wallace named[3741]: error (broken trust chain) resolving 'weather.noaa.gov.dlv.isc.org/DLV/IN': 156.154.101.23#53
Apr 18 15:07:39 wallace named[3741]: error (broken trust chain) resolving 'weather.noaa.gov/A/IN': 140.172.17.240#53
Comment 7 Adam Tkac 2010-04-20 09:27:42 EDT
(In reply to comment #3)
> $ dig @208.67.222.222 dlv.isc.org SOA +dnssec
> 
> ; <<>> DiG 9.6.2-P1-RedHat-9.6.2-2.P1.fc12 <<>> @208.67.222.222 dlv.isc.org SOA
> +dnssec
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22171
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;dlv.isc.org.   IN SOA
> 
> ;; ANSWER SECTION:
> dlv.isc.org.  3600 IN SOA ns-int.isc.org. hostmaster.isc.org. 2010040200 7200
> 3600 2419200 3600
> 
> ;; Query time: 261 msec
> ;; SERVER: 208.67.222.222#53(208.67.222.222)
> ;; WHEN: Sat Apr  3 07:43:02 2010
> ;; MSG SIZE  rcvd: 94
> 
> $ dig @64.59.135.133 dlv.isc.org SOA +dnssec

Are you sure that output written below is really with the +dnssec flag? In my opinion you copied & paste output without +dnssec because question contains no "OPT pseudosection".

> ; <<>> DiG 9.6.2-P1-RedHat-9.6.2-2.P1.fc12 <<>> @64.59.135.133 dlv.isc.org SOA
> +dnssec
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55325
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;dlv.isc.org.   IN SOA
> 
> ;; ANSWER SECTION:
> dlv.isc.org.  3429 IN SOA ns-int.isc.org. hostmaster.isc.org. 2010040200 7200
> 3600 2419200 3600
> 
> ;; Query time: 9 msec
> ;; SERVER: 64.59.135.133#53(64.59.135.133)
> ;; WHEN: Sat Apr  3 07:51:08 2010
> ;; MSG SIZE  rcvd: 83
Comment 8 Adam Tkac 2010-04-20 09:33:23 EDT
(In reply to comment #6)
> A bit of inconsistency, on removal of the forward and forwarders stanzas.
> 
> The x86_64 system (f12) now resolves host names reliably and securely.
> 
> The 386 system (f13 Beta + all updates) still fails to resolve any queries.
> The attached is the named syslog output for that system:

It's odd. Would it be possible to attach your named.conf, please? Make sure you attach it as a "private" attachment if it contains any security related information.

Additionally, it would be nice to get more information about DNSSEC validation, please add following to your named.conf:

logging {
        channel debug_channel {
                file "/var/named/data/named.dnssec" versions 1 size 2M;
                severity debug 99;
        };
        category dnssec { debug_channel; };
};

And when your named fails to resolve a query due DNSSEC failure then attach /var/named/data/named.dnssec as well, please.

Thank you in advance.
Comment 9 Al Dunsmuir 2010-04-20 20:12:26 EDT
Created attachment 407953 [details]
Al's main named config file
Comment 10 Al Dunsmuir 2010-04-20 20:15:53 EDT
Created attachment 407954 [details]
Al's named config - included from /var/named/slaves/
Comment 11 Al Dunsmuir 2010-04-20 20:16:19 EDT
Created attachment 407955 [details]
Al's named config - included from /var/named/slaves/
Comment 12 Al Dunsmuir 2010-04-20 20:18:13 EDT
Adam - didn't get EMails for your updates to this bug.  Have to run... attached named config and included files - nothing earth shattering.  Will add the DNSSEC debug stanza on Thursday and attach results.
Comment 13 Al Dunsmuir 2010-04-20 20:19:46 EDT
OK... somehow I was on excluded list with you and Paul.  Added myself explicitly.  Something else for me to look into.
Comment 14 Al Dunsmuir 2010-04-21 05:34:05 EDT
Created attachment 408030 [details]
dnssec debug output

Debug output for FireFox query of http://start.fedora.project.org via 127.0.0.1 attached.
Comment 15 Frantisek Hanzlik 2010-04-21 06:55:28 EDT
I encounter this problem with bind-9.6.2-3.P1.fc12.i686.
What is suspicious, I have "dnssec-enable no;" in named.conf, but this seems not
sufficient - e.g. "dig @localhost -t MX mesto.vimperk.cz" return with
"return status: SERVFAIL" and messages contain:

Apr 21 12:39:32 agmsrv named[6614]: no valid RRSIG resolving 'vimperk.cz/DNSKEY/IN': 81.95.96.2#53
Apr 21 12:39:32 agmsrv named[6614]: no valid RRSIG resolving 'vimperk.cz/DNSKEY/IN': 81.0.238.27#53
Apr 21 12:39:32 agmsrv named[6614]: broken trust chain resolving 'mesto.vimperk.cz/MX/IN': 81.95.96.2#53

named stops use DNSSEC as late after explicitly specifying
"dnssec-validation no;" - it seems as "dnssec-enable no;" isn't enough.
Comment 16 Adam Tkac 2010-05-03 07:53:30 EDT
(In reply to comment #9)
> Created an attachment (id=407953) [details]
> Al's main named config file    

It seems you have your named misconfigured. You have "dnssec-lookaside . trust-anchor dlv.isc.org.;" line in your options {} statement but you don't have the dlv.isc.org. DNSKEY in your named.conf. Basically you told named "try to validate all domains via ISC DLV key" but you didn't specify the key. Thus named failed to validate all domains. You can check this with the /usr/bin/dig utility, for example:

$ dig @127.0.0.1 fedoraproject.org

; <<>> DiG 9.6.2-P1-RedHat-9.6.2-3.P1.fc12 <<>> @127.0.0.1 fedoraproject.org
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

It means "something is wrong". When you try to add "+cd" parameter (check +[no]cdflag in `man 1 dig`) then everything is OK. It means server is unable to perform DNSSEC validation.

If you use Fedora 12 then you can add following line to your named.conf:

include "/etc/pki/dnssec-keys/dlv/dlv.isc.org.conf";

If you use Fedora 13 then remove the "dnssec-lookaside ..." line and add this to your options {} section:

dnssec-lookaside auto;
bindkeys-file "/etc/named.iscdlv.key";

Does it help?
Comment 17 Adam Tkac 2010-05-03 07:57:59 EDT
(In reply to comment #15)
> I encounter this problem with bind-9.6.2-3.P1.fc12.i686.

Do you use forwarders and/or do you have your DLV configuration in your named.conf validm, as written in comment #16?

> What is suspicious, I have "dnssec-enable no;" in named.conf, but this seems
> not
> sufficient - e.g. "dig @localhost -t MX mesto.vimperk.cz" return with
> "return status: SERVFAIL" and messages contain:
> 
> Apr 21 12:39:32 agmsrv named[6614]: no valid RRSIG resolving
> 'vimperk.cz/DNSKEY/IN': 81.95.96.2#53
> Apr 21 12:39:32 agmsrv named[6614]: no valid RRSIG resolving
> 'vimperk.cz/DNSKEY/IN': 81.0.238.27#53
> Apr 21 12:39:32 agmsrv named[6614]: broken trust chain resolving
> 'mesto.vimperk.cz/MX/IN': 81.95.96.2#53
> 
> named stops use DNSSEC as late after explicitly specifying
> "dnssec-validation no;" - it seems as "dnssec-enable no;" isn't enough.    

Right you are. Let me check if this is a correct behavior and documentation should be fixed or this is a bug in the named.
Comment 18 Al Dunsmuir 2010-05-04 16:48:22 EDT
(In reply to comment #16)
> It seems you have your named misconfigured. You have "dnssec-lookaside .
> ...
> If you use Fedora 13 then remove the "dnssec-lookaside ..." line and add this
> to your options {} section:
> 
> dnssec-lookaside auto;
> bindkeys-file "/etc/named.iscdlv.key";
> 
> Does it help?    

It does indeed - thanks Adam, for spotting the problem!

I suspect that I'm not the only soul out there that will be burned by the dnssec configuration changes from F12 to F13.  Would this be a good thing to add to the F13 FAQ?

Al
Comment 19 Adam Tkac 2010-05-06 07:34:44 EDT
(In reply to comment #18)
> (In reply to comment #16)
> > It seems you have your named misconfigured. You have "dnssec-lookaside .
> > ...
> > If you use Fedora 13 then remove the "dnssec-lookaside ..." line and add this
> > to your options {} section:
> > 
> > dnssec-lookaside auto;
> > bindkeys-file "/etc/named.iscdlv.key";
> > 
> > Does it help?    
> 
> It does indeed - thanks Adam, for spotting the problem!
> 
> I suspect that I'm not the only soul out there that will be burned by the
> dnssec configuration changes from F12 to F13.  Would this be a good thing to
> add to the F13 FAQ?

This issue should be no longer present with the latest bind packages.

I'm not sure how your named.conf got "corrupted" (dnssec-lookaside ... line was present but ISC key was missing) but such bug was present only in bind 9.7.0-0.14.rc2 and 9.7.0-1. So if you updated to that versions you might hit this problem. Current bind-9.7.0-9.P1.fc13 doesn't suffer from this problem.
Comment 20 Al Dunsmuir 2010-05-06 12:55:22 EDT
I started with the F13 beta, and have applied all updates.  
Current bind is bind-9.7.0-9.P1.fc13, so I'm good to go.

Will keep this system running with all updates through GA.
Planning to download new DVD images then for the other F12
upgrades (i686 and X86_64).

Thanks!
Al
Comment 21 Frantisek Hanzlik 2010-05-07 07:41:16 EDT
(In reply to comment #17)
Hello Adam, maybe my error reports was caused by something else, not by bind. When I gone through system logs, I find that:
- bind-9.6.2-3.P1.fc12.i686 was installed(updated) and run 19-Apr-2010 4:17 am.

- any series (cca 50) of error messages similar to this I sent above appear in log in 21-Apr-2010 6:51 am and took up to 12:50 (6 hours), until I switch both "dnssec-validation no;" & "dnssec-enable no;".

- but I more then two days ago set both these options to "yes" and bind seems working OK (with sporadic /~20/ entries in /var/log/messages as:
May  7 03:40:48 agmsrv named[2588]: broken trust chain resolving '39.224.204.41.in-addr.arpa/PTR/IN': 41.211.233.10#53
May  7 10:43:27 agmsrv named[2588]: no valid RRSIG resolving 'csadcbas.cz/A/IN': 81.0.238.27#53
),
but in contrast to time of my previous report (when any dig request ends allways with SERVFAIL), now all dig-ging are OK.

I do not know explain what might cause previous behavior (maybe DNS transparent caching somewhere in chain?). But without any other changes, this BIND version now seems worked fine.
Comment 22 Adam Tkac 2010-06-09 09:16:54 EDT
(In reply to comment #21)
> - any series (cca 50) of error messages similar to this I sent above appear in
> log in 21-Apr-2010 6:51 am and took up to 12:50 (6 hours), until I switch both
> "dnssec-validation no;" & "dnssec-enable no;".
> 
> - but I more then two days ago set both these options to "yes" and bind seems
> working OK (with sporadic /~20/ entries in /var/log/messages as:
> May  7 03:40:48 agmsrv named[2588]: broken trust chain resolving
> '39.224.204.41.in-addr.arpa/PTR/IN': 41.211.233.10#53
> May  7 10:43:27 agmsrv named[2588]: no valid RRSIG resolving
> 'csadcbas.cz/A/IN': 81.0.238.27#53
> ),
> but in contrast to time of my previous report (when any dig request ends
> allways with SERVFAIL), now all dig-ging are OK.
> 
> I do not know explain what might cause previous behavior (maybe DNS transparent
> caching somewhere in chain?). But without any other changes, this BIND version
> now seems worked fine.    

Some "clever" middleware and/or caching can cause such problems. Debugging is usually not easy, you must use "dig" and try to catch what exactly is broken.
Comment 23 Adam Tkac 2010-06-09 09:23:19 EDT
It seems nobody longer hits this problem. This issue was caused by misconfigured trust-anchors (comment #16) or by too old forwarders which don't include RRSIG records in responses (can be checked via `dig
@<address_of_ISP_nameserver> dlv.isc.org SOA +dnssec`).

Closing as NOTABUG.

Note You need to log in before you can comment on or make changes to this bug.