On Wed, Feb 26, 2014 at 07:41:00PM -0500, Paul Wouters wrote:
> That and I prefer solutions working on obsoleting resolv.conf
> over extending it and I think most cases can already be covered by
> running a DNS server on localhost - with the exception of laptops
> (dnssec-trigger+unbound does not cut it yet for non-techies)
I think obsoleting resolv.conf would be a grave mistake. More
precisely, control over the security properties of the default list
of recursive resolvers needs to be by default in the hands of the
party that sets up the set of resolvers. Some applications may
want to tweak this, but out of the box the system administrator
sets the resolver list, and designates them trusted or not.
Applications that delegate validation are rarely well positioned
to know all the gory details, certainly not by default.
So while system configuration may default to fail safe (not lie),
it should be up to the administrator, not the application user or
developer to vouch for the safety of a given configuration.
> So far it seems people are leaning towards A) over B) while everyone
> seems to agree doing DNSSEC on the host itself (server or in-app) is
> still the preferred method.
Modulo some adamant administrators who insist that multiple resolvers
on a physically secured firewalled LAN obviate the need for a local
resolver on each machine, and desperately want to configure trust
in nearby, but not on-host local resolvers. (See earlier link to
postfix-users list).
For them, I am proposing a damn-the-torpedoes flag in resolv.conf,
global boolean, rather than a one nameserver at a time white-list.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
