Re: Building consensus over DNSSEC enhancements to glibc.
From: | Zack Weinberg <zackw-AT-panix.com> | |
To: | Rich Felker <dalias-AT-libc.org> | |
Subject: | Re: Building consensus over DNSSEC enhancements to glibc. | |
Date: | Mon, 16 Nov 2015 20:18:19 -0500 | |
Message-ID: | <564A805B.4090103@panix.com> | |
Cc: | libc-alpha-AT-sourceware.org |
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
(Log in to post comments)