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: Petr Spacek <pspacek at redhat dot com>
- To: libc-alpha at sourceware dot org
- Date: Fri, 13 Jun 2014 18:51:12 +0200
- 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> <20140613163110 dot GB179 at brightrain dot aerifal dot cx>
On 13.6.2014 18:31, Rich Felker wrote:
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
That is exactly the point.
This thread is exactly about "run a nameserver (recursive or just caching) on
localhost" + *make sure that system is secure even if the server is not
running locally* (because admin never installed it etc.).
We are not going add/link glibc with crypto code.
Have a nice day!
Petr Spacek @ Red Hat