Maintained by: NLnet Labs

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

W.C.A. Wijngaards
Thu Mar 17 15:19:52 CET 2016


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 RRsets in answer and authority
>> sections should be authentic ...
> 
> That's an incomplete quote.  A more complete quote would be:
> 
> 3.2.3.  The AD Bit
> 
>    The name server side of a security-aware recursive name server MUST
>    NOT set the AD bit in a response unless the name server considers all
>    RRsets in the Answer and Authority sections of the response to be
>    authentic.  The name server side SHOULD set the AD bit if and only if
>    the resolver side considers all RRsets in the Answer section and any
>    relevant negative response RRs in the Authority section to be
>    authentic. [...]
> 
> However, since the CD ("Checking Disabled") bit is set in the query
> Unbound sends to its forwarder, the AD ("Authentic Data") bit is of
> course not set in its response, so this whole section doesn't really
> apply.

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.

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.

CD flag is still used on all queries to authorities.

Best regards, Wouter

> 
> Please also note that this section only talks about setting the AD
> bit, not about whether it's mandatory to include "all required DNSSEC
> records that the querier is missing and which are required to validate
> the included information".
> 
> If such or a similar mandate exists on a recursive resolver, it must
> come from elsewhere.
> 
> Therefore my suggestion: "If the validator needs more information to
> complete validation, it had better ask for it explicitly."
> 
> As has been pointed to elsewhere in this thread there's a question of
> whether setting the CD bit in queries sent to a forwarder is
> appropriate, but RFC 6840 (Clarifications and Implementation notes for
> DNS security) seems to recommend the practice, ref. section 5.9, but
> also lists a number of different ways this can be done, ref. appendix
> B, which also mentions the possibility of there being more than one
> validator on the path, as can be the case when using a forwarder.
> 
> Regards,
> 
> - Håvard
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20160317/012a68b3/attachment.sig>