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:
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
(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.
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
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.
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"
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
(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
(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.
Created attachment 407953 [details] Al's main named config file
Created attachment 407954 [details] Al's named config - included from /var/named/slaves/
Created attachment 407955 [details] Al's named config - included from /var/named/slaves/
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.
OK... somehow I was on excluded list with you and Paul. Added myself explicitly. Something else for me to look into.
Created attachment 408030 [details] dnssec debug output Debug output for FireFox query of http://start.fedora.project.org via 127.0.0.1 attached.
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.
(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?
(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.
(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
(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.
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
(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.
(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.
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.