<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-04-26 0:51 GMT+02:00 Chuck Anderson <span dir="ltr"><<a href="mailto:cra@wpi.edu" target="_blank">cra@wpi.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Main goal is to have local DNSSEC-validating resolver.<br>
<br>
I, as the OP, did not intend that as the goal, although I have no<br>
problem with that as a different goal. My intent was to fix the<br>
atrocious failover behavior of the glibc resolver. I also don't mind<br>
using a caching resolver BUT there should be a better stub resolver<br>
that can be widely deployed in a default configuration that doesn't<br>
require a local caching resolver to paper over its deficiencies.<br>
Maybe nscd (and some of the other ideas in the link I posted) are part<br>
of the solution.<br>
<br>
Basically, we aren't going to win the war by suggesting that everyone<br>
should run a DNSSEC-validating resolver everywhere.</blockquote><div><br></div><div>Right now I'd actually guess that it's more likely to have a DNSSEC-validating resolver soon, than the simple caching daemon you propose. Specific people are already dedicated to working on the former, and the principal elements of the solution already exist; what is left is (a large amount of) integration work. And that will also inherently handle the caching/failover case "for free".<br>
<br>OTOH the caching daemon initiative would require new research, probably new implementation, and about the same large amount of integration work (currently unstaffed for <i>that</i> project)—and then doing the integration all over again when we do decide deploy DNSSEC.<br>
</div><div> Mirek<br></div></div><br></div></div>