This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]