[RFC] support for trusted validating resolver configuration

[Florian Weimer]

On 11/18/2014 01:40 PM, Pavel Simerda wrote:
> Goals:
>
>   * Applications can rely on the AD flag coming from the library.
>      - It's either cleared out or it comes from a trusted validating resolver.

Hi Pavel,

I have looked at the situation, I think there are actually two goals here.

(1) Prevent updating the nss_dns configuration from untrusted sources 
(such as DHCP).

(2) The AD flag matter.

I think (1) is a separate issue because there are so many things that 
can unexpectedly edit /etc/resolv.conf, essentially taking a trust, 
local validating resolver (whether recursive or not) out of the picture.

It's better to consider (2) because that part is really complex.  (I 
firmly believe we should in no way encourage applications to alter 
behavior on the AD bit—we did this with HTTP, and made encrypting HTTP 
opportunistically more difficult.)  But the nice thing is that if there 
is a foolproof way to lock a system to a trusted resolver, then the 
correctness of the AD bit matters less (in the sense that you can be 
sure that you receive DNS data at the security level specified by 
relevant zone operators).

>   * Backwards compatibility for free.
>      - Supporting software writes both resolv.conf and resolv-secure.conf and
>        reads resolv-secure.conf falling back to resolv.conf when missing.
>      - Other software writes resolv.conf (thus won't overwrite
>        resolv-secure.conf) and reads resolv.conf.

I fear this might be overly optimistic because if updates to 
/etc/resolv.conf are not inhibited in another way, these legacy 
applications would still send queries to the wrong resolver, and use the 
wrong search path.

>   * Easy to support in dynamic configuration tools like dnssec-trigger.
>      - The tool simply stores its resolv.conf somewhere in /run and creates
>        symlinks /etc/resolv.conf and /etc/resolv-secure.conf.
>      - Any other tools will immediatly learn where the data comes from by
>        checking the symlink target and act accordingly.

Note that some parts of systemd assume that they own the 
/etc/resolv.conf symbolic link, so this may or may not work in practice.

For goal (1), there is also the question where the contents of 
/etc/resolv-secure.conf will come from.  Obviously, DHCP is out.

Florian
-- 
Florian Weimer / Red Hat Product Security