<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 17, 2014 at 5:09 PM, Chris Adams <span dir="ltr"><<a href="mailto:linux@cmadams.net" target="_blank">linux@cmadams.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Once upon a time, Juan Orti <<a href="mailto:juan.orti@miceliux.com">juan.orti@miceliux.com</a>> said:<br>
> systemd-resolved is a daemon for resolving DNS. What's wrong about<br>
> caching? All DNS servers perform caching.<br>
><br>
> It's like if you have unbound at 127.0.0.1 as local resolver, that's a<br>
> very common setup.<br>
<br>
</span>Well, that's the point. We already have multiple, perfectly functional,<br>
caching resolvers. We have resolver libraries. Why did the systemd<br>
project add this to the scope of the project for "a system and service<br>
manager for Linux"? Why didn't they re-use existing services and/or<br>
libraries? Why re-invent a wheel that happens to have a number of<br>
corner cases that can be tricky to get right (and a security problem if<br>
you get it wrong)?<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>In general DNS caching may be useful, but with other perfectly good solution(s) (i.e. nscd) for Linux the implementation of the same in systemd does not add value.</div></div></div></div>