Maintained by: NLnet Labs

message is bogus, non secure rrset with Unbound as local caching resolver

Olav Morken
Wed Mar 2 17:16:47 CET 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:
> 
> 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