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 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
unreasonable.

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


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