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

[Jan Komissar (jkomissa)]

It does seem that the CD bit is the key to this: RFC4035 3.2.2 talks about
it (https://tools.ietf.org/html/rfc4035#section-3.2.2), mainly:

<snip>
The name server side of a security-aware recursive name server MUST
   pass the state of the CD bit to the resolver side along with the rest
of an initiating query, so that the resolver side will know whether
   it is required to verify the response data it returns to the name
   server side.  If the CD bit is set, it indicates that the originating
   resolver is willing to perform whatever authentication its local
   policy requires.  Thus, the resolver side of the recursive name
   server need not perform authentication on the RRsets in the response.
   When the CD bit is set, the recursive name server SHOULD, if
   possible, return the requested data to the originating resolver, even
   if the recursive name server's local authentication policy would
   reject the records in question.  That is, by setting the CD bit, the
   originating resolver has indicated that it takes responsibility for
   performing its own authentication, and the recursive name server
   should not interfere.

</snip>

Just FYI,

Jan.




On 3/3/16, 6:43 AM, "Unbound-users on behalf of unbound-users at unbound.net"
<unbound-users-bounces at unbound.net on behalf of unbound-users at unbound.net>
wrote:

>Havard Eidnes <he at uninett.no> wrote:
>>
>> > CD=1 is the wrong thing when querying a forwarder. When a
>> > domain is partly broken, queries that work with CD=0 can be
>> > forced to fail with CD=1.
>>
>> Relly?  I interpreted the use of CD=1 as "I want to do my own
>> DNSSEC validation, and therefore don't want or need the
>> validation service which could be provided by the forwarder",
>> especially as noted above when the communication isn't secured.
>> It should not make much of a difference wrt. the validity of the
>> end result whether the forwarder or the unbound resolver does the
>> DNSSEC validation?
>
>This current case is a perfect example: unbound works when it queries
>upstream with CD=0 but not with CD=1.
>
>If a domain is a bit broken then you can get bogus data into the upstream
>cache using CD=1 and subsequent CD=1 queries will receive the bogus data.
>If the downstream validator doesn't have an alternative resolution path it
>is now stuck. But if it queries with CD=0 it can get unstuck.
>
>You need to suppress bogus data at every point in the resolution path.
>
>https://www.ietf.org/mail-archive/web/dnsop/current/msg11512.html
>
>Tony.
>-- 
>f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
>Southeast Iceland: Easterly or northeasterly, 4 or 5, occasionally 6,
>becoming
>variable 4 later in west. Moderate or rough, occasionally very rough
>later in
>south. Mainly fair. Good.