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

[Havard Eidnes]

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

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?

The closest I've been able to find is section 3.1.1 in RFC 4035,
and that section only applies to authoritative name servers.

In the absence of any forwarding configuration, unbound always
expects to speak with authoritative name servers, and then it
makes sense to enforce the text from 3.1.1.  However, when it
uses forwarding it will send all its requests via one or more
non-authoritative recursive resolvers, and then insisting on
RRSig on all RRsets in the authoritative section no longer makes
sense.  Instead, unbound should adhere to the rule "if you need a
specific RRset (that you've not already been given) to proceed,
you had better ask for it explicitly".

Therefore, in the absence of any contradictory quote from the
standards, I conclude that the current behaviour of unbound in a
forwarding setup is a bug in unbound.

Best regards,

- Håvard