Re: DNSSEC support in stub-resolver

[Nikos Mavrogiannopoulos <nmav at redhat dot com>]

Petr Spacek <pspacek <at> redhat.com> writes:

> 
> Hello list,
> IETF mailing list dedicated to DNS-DANE hosted a lengthy discussion [0] 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.)

Also true.

> 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* ->
IP -> 
> 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

Looks reasonable.

> 2) res_* interface
> Goal: Get data associated with given *FQDN* and make sure that nobody
tampered 
> 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.

regards,
Nikos