This is the mail archive of the
mailing list for the glibc project.
Re: DNSSEC support in stub-resolver
- From: Nikos Mavrogiannopoulos <nmav at redhat dot com>
- To: libc-alpha at sourceware dot org
- Date: Fri, 23 May 2014 08:21:21 +0000 (UTC)
- Subject: Re: DNSSEC support in stub-resolver
- Authentication-results: sourceware.org; auth=none
- References: <535E41F5 dot 5020109 at redhat dot com>
Petr Spacek <pspacek <at> redhat.com> writes:
> Hello list,
> IETF mailing list dedicated to DNS-DANE hosted a lengthy discussion  about
> DNSSEC support in stub-resolvers.
> The questions are mostly:
> - How can we enable applications to use DNSSEC easily *and securely*?
It would be great to have that in libc. As it is now, applications need to
include a full resolver + dnssec library if they want to use dnssec. That is
extremely annoying in my case where I have a DANE library based on gnutls,
that needs to depend on an openssl dnssec library.
> is to *avoid* adding application-specific switches to all applications
dealing with DNS.)
> The discussion on DANE list was focused on the principle of configuring trust
> in stub-resolver, we didn't discuss API extensions etc.
> Now, I would like to start discussion about potential extensions to libresolv
> API & configuration.
> *This is first and raw draft, any suggestions are more than welcome!*
I think this draft addresses the use cases for DNSSEC that I am interested
on (mostly related to DANE).
> API extensions
> 1) getnameinfo/getaddrinfo
> Goal: Enable secure name-address-name translations chains like *FQDN* ->
> canonical FQDN resolution.
> - Add flags AI_SECURE_ONLY and NI_SECURE_ONLY (or something like that)
> - Use (RES_NOALIASES & RES_USE_DNSSEC)
> - Do not use (RES_DNSRCH & RES_DEFNAMES)
> - Return answer only if result is deemed to be secure
> - Return EAI_INSECURE if an answer was received but is not deemed secure
> - Return other EAI_* errors as usual
> 2) res_* interface
> Goal: Get data associated with given *FQDN* and make sure that nobody
> with it.
> - Add new flag RES_SECURE_ONLY to _res.options
> - All res_* functions should fail if RES_SECURE_ONLY is set but
I dislike the global nature of this flag as it means that locks will be
needed for every resolve, but that looks like an issue of the resolver's API.