Maintained by: NLnet Labs

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

Casey Deccio
Thu Mar 3 15:19:59 CET 2016

On Thu, Mar 3, 2016 at 6:43 AM, Tony Finch via Unbound-users <
unbound-users at> wrote:

> Havard Eidnes <he at> 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.

This is one viewpoint, but there's more to it than suppressing bogus data.
There might be, for example, local policy or different/older implementation
for which data does not validate at the upstream forwarder, but for which
it might, if given the chance, by the downstream resolver.

About a year ago I reported a bug in BIND in which glue--rather than
authoritative--data was being returned from the cache in response to a
query for a name if 1) the glue data differed from the authoritative data
and 2) CD=1 was set.  If the zone was signed, it also sent an RRSIG along
with the glue data--the RRSIG for the authoritative data, which of course,
didn't cryptographically validate!  I don't know if this has been fixed,
but this seems very similar to the bug being discussed here: if CD=1, then
RFC 2181 priorities are being discarded.  Note that this is DNSSEC
independent, but DNSSEC validation is affected by it, as demonstrated in
the case I reported as well (glue instead of authoritative) as well as the
case at hand (delegation instead of authoritative NS).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>