default local DNS failover solution needed, nscd?
P J P
pj.pandit at yahoo.co.in
Mon Apr 28 05:39:21 UTC 2014
(sorry for the delayed response, I was away past few days)
2014-04-26 0:51 GMT+02:00 Chuck Anderson wrote:
>> Main goal is to have local DNSSEC-validating resolver.
>I, as the OP, did not intend that as the goal, although I have no
>problem with that as a different goal. My intent was to fix the
>atrocious failover behavior of the glibc resolver.
Agreed. There are several reasons to have a local DNS resolvers. Nonetheless, one solution may not address all use cases. For that reason, one of the requisites gathered from the earlier long thread is
+ Choice between different DNS resolvers - unbound, bind, dnsmasq, dnslookupd etc. etc.
- you would want to have plugins for those in NetworkManager
Please see -> https://www.piratepad.ca/p/dnssec-requisites-configurations
As Miloslav rightly said, supporting each new DNS resolver would entail resolver specific integration work and relevant upstream development work.
We plan to do our _best_ to address maximum use cases and provide due guidance for the others. But for that, it is essential to gather first hand data and list down all the DNS resolver use cases across desktops/servers/workstations/thin clients/data centres/cloud/containers etc. etc. Anything and everything that uses DNS resolver, we need to know about it. Having such data would _greatly_ help to device a robust solution.
Please help us by spreading the word about it, so that we have more & more real life data on that ether pad. That way we can estimate the amount of work to be done and invite contributors to take-up individual tasks. More hands together can easily make huge difference.
On Saturday, 26 April 2014 4:29 AM, Miloslav Trmač wrote:
>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".
More information about the devel