This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Building consensus over DNSSEC enhancements to glibc.


On 11/13/2015 11:38 PM, Carlos O'Donell wrote:
> On 11/10/2015 08:47 PM, 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.
> 
> Could you expand on this a bit?
> 
> How is outsourcing to a local validating resolver different from outsourcing
> to nscd?

So first off, I hope you agree with me that outsourcing DNSSEC to a
local DNS server is not an option.  If the rest of this thread hasn't
convinced you of that, I don't know what to say.

The most straightforward alternative, the option with the fewest moving
parts and the fewest ways it could fail insecure, would be to do
validation in-process - imagine replacing libresolv with libunbound, or
something like that.  I would actually prefer that to an nscd-based
approach.

However, I can see a case for some sort of local, DNSSEC-aware cache.
We *can* trust nscd to do that job, even though we can't trust a local
DNS server, because we provide the code on both sides of the
communications channel, and we *don't* look at resolv.conf to find out
where to talk to nscd.  It's /var/run/nscd/socket or nothing.  And
nobody is mucking with nscd.conf the way they muck with resolv.conf; we
can stick validation options in there and rely on them *staying* there.

Unrelatedly, I hope you also agree with me that exposing the AD bit to
applications is a Bad Idea unless they explicitly demonstrate that they
know what they are doing by using a low-level API. If getaddrinfo() does
not fail hard in the condition DNSSEC calls "bogus", there will be
exploitable application bugs.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]