This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: resolv.conf format for DNSSEC [was: DNSSEC support in stub-resolver]
- From: Nikos Mavrogiannopoulos <nmav at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Roland McGrath <roland at hack dot frob dot com>, libc-alpha at sourceware dot org
- Date: Mon, 16 Jun 2014 09:10:19 +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 Fri, 2014-06-13 at 12:31 -0400, 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.
This is what I am proposing, and this is the reason we need the
additional resolv.conf entry to allow specifying the trusted (for
dnssec) name server.
regards,
Nikos