Re: resolv.conf format for DNSSEC [was: DNSSEC support in stub-resolver]

[Rich Felker <dalias at libc dot org>]

On Fri, Jun 13, 2014 at 01:32:10PM +0200, Nikos Mavrogiannopoulos wrote:
> On Thu, 2014-06-12 at 09:08 -0700, Roland McGrath wrote:
> > Are there other systems with DNSSEC support built in?
> > What syntax do they use for resolv.conf?
> 
> I'm not aware of any system with dnssec built-in on libc and the ones I
> know I don't think they distinguish between trusted and non-trusted name
> servers. As it is now applications use external libraries for the dnssec
> operations (e.g., libunbound, or APIs like [0,1]), and these libraries
> have their own configuration, rather than rely on resolv.conf.

I really question the need for this. At worst it may even be a source
of vulnerabilities. Linking cryptographic code into every process's
namespace exposes them to bugs in said code (and by now we all know
how that ends).

IMO the right way to do DNSSEC is to run a nameserver (recursive or
just caching) on localhost, list it as the only nameserver in
resolv.conf, and have it be responsible for verification of trust.
Then in case of any vulnerability, the worst that happens is the
attacker gaining control over name resolution on the host, rather than
gaining full privilege elevation to the privilege level of the process
performing the lookup.

Perhaps I'm missing something and the intent of this thread is only to
add mechanisms for the resolver to report whether the nameserver
claims the response is trusted, rather than actually doing any
verification on the client side. If so, that might not be
unreasonable.

Rich