This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Building consensus over DNSSEC enhancements to glibc.
- From: Rich Felker <dalias at libc dot org>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Sat, 14 Nov 2015 12:25:04 -0500
- Subject: Re: Building consensus over DNSSEC enhancements to glibc.
- Authentication-results: sourceware.org; auth=none
- References: <563A6E40 dot 9040508 at redhat dot com> <56429E2A dot 7050208 at panix dot com>
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. (A broken system installation could also have a version of
glibc that's patched to be intentionally broken.)
One option would be to add an /etc/dnssecure file or similar which, if
it exists, fully suppresses use of resolv.conf and forces a single
nameserver at 127.0.0.1. But I see this as a band-aid for broken
things distros and dhcp client software are doing. The right fix is
just fixing distro policy to stop overwriting resolv.conf.
Rich