message is bogus, non secure rrset with Unbound as local caching resolver
olav.morken at uninett.no
Wed Mar 2 16:16:47 UTC 2016
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:
> 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.
More information about the Unbound-users