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.