message is bogus, non secure rrset with Unbound as local caching resolver
Jan Komissar (jkomissa)
jkomissa at cisco.com
Thu Mar 3 15:21:19 UTC 2016
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:
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.
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>
>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.
>f.anthony.n.finch <dot at dotat.at> http://dotat.at/
>Southeast Iceland: Easterly or northeasterly, 4 or 5, occasionally 6,
>variable 4 later in west. Moderate or rough, occasionally very rough
>south. Mainly fair. Good.
More information about the Unbound-users