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

[W.C.A. Wijngaards]

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

RFC4035 3.2.3 for validators, all RRsets in answer and authority
sections should be authentic ...

https://tools.ietf.org/html/rfc4035#section-3.2.3

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

Yes and I had not counted on getting a partial referral mixed into
another reply from a forwarder.

Best regards, Wouter

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJW1/lAAAoJEJ9vHC1+BF+NRUwP/A35eRI+/FxrXGJZUwfyx4QC
Ozt8pDiQ3h1ik5YLXoU85JeKOTyj7lhmdzCNvw/yzfFLSmon3F5URHor8KKGnbWn
k2mZU9Rgh+JlR1k3Dcwl9ayOtBr/1VF/lJh4tXXxgEWgUxLT7jacAGdDq0fZKlGz
42t3l+biIbUKK2oQq15/ytfZSQD6yBGndqgJjDDhEP11Kfv0QazPKGDGRyPcWe9R
XbqToc5qm7F7bl4Q8dXscGt4kQvHz6vCNAtikZHUAd1gHduQ8Bz9sKJv5LunjRFl
NXOCgRZpH81LbGzcMdzzt4tN9kEbwwxzFo1lb9s9ocsVpxs0j4AKa1D5DMU747zN
y8V0lekSz4SEu6++krdmykWIyvLc94lHudbWwvdxqqWkTuFE/g9mhMjvdQbISl9n
xlJEOP/5mFoEIZXH9x2tfH6uM/JQzQxQ1mbbQQoxY3rvy3yfDYx20iGPThmjjfnt
jIjmaGGQR0OXI5M9bSbGC1J99OLO/xNgjw5QvCAij1Y8Go870N/eyxw81cfyFZvV
QCU6lLUJKGIrexFQAGf6GxeexMFte2ZeSUyy1SR2ufP0+7pYUeUpMN01Bxswjglh
IdftX+PrPjsAChTmwZFm3r/OPPKv9ByVZKYlZQNwDujvgHdlPzQbj8KKHLlyyiGu
AEJYnq60g0PUmi+W6e3B
=1MWD
-----END PGP SIGNATURE-----