Building consensus over DNSSEC enhancements to glibc.

[Simo Sorce]

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 ...).

Do we fail safe and start stripping the AD bit ? Or do we start giving 
apps untrusted AD bits ?

Our systems are not static these days, so this is something we need a 
clear answer for.

Simo.


-- 
Simo Sorce * Red Hat, Inc * New York