Re: Building consensus over DNSSEC enhancements to glibc.

[Zack Weinberg <zackw at panix dot com>]

On 11/14/2015 12:25 PM, Rich Felker wrote:
> On Tue, Nov 10, 2015 at 08:47:22PM -0500, Zack Weinberg wrote:
>> On 11/04/2015 03:44 PM, 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.
>>
>> (I am not a DNS nerd, but I *am* a security nerd.)
>>
>> The conversation so far has convinced me of something I've suspected for
>> a while: The nameservers configured in /etc/resolv.conf *cannot* be
>> trusted - not even 127.0.0.1.  The only approach that seems viable to me
>> is to scrap the idea of outsourcing DNSSEC validation to a local DNS server.
> 
> Why can't 127.0.0.1 be trusted? It runs in essentially the same
> privilege domain as the nscd. If resolv.conf is misconfigured this is
> a broken system installation and in general glibc cannot protect you
> from that.

Don't you see that the entire rest of this thread demonstrates that
trying to eliminate all the "broken things distros and dhcp client
software are doing" is a lost cause?

But even if we *could* be sure that resolv.conf had not been changed out
from under our feet, that wouldn't be good enough, because we have no
way of knowing whether the local recursive resolver actually implements
DNSSEC validation.  It would be perfectly possible for someone to slot
in a local resolver that sets the AD bit on *every response* - and I
fully expect people to do that exact thing, for the same reasons that
they love stubbing out TLS certificate validation.

Using nscd avoids that problem because glibc controls the code on both
sides of /var/run/nscd/socket.  (Yes, I know about unscd.)  In
particular, we can be confident that there are no configuration knobs
that produce insecure behavior when frobbed.  And, /etc/nscd.conf *can*
be in a different privilege domain than /etc/resolv.conf - don't even
need SELinux for that, all it takes is some groups.

zw