Hi,
sorry for the rather longwinded email. In the interest of saving some
time, here is a short summary:
We get the error "message is bogus, non secure rrset" from Unbound in
some cases when resolving a wildcard CNAME record. The cause appears to
be an upstream BIND resolver that in some cases
On Wed, Mar 02, 2016 at 08:45:11 -0500, Casey Deccio wrote:
> On Wed, Mar 2, 2016 at 6:39 AM, Olav Morken via Unbound-users <
> unbound-users@unbound.net> wrote:
>
> > sorry for the rather longwinded email. In the interest of saving some
> > time, here is a short
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.
&
On Wed, Mar 02, 2016 at 16:58:38 +, Tony Finch wrote:
> Olav Morken via Unbound-users wrote:
> >
> > info: validate(cname): sec_status_secure
> > info: validate(positive): sec_status_secure
> > info: message is bogus, non secure rrset uninett.no. NS IN
> &
On Wed, Mar 02, 2016 at 16:42:01 +0100, Olav Morken wrote:
> On Wed, Mar 02, 2016 at 08:45:11 -0500, Casey Deccio wrote:
> > On Wed, Mar 2, 2016 at 6:39 AM, Olav Morken via Unbound-users <
> > unbound-users@unbound.net> wrote:
> >
> > > sorry for the rather
On Thu, Mar 03, 2016 at 08:58:02 +0100, Olav Morken wrote:
> On Wed, Mar 02, 2016 at 16:58:38 +, Tony Finch wrote:
> > Does Unbound use CD=1 when forwarding? If so, it should expect to receive
> > partially bogus answers and should handle them gracefully.
>
> I checked, and it does set the CD-
On Wed, Mar 02, 2016 at 21:14:56 +0100, W.C.A. Wijngaards via Unbound-users
wrote:
> However, I think it is not unreasonable to extend the compatibility
> code in Unbound for this. The error that Olav quotes is simply
> Unbound enforcing that 'all RRsets MUST validate' rule, telling you
> which o
On 2016-03-17 15:19, W.C.A. Wijngaards via Unbound-users wrote:
I fixed it so that Unbound uses CD=0 to send queries to a forwarder.
Unless a dnssec trust anchor exists above the qname, in which case CD=0
is only attempted on the first query.
Hi,
I did a quick test here, and can confirm that t