This is the mail archive of the
mailing list for the glibc project.
Re: resolv.conf format for DNSSEC [was: DNSSEC support in stub-resolver]
- From: Rich Felker <dalias at libc dot org>
- To: Nikos Mavrogiannopoulos <nmav at redhat dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, libc-alpha at sourceware dot org
- Date: Fri, 13 Jun 2014 12:31:10 -0400
- Subject: Re: resolv.conf format for DNSSEC [was: DNSSEC support in stub-resolver]
- Authentication-results: sourceware.org; auth=none
- References: <535E41F5 dot 5020109 at redhat dot com> <loom dot 20140612T135904-448 at post dot gmane dot org> <20140612160823 dot E308B2C39C1 at topped-with-meat dot com> <1402659130 dot 6191 dot 52 dot camel at dhcp-2-127 dot brq dot redhat dot com>
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