Re: Building consensus over DNSSEC enhancements to glibc.

["Carlos O'Donell" <carlos at redhat dot com>]

On 11/09/2015 05:57 AM, Petr Spacek wrote:
> On 6.11.2015 21:10, Simo Sorce wrote:
>> 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.
> 
> One of reasons why 'nameserver 127.0.0.1' only cannot work are systems which
> boot from network. Imagine that the system is booting so it does not
> necessarily have local resolver running (yet) but the system might need to
> mount NFS share with / from somewhere, probably from a NFS server which is
> identified by DNS name.
> 
> That is exactly the case where you want to use remote DNS server for name->IP
> resolution but at the same time the DNS server should not be trusted for
> DNSSEC validation because as you said, only 127.0.0.1 can give you trustworthy
> answers. Sure, there should not be anything relying on DNSSEC during the boot
> process, but faith is not a good security principle.
> 
> To return back to the main discussion:
> What can we do to design and implement *something* which fails safe?

Such a system must boot with `options dns-strip-dnssec-ad-bit` in /etc/resolv.conf
and if anything change that, then it's a bug.

Once the system has the locally running validating resolver with all the appropriate
policy in place then you can remove the `options` entry.

c.