On 06/11/15 13:28, Rich Felker wrote:
On Fri, Nov 06, 2015 at 01:11:47PM -0500, Simo Sorce wrote:
On 06/11/15 12:59, Rich Felker wrote:
On Fri, Nov 06, 2015 at 10:42:38AM +0100, Petr Spacek wrote:
On 5.11.2015 02:23, Rich Felker wrote:
On Wed, Nov 04, 2015 at 03:44:48PM -0500, Carlos O'Donell wrote:
Community,
I have written up a summary of the mailing list discussions
surrounding DNSSEC and the enhancements required to better
support it in glibc.
https://sourceware.org/glibc/wiki/DNSSEC
Any thoughts or comments would be much appreciated.
While I'm not opposed to clean ways to expose DNSSEC trust to
applications, I don't see a bit libc role in the ideal client setup:
you just run a local nameserver that verifies DNSSEC and replies with
ServFail upon receiving forged reslts/results that are supposed to be
signed but aren't.
This scheme is okay in principle and we want to deliver it in Fedora,
however,
it is missing one important aspect: It has to fail safe.
If the local validating resolver is not available for whatever reason the
application cannot rely on AD bit - doing so would be a security nightmare
because an attacker could easily spoof SSL/SSH key fingerprints etc.
In such a configuration, if the local validating resolver is not
available, all lookups fail with an inconclusive error.
Presumably you're assuming having a non-local backup nameserver
configured. Such a configuration is inherently broken and insecure.
resolv.conf should contain nothing but "nameserver 127.0.0.1" on a
DNSSEC enabled system.
The problem is what happen if you configure the system to have
127.0.0.1 in the normal case, then you attach a new network
interface and suddenly resolv.conf is changed to point to something
else (whatever DNS is passed to a dhcp client or vpn client or ...).
On a system configured with DNSSEC you do not allow resolv.conf to be
changed by dhcp clients. Doing so is a bug.
It is not whether you want it, it is what do you do when (not if) it happens.
Look, we all want DNSSEC, and we all want a local resolver and avoid bad
resolv.conf configuration, but we all also know that desires and reality are
two different thing.
Our end goal with Fedora (and eventually RHEL) is to end up with a default
local resolver and NetworkManager (or other appropriate daemon) controlling
resolv.conf (probably setting it with the immutable filesystem flag and what
not).
However we are not there, and there are ton of Linux distributions that we
have no say over and will continue to allow dhclient, vpn clients, and whatnot
to change resolv.conf
In order for *any* application to be able to trust glibc's AD bit, glibc must
give guarantees that it will not serve data from untrusted servers (or exposes
indication about trustability).
To do that glibc needs to know that a server *is* indeed trusted. and looking
at the nameserver field is obviously not sufficient, because no matter how
ardently we desire so, common/existing configuration managers slap in random
servers with no regard.
So how do we indicate to glibc that a server is trusted in a way that
applications can trust it and other commonly used resolver libraries (like
c-ares for example) can learn to use ?
We need a (positive) way to tell glibc, unequivocally, that the system is
handled by a configuration manager (whether that is software or an admin
manually setting configuration options doesn't matter) that is aware and know
how to properly set the system for DNSSEC.
The easiest mostr compatible way to tell glibc is by adding/changing an option
in resolv.conf, an option not used by current existing configuration managers.
Then glibc has two options to deal with applications:
- always strip AD bits unless trusted resolver is enabled
or
- add a new public function that applications can call to query if glibc is
currently configured with a trusted resolver or not.
A situation in which glibc does not use an explicit configuration option to
signal applications that it is using a trusted resolver is not useful ... no
scratch that, it is actively harmful, because applications developers will
quickly realize they cannot trust any information coming from glibc and will
simply not use it for DNSSEC related information.