On Wed, Mar 02, 2016 at 10:47:13 -0500, Paul Wouters wrote: > On Wed, 2 Mar 2016, Olav Morken via Unbound-users wrote: > > >Unfortunately, the BIND server only tends to return responses where the > >authority-section has NS-records but no RRSIG-record during the night. > >I suspect it has something to do with traffic levels and what other > >systems are accessing it. It makes it all a bit hard to troubleshoot. > >The main source of information for troubleshooting has been a > >combination of PCAP-files and log files. > > Are you sure this is not the bind wildcard bug? Can you try to resolve > something like pwouters.fedorahosted.org. That's an expanded wildcard. > > If so, this is the same bug as: > > https://bugzilla.redhat.com/show_bug.cgi?id=824219 > > We have a test for this, but I don't this dnssec-trigger has included > this test yet.
I wasn't aware of that bug report, but after having looked at it now, I don't think it is the same issue. I have no problems resolving pwouters.fedorahosted.org, even if I limit Unbound to only using the BIND upstream server. Looking at the bug report, the Bind version here is more recent (9.9.8P2). I have also never never seen any problems with the NSEC3-record or its RRSIG-record. The error message mentioned in comment #4 is also different: info: validator: response has failed AUTHORITY rrset: fedorapeople.org. NS IN info: validate(positive): sec_status_bogus The error I get is: info: validate(cname): sec_status_secure info: validate(positive): sec_status_secure info: message is bogus, non secure rrset uninett.no. NS IN As far as I can tell, the problem here is caused by extra NS-records in the authority-section that do not include the RRSIG element for the NS-records, but I can't really say that for certain. Best regards, Olav Morken UNINETT