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

[Havard Eidnes]

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

Yep, indeed, this does appear to be exactly the same root cause,
although DLV isn't really relevant to the problem.  Unbound appears to
enforce compliance to section 3.1.1 of RFC 4035 even when it's
querying a forwarder, which is a non-authoritative recursive resolver.
In fact, the entire 3.1 section only talks about the behaviour of
authoritative name servers, while section 3.2 talks about recursive
name servers.  Thus, unbound enforcing 3.1.1 on responses to forwarded
queries is just Wrong, and a bug in unbound.

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

Come to think of it, anything you get from a recursive resolver are
possibly cached hints, including what you get in the Answer section.
If a validating resolver needs other RRsets than those supplied in the
answer (all sections) or what it has in the cache, it should
explicitly ask for them.

Granted, modern recursive name servers used for forwarding will set
"DNSSEC OK" in outgoing queries (as mandated by RFC 3225), and will
supply any cached related DNSSEC material in the reply when queried
with the "DNSSEC OK" flag set.  However, it does not have to comply to
section 3.1 of RFC 4035 when composing the reply.

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

Yep, as Olav replied, and the pcaps I capture on the BIND recursor
agrees: CD=1 is set in the forwarded queries.

Regards,

- Håvard