<div dir="ltr">On Thu, Mar 3, 2016 at 6:43 AM, Tony Finch via Unbound-users <span dir="ltr"><<a href="mailto:unbound-users@unbound.net" target="_blank">unbound-users@unbound.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">Havard Eidnes <<a href="mailto:he@uninett.no">he@uninett.no</a>> wrote:<br>
><br>
> > CD=1 is the wrong thing when querying a forwarder. When a<br>
> > domain is partly broken, queries that work with CD=0 can be<br>
> > forced to fail with CD=1.<br>
><br>
> Relly?  I interpreted the use of CD=1 as "I want to do my own<br>
> DNSSEC validation, and therefore don't want or need the<br>
> validation service which could be provided by the forwarder",<br>
> especially as noted above when the communication isn't secured.<br>
> It should not make much of a difference wrt. the validity of the<br>
> end result whether the forwarder or the unbound resolver does the<br>
> DNSSEC validation?<br>
<br>
</span>This current case is a perfect example: unbound works when it queries<br>
upstream with CD=0 but not with CD=1.<br>
<br>
If a domain is a bit broken then you can get bogus data into the upstream<br>
cache using CD=1 and subsequent CD=1 queries will receive the bogus data.<br>
If the downstream validator doesn't have an alternative resolution path it<br>
is now stuck. But if it queries with CD=0 it can get unstuck.<br>
<br>
You need to suppress bogus data at every point in the resolution path.<br>
<br>
<a href="https://www.ietf.org/mail-archive/web/dnsop/current/msg11512.html" rel="noreferrer" target="_blank">https://www.ietf.org/mail-archive/web/dnsop/current/msg11512.html</a><br>
<span class=""></span></blockquote><div><br></div><div>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.<br><br></div><div>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).<br></div><div><br></div><div>Casey <br></div></div></div></div>