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

Hi, On 04/03/16 11:39, Havard Eidnes wrote: >>> Following the "not a bug" response from the BIND maintainers >>> yesterday evening, can you please point to chapter and verse >>> mandating this behaviour for non-authoritative recursive >>> resolvers? >> >> RFC4035 3.2.3 for validators, all

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

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

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

> But unbound is trying to set the AD flag in its reply. And thus it > needs all the RRsets to be secure. Thus, the reply from the forwarder > with CD flag becomes bogus. Yes, I know unbound is trying to validate the answer. However, insisting that a recursor return all pertinent data required

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

>> Following the "not a bug" response from the BIND maintainers >> yesterday evening, can you please point to chapter and verse >> mandating this behaviour for non-authoritative recursive >> resolvers? > > RFC4035 3.2.3 for validators, all RRsets in answer and authority > sections should be

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

It does seem that the CD bit is the key to this: RFC4035 3.2.2 talks about it (https://tools.ietf.org/html/rfc4035#section-3.2.2), mainly: The name server side of a security-aware recursive name server MUST pass the state of the CD bit to the resolver side along with the rest of an initiating

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

On Thu, Mar 3, 2016 at 6:43 AM, Tony Finch via Unbound-users < unbound-users@unbound.net> wrote: > Havard Eidnes wrote: > > > > > CD=1 is the wrong thing when querying a forwarder. When a > > > domain is partly broken, queries that work with CD=0 can be > > > forced to fail with

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

Havard Eidnes wrote: > > > CD=1 is the wrong thing when querying a forwarder. When a > > domain is partly broken, queries that work with CD=0 can be > > forced to fail with CD=1. > > Relly? I interpreted the use of CD=1 as "I want to do my own > DNSSEC validation, and therefore

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

>> 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

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Havard, On 03/03/16 09:30, Havard Eidnes wrote: >>> A couple of responses to an 'a' query for this name follows >>> attached below. In both cases you'll see the Authority section >>> contains the NS RRSET but not the RRSIG covering the NS

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

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

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

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

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

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 longwinded email. In the interest of

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

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 > > > >

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

>> The "right" thing is to have RRSIGs for all elements of the >> answer and authority sections. This is mandated by >> RFC4034,4035. All the RRsets in the answer and authority >> section MUST validate to mark the response as valid. > > FYI, I've submitted a tentative bug report to the BIND

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

> The "right" thing is to have RRSIGs for all elements of the > answer and authority sections. This is mandated by > RFC4034,4035. All the RRsets in the answer and authority > section MUST validate to mark the response as valid. FYI, I've submitted a tentative bug report to the BIND maintainers

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Havard, On 02/03/16 20:20, Havard Eidnes 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

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

>> 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.

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

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 > > As far as I can tell, the problem here is caused by extra NS-records in

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

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

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

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.

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

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 summary: > > > > > Hi Olav, > >