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

[Casey Deccio]

On Thu, Mar 3, 2016 at 6:43 AM, Tony Finch via Unbound-users <
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
>

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).

Casey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20160303/5b6278e5/attachment.htm>