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

[Olav Morken via Unbound-users]

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
> >
> > 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.
> 
> This sounds a lot like a problem we discussed last year. See
> https://unbound.net/pipermail/unbound-users/2015-February/003757.html

It look similar, in that it is caused by extra records, but as far as I 
know there shouldn't be any DLV involved here. The uninett.no-zone is 
properly delegated from the parent zone.

I also tested with the most recent version from subversion trunk, which 
includes the fix mentioned in that thread, but got the same result.

> 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-flag. The full dig command line to 
simulate the queries that Unbound sends appear to be:

  dig -4 +qr +noadflag +recurse +cdflag +bufsize=4096 +dnssec 
pingapi.paas.uninett.no @dns-resolver1.uninett.no

I.e. the packets have the RD, CD and DO flags set.

I grabbed the output from dig yesterday evening. If anyone is curious, I 
uploaded it here:

  https://gist.github.com/olavmrk/c62f099736dbc5ef514a

Best regards,
Olav Morken
UNINETT

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

[Havard Eidnes via Unbound-users]

>> 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
> based on my message and the one I'm replying to here, RT#41844.

And... They're not having it:

  This is not a bug.  Section 3.1.1 applies to authoritative nameservers
  not intermediate caching nameservers.  In this case you are seeing the
  referral which is unsigned being returned from the cache.

Regards,

- Håvard

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

[Havard Eidnes via Unbound-users]

> 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
based on my message and the one I'm replying to here, RT#41844.

Regards,

- Håvard

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

[W.C.A. Wijngaards via Unbound-users]

-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 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.
> 
> 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 RRSET, 
> something we're not quite sure is "right" (but have not yet found 
> the scripture on), and which Olav suspects is triggering Unbound to
> be unhappy about the response.

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.

That contradicts explicitly your idea to keep valid parts surrounded
by invalid parts.

I think it is a bug in BIND that it transmits the NS set without its
RRSIGs in the authority section (in a reply that is not a referral).

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 one failed.  The NS set is gratuitous though, in the answer,
hence perhaps compatibility is an option.  Not so, for, say, NSEC or
SOA RRs.

Best regards, Wouter

> 
>> If so, this is the same bug as:
>> 
>> https://bugzilla.redhat.com/show_bug.cgi?id=824219
> 
> You mean the ISC RT#21409 which is mentioned in there, or something
> else?  The recursor Olav's machine is forwarding to 
> (oliven.uninett.no) is running BIND 9.9.8-P2, and according to its
> CHANGES file, that bug was squashed in the run-up to 9.9.3b2:
> 
> 3444.   [bug]   The NOQNAME proof was not being returned
> from cached insecure responses. [RT #21409]
> 
> Or is "the bind wildcard bug" something else?  If so please provide
> more information.
> 
> Best regards,
> 
> - Håvard
> 
> 
> 
> : {12} ; dig pwouters.fedorahosted.org. a +dnssec
> 
> ; <<>> DiG 9.10.2-P4 <<>> pwouters.fedorahosted.org. a +dnssec ;;
> global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY,
> status: NOERROR, id: 11578 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4,
> AUTHORITY: 5, ADDITIONAL: 6
> 
> ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;;
> QUESTION SECTION: ;pwouters.fedorahosted.org. IN  A
> 
> ;; ANSWER SECTION: pwouters.fedorahosted.org. 60   IN  CNAME
> hosted03.fedoraproject.org. pwouters.fedorahosted.org. 60   IN
> RRSIG   CNAME 5 2 60 20160331192054 20160301192054 39900
> fedorahosted.org.
> P91FaEGxGv2Yrsdo5eDfhkpJD2zqkkoVkJr6dz9XYl0Y2TBG2FQ1OArv
> wUwu/bbi63LDVXsJqmg+AarvQ/xkB6f0C9Ro5/cnQFgQ0zjhi1/n/R7I
> vdXXYMU3xslNTe5s7U2YfCquHtKti8q6bM/ltxgtD03QJz8OxAIbpiyj 4VQ= 
> hosted03.fedoraproject.org. 267 IN  A   140.211.169.199 
> hosted03.fedoraproject.org. 267 IN  RRSIG   A 5 3 300
> 20160331192053 20160301192053 7725 fedoraproject.org.
> n/lc4F2WKfEnq9kTqjWuBH1YbCjSiFPT1NQuDF9x30BHliC8D6M+EZKC
> Lcx2JVdzi+Gb/DREkp/facfVGsslfGjKfkhl4AL0kDD638I7qhnR8TJp
> D9e+B26xRwORMEDTALc/8KkfPNiBF1rztu2dvVSXR/LsIZd/y/3hyudO Fwk=
> 
> ;; AUTHORITY SECTION: mtn.fedorahosted.org.   60  IN  NSEC
> sssd.fedorahosted.org. A SSHFP RRSIG NSEC mtn.fedorahosted.org.
> 60  IN  RRSIG   NSEC 5 3 86400 20160331192054
> 20160301192054 39900 fedorahosted.org.
> p8tlcTZI3cDVAqlk2pbpGHUmDm/tZJyE2PSQNRJsOGXKnVWdZOs9Xovf
> bvJbsnVpeun9S4BosZ6UytlnX7XPn+jVu4KYZ2DK8tdAhyNOJOyVjTnh
> QJtGgPRWnraHA/hKWYsTpkK3meW2/kZdHsSsJodYeQ4WOhsa681htoYp 3vY= 
> fedoraproject.org.  86367   IN  NS
> ns02.fedoraproject.org. fedoraproject.org.  86367   IN  NS
> ns05.fedoraproject.org. fedoraproject.org.  86367   IN  NS
> ns04.fedoraproject.org.
> 
> ;; ADDITIONAL SECTION: ns02.fedoraproject.org. 86314   IN  A
> 152.19.134.139 ns02.fedoraproject.org. 86314   IN  
> 2610:28:3090:3001:dead:beef:cafe:fed5 ns05.fedoraproject.org. 86314
> IN  A   85.236.55.10 ns05.fedoraproject.org. 86314   IN
> 2001:4178:2:1269:dead:beef:cafe:fed5 
> ns04.fedoraproject.org. 86314   IN  A   209.132.181.17
> 
> ;; Query time: 322 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN:
> Wed Mar 02 20:06:31 CET 2016 ;; MSG SIZE  rcvd: 844
> 
> : {13} ; rndc status version: 9.10.2-P4  ...
> 
> 
> : {14} ; dig @oliven.uninett.no. pwouters.fedorahosted.org. a
> +dnssec
> 
> ; <<>> DiG 9.10.2-P4 <<>> @oliven.uninett.no.
> 

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

[Havard Eidnes via Unbound-users]

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

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 RRSET,
something we're not quite sure is "right" (but have not yet found
the scripture on), and which Olav suspects is triggering Unbound
to be unhappy about the response.

> If so, this is the same bug as:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=824219

You mean the ISC RT#21409 which is mentioned in there, or
something else?  The recursor Olav's machine is forwarding to
(oliven.uninett.no) is running BIND 9.9.8-P2, and according to
its CHANGES file, that bug was squashed in the run-up to 9.9.3b2:

3444.   [bug]   The NOQNAME proof was not being returned from cached
insecure responses. [RT #21409]

Or is "the bind wildcard bug" something else?  If so please
provide more information.

Best regards,

- Håvard
: {12} ; dig pwouters.fedorahosted.org. a +dnssec

; <<>> DiG 9.10.2-P4 <<>> pwouters.fedorahosted.org. a +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11578
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 6

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;pwouters.fedorahosted.org. IN  A

;; ANSWER SECTION:
pwouters.fedorahosted.org. 60   IN  CNAME   hosted03.fedoraproject.org.
pwouters.fedorahosted.org. 60   IN  RRSIG   CNAME 5 2 60 20160331192054 
20160301192054 39900 fedorahosted.org. 
P91FaEGxGv2Yrsdo5eDfhkpJD2zqkkoVkJr6dz9XYl0Y2TBG2FQ1OArv 
wUwu/bbi63LDVXsJqmg+AarvQ/xkB6f0C9Ro5/cnQFgQ0zjhi1/n/R7I 
vdXXYMU3xslNTe5s7U2YfCquHtKti8q6bM/ltxgtD03QJz8OxAIbpiyj 4VQ=
hosted03.fedoraproject.org. 267 IN  A   140.211.169.199
hosted03.fedoraproject.org. 267 IN  RRSIG   A 5 3 300 20160331192053 
20160301192053 7725 fedoraproject.org. 
n/lc4F2WKfEnq9kTqjWuBH1YbCjSiFPT1NQuDF9x30BHliC8D6M+EZKC 
Lcx2JVdzi+Gb/DREkp/facfVGsslfGjKfkhl4AL0kDD638I7qhnR8TJp 
D9e+B26xRwORMEDTALc/8KkfPNiBF1rztu2dvVSXR/LsIZd/y/3hyudO Fwk=

;; AUTHORITY SECTION:
mtn.fedorahosted.org.   60  IN  NSECsssd.fedorahosted.org. A SSHFP 
RRSIG NSEC
mtn.fedorahosted.org.   60  IN  RRSIG   NSEC 5 3 86400 20160331192054 
20160301192054 39900 fedorahosted.org. 
p8tlcTZI3cDVAqlk2pbpGHUmDm/tZJyE2PSQNRJsOGXKnVWdZOs9Xovf 
bvJbsnVpeun9S4BosZ6UytlnX7XPn+jVu4KYZ2DK8tdAhyNOJOyVjTnh 
QJtGgPRWnraHA/hKWYsTpkK3meW2/kZdHsSsJodYeQ4WOhsa681htoYp 3vY=
fedoraproject.org.  86367   IN  NS  ns02.fedoraproject.org.
fedoraproject.org.  86367   IN  NS  ns05.fedoraproject.org.
fedoraproject.org.  86367   IN  NS  ns04.fedoraproject.org.

;; ADDITIONAL SECTION:
ns02.fedoraproject.org. 86314   IN  A   152.19.134.139
ns02.fedoraproject.org. 86314   IN  
2610:28:3090:3001:dead:beef:cafe:fed5
ns05.fedoraproject.org. 86314   IN  A   85.236.55.10
ns05.fedoraproject.org. 86314   IN  
2001:4178:2:1269:dead:beef:cafe:fed5
ns04.fedoraproject.org. 86314   IN  A   209.132.181.17

;; Query time: 322 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Mar 02 20:06:31 CET 2016
;; MSG SIZE  rcvd: 844

: {13} ; rndc status
version: 9.10.2-P4 
...


: {14} ; dig @oliven.uninett.no. pwouters.fedorahosted.org. a +dnssec

; <<>> DiG 9.10.2-P4 <<>> @oliven.uninett.no. pwouters.fedorahosted.org. a 
+dnssec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35941
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 6

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;pwouters.fedorahosted.org. IN  A

;; ANSWER SECTION:
pwouters.fedorahosted.org. 60   IN  CNAME   hosted03.fedoraproject.org.
pwouters.fedorahosted.org. 60   IN  RRSIG   CNAME 5 2 60 20160331192054 
20160301192054 39900 fedorahosted.org. 
P91FaEGxGv2Yrsdo5eDfhkpJD2zqkkoVkJr6dz9XYl0Y2TBG2FQ1OArv 
wUwu/bbi63LDVXsJqmg+AarvQ/xkB6f0C9Ro5/cnQFgQ0zjhi1/n/R7I 
vdXXYMU3xslNTe5s7U2YfCquHtKti8q6bM/ltxgtD03QJz8OxAIbpiyj 4VQ=
hosted03.fedoraproject.org. 300 IN  A   140.211.169.199
hosted03.fedoraproject.org. 300 IN  RRSIG   A 5 3 300 20160331192053 
20160301192053 7725 fedoraproject.org. 
n/lc4F2WKfEnq9kTqjWuBH1YbCjSiFPT1NQuDF9x30BHliC8D6M+EZKC 
Lcx2JVdzi+Gb/DREkp/facfVGsslfGjKfkhl4AL0kDD638I7qhnR8TJp 

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

[Tony Finch via Unbound-users]

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
> the authority-section that do not include the RRSIG element for the
> NS-records, but I can't really say that for certain.

This sounds a lot like a problem we discussed last year. See
https://unbound.net/pipermail/unbound-users/2015-February/003757.html

As I said back then, I think it's wrong to discard the entire response if
parts of it are bogus. Unbound should keep the valid parts because it
knows there is nothing wrong with them.

Does Unbound use CD=1 when forwarding? If so, it should expect to receive
partially bogus answers and should handle them gracefully.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Trafalgar: North 4 or 5. Slight or moderate, occasionally rough later in
north. Occasional rain. Good, occasionally moderate.

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

[Olav Morken via Unbound-users]

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

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

[Paul Wouters via Unbound-users]

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.

Paul

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

[Olav Morken via Unbound-users]

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,
> 
> Would mind trying the DNSViz command-line tool [1] against the resolvers to
> see if anything shows up?  After install, run:
> 
> dnsviz probe -s x.x.x.x pingapi.paas.uninett.no | dnsviz grok -plwarning
> dnsviz probe -s x.x.x.x pingapi.paas.uninett.no | dnsviz graph -Thtml -O
> 
> (substitute x.x.x.x for the BIND and unbound resolvers, in turn)
> 
> I'm curious if anything shows up there.

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.

I have grabbed a capture from the Unbound resolver that I have attached 
to this email. If I ever happen to catch the BIND resolver having this 
behavior, I'll try to catch the output from it as well, but I won't 
make any promises.

The output of `dnsviz -grok -plwarning` only contains:

> Analyzing pingapi.paas.uninett.no
> Analyzing paas.uninett.no
> Analyzing uninett.no
> Analyzing no
> Analyzing .
> Analyzing paas-lb.uninett.no

The HTML output from the DNSViz on the Unbound server is available here:

  https://uninett.box.com/s/3uz8fz7055oe788yrf0en3dmx651eyg1

(Changed from an attachment due to size restrictions on the list.)

Best regards,
Olav Morken
UNINETT / Feide

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

[Olav Morken via Unbound-users]

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 returns an authority 
section containing NS-records but no RRSIG-record for those records.

A longer version of the questions are at the end, but in short:

* Is this a bug in Unbound (it should handle those types of responses) 
  or in BIND (it should not generate those kind of responses).
* Could (and should?) Unbound be extended to deal with this type of 
  responses (no matter whether they are legal or not)?


Now the longwinded version:

We have an Unbound server running as a local caching resolver on a 
server. This instance is configured to forward requests to two 
resolvers, one running Unbound and one running BIND.

Both Unbound servers are running 1.4.22 from Debian Jessie. The BIND 
server is running version 9.9.8P2.

This error occurs frequently when doing lookups for a domain 
"pingapi.paas.uninett.no". This is handled by a wildcard CNAME 
pointing at "paas-lb.uninett.no". Since this is a wildcard CNAME, is 
must be authenticated with a NSEC3-record in the authority section.

As far as we can tell, the problem occurs because the BIND server is 
occasionally returning responses with NS-records in the 
authority-section that does not include the RRSIG records. 


There are actually two errors from Unbound due to this:

The first is when doing a request for the "pingapi.paas.uninett.no". 
In that case, the response from the resolver running BIND looks 
something like this:

  ;; ANSWER SECTION:
  pingapi.paas.uninett.no. 85 IN CNAME paas-lb.uninett.no.
  pingapi.paas.uninett.no. 85 IN RRSIG CNAME [...]
  paas-lb.uninett.no. 158 IN A 158.38.213.52
  paas-lb.uninett.no. 158 IN RRSIG A [...]
  
  ;; AUTHORITY SECTION:
  st5rjlutdrm3le5lla3r11bu3qu2qk06.uninett.no. 85 IN NSEC3 [...]
  st5rjlutdrm3le5lla3r11bu3qu2qk06.uninett.no. 85 IN RRSIG NSEC3 [...]
  uninett.no. 3408 IN NS server.nordu.net.
  uninett.no. 3408 IN NS benoni.uit.no.
  uninett.no. 3408 IN NS nac.no.
  uninett.no. 3408 IN NS ns.uninett.no.
  uninett.no. 3408 IN NS nn.uninett.no.

Note that the signature for the NSEC3-record is present, but no 
signature for the NS-records. At that point, Unbound rejects the 
response, and tries a different server:

  info: validator operate: query pingapi.paas.uninett.no. A IN
  debug: CNAME response was wildcard expansion and did not prove original data 
did not exist
  info: validate(cname): sec_status_bogus
  debug: iterator[module 1] operate: extstate:module_finished 
event:module_event_pass
  info: resolving pingapi.paas.uninett.no. A IN

Once the query hits the resolver running Unbound, it succeeds, and the 
local resolver moves on to resolving the "paas-lb.uninett.no" domain. 
At that point, it may query the resolver running BIND, and will get a 
response looking like:

  ;; ANSWER SECTION:
  paas-lb.uninett.no.   299 IN  A   158.38.213.52
  paas-lb.uninett.no.   299 IN  RRSIG   A [...]
  
  ;; AUTHORITY SECTION:
  uninett.no.   1118IN  NS  ns.uninett.no.
  uninett.no.   1118IN  NS  server.nordu.net.
  uninett.no.   1118IN  NS  nac.no.
  uninett.no.   1118IN  NS  nn.uninett.no.
  uninett.no.   1118IN  NS  benoni.uit.no.

Now I am a bit unclear about what happens, but as far as I can tell, 
Unbound sort-of accepts this response, since the authority-section 
isn't necessary to validate the answer. However, it then fails with 
the error from the subject line:

  [...]
  info: reply from <.> 158.38.212.107#53
  info: query response was CNAME
  info: resolving pingapi.paas.uninett.no. A IN
  info: processQueryTargets: pingapi.paas.uninett.no. A IN
  info: sending query: paas-lb.uninett.no. A IN
  debug: sending to target: <.> 2001:700:0:ff00::1#53
  debug: cache memory msg=89289 rrset=121419 infra=3788 val=77277
  debug: iterator[module 1] operate: extstate:module_wait_reply 
event:module_event_reply
  info: iterator operate: query pingapi.paas.uninett.no. A IN
  info: iterator operate: chased to paas-lb.uninett.no. A IN
  info: response for pingapi.paas.uninett.no. A IN
  info: reply from <.> 2001:700:0:ff00::1#53
  info: query response was ANSWER
  info: finishing processing for pingapi.paas.uninett.no. A IN
  debug: validator[module 0] operate: extstate:module_restart_next 
event:module_event_moddone
  info: validator operate: query pingapi.paas.uninett.no. A IN
  info: validator operate: chased to . TYPE0 CLASS0
  info: validate(cname): sec_status_secure
  info: validate(positive): sec_status_secure
  info: message is bogus, non secure rrset uninett.no. NS IN

My guess is that it somehow tries to combine the response it got from 
the server running BIND, which contains an 

Unbound 1.5.8 release

[W.C.A. Wijngaards via Unbound-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Unbound 1.5.8 is available:
http://www.unbound.net/downloads/unbound-1.5.8.tar.gz
sha1 1391888d2e3395d766545cd3dbdf0f1879c48080
sha256 33567a20f73e288f8daa4ec021fbb30fe1824b346b34f12677ad77899ecd09be
pgp http://www.unbound.net/downloads/unbound-1.5.8.tar.gz.asc
zip http://www.unbound.net/downloads/unbound-1.5.8.zip
win http://www.unbound.net/downloads/unbound_setup_1.5.8.exe .

The release fixes line endings in the unbound-control-setup script, and
a potential gost-hash validation failure and handles the ".onion" domain
to avoid privacy leakage.

Features
- -   ip-transparent option for FreeBSD with IP_BINDANY socket option.
- -   insecure-lan-zones: yesno config option, patch from Dag-Erling
Smørgrav.
- -   RR Type CSYNC support RFC 7477, in debug printout and config input.
- -   RR Type OPENPGPKEY support (draft-ietf-dane-openpgpkey-07).
- -   [bugzilla: 731 ] tcp-mss, outgoing-tcp-mss options for unbound.conf,
patch from Daisuke Higashi.
- -   Support RFC7686: handle ".onion" Special-Use Domain. It is blocked
by default, and can be unblocked with "nodefault" localzone config.
- -   ub_ctx_set_stub() function for libunbound to config stub zones.

Bug Fixes
- -   Fix that NSEC3 negative cache is used when there is no salt.
- -   sorted ubsyms.def file with exported libunbound functions.
- -   Print understandable debug log when unusable DS record is seen.
- -   load gost algorithm if digest is seen before key algorithm.
- -   Fix that "make install" fails due to "text file busy" error.
- -   Set IPPROTO_IP6 for ipv6 sockets otherwise invalid argument error.
- -   wait for sendto to drain socket buffers when they are full.
- -   Neater cmdline_verbose increment patch from Edgar Pettijohn.
- -   Made netbsd sendmsg test nonfatal, in case of false positives.
- -   [bugzilla: 741 ] Fix: log message for dnstap socket connection is
more clear.
- -   [bugzilla: 734 ] Fix: chown the pidfile if it resides inside the
chroot.
- -   Fix cmsg alignment for argument to sendmsg on NetBSD.
- -   Fix that unbound complains about unimplemented IP_PKTINFO for
sendmsg on NetBSD (for interface-automatic).
- -   [bugzilla: 738 ] Fix: Swig should not be invoked with CPPFLAGS.
- -   Squelch 'cannot assign requested address' log messages unless
verbosity is high, it was spammed after network down.
- -   Fix to simplify empty string checking from Michael McConville.
- -   [bugzilla: 734 ] Fix: Do not log an error when the PID file cannot
be chown'ed. Patch from Simon Deziel.
- -   Fix test if -pthreads unused to use better grep for portability.
- -   Fix mingw crosscompile for recent mingw.
- -   Update aclocal, autoconf output with new versions (1.15, 2.4.6).
- -   Define DEFAULT_SOURCE together with BSD_SOURCE when that is defined,
for Linux glibc 2.20.
- -   Fixup contrib/-filter-iterator.patch for moved contents in the
source code, so it applies cleanly again. Removed unused variable
warnings.
- -   [bugzilla: 729 ] Fix: omit use of escape sequences in echo since
they are not portable (unbound-control-setup).
- -   remove NULL-checks before free, patch from Michael McConville.
- -   updated ax_pthread.m4 to version 21 with clang support, this removes
a warning from compilation.
- -   OSX portability, detect if sbrk is deprecated.
- -   OSX clang, stop -pthread unused during link stage warnings.
- -   OSX clang new flto check.
- -   iana portlist update.

Best regards, Wouter
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJW1qBuAAoJEJ9vHC1+BF+NN0EP/RB+s62mgyQQMmCDpr0vHguu
kkD61T1SRGHm2C4wSJc7Fbf5Ouo7V2Q2XEJI/LRHHK5HDzKEE5hupe/qJyDw8u5i
oD/rc5LQhG6wCr3GoOtSyqYgueHefkGfjb3rQNr0+Nlk72yK7onYnfLZtsw2pqN5
5uieKuCJX9f93+zxbocdFrLsrSlFyYG4bdEktXI+ec5x9pdY06HHVr+F1qOSBW8s
WLZrQfUyh4nVyrjDg52ckLpdinW+AHyrsFTcd0FJSuB2ERA40eUrLnEzNdyJoe4o
HTsliuW7FzD6AMRL01m8qUV86Zhi1e9o4BgGtxQ6VHKeizpyMyGz+sqLEMYEwXQs
5X3S1cIBBVRYtGpW3p9MxxVUkrjl8zrSd1CpYeA0urXXOfuGn/2bLDUF5b11NDmi
UxTeDyypWx6RAhIpa37a7PP8qoe/FBk0uoD1D7EnnD/vYaOco706pNAHPKE6H8R2
BRHjyNnLGjf4wKFe+3kPi3Wzcu1o78PS9nZaxnjglrfZero0hhNma653E663Flcw
+sHmh594gO62psjky2tBivgBq6WIa0y1HNdjQUf6HO3LGtUW0/HXiCrn8NVTEOyu
3Bx9XC72sei99HhiNGtaWFa3HjTWdN2zZw4pQHjf1SSwFHlKMTAN0JxEIMQLNyPs
DebxRJ1VzvJGqdl2oaa0
=spbX
-END PGP SIGNATURE-