On Thu, Mar 3, 2016 at 6:43 AM, Tony Finch via Unbound-users < unbound-users@unbound.net> wrote:
> Havard Eidnes <h...@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
