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: Simo Sorce <simo at redhat dot com>
- Cc: Petr Spacek <pspacek at redhat dot com>, libc-alpha at sourceware dot org, Paul Wouters <pwouters at redhat dot com>
- Date: Fri, 6 Nov 2015 13:28:35 -0500
- Subject: Re: Building consensus over DNSSEC enhancements to glibc.
- Authentication-results: sourceware.org; auth=none
- References: <563A6E40 dot 9040508 at redhat dot com> <20151105012328 dot GU8645 at brightrain dot aerifal dot cx> <563C760E dot 4060107 at redhat dot com> <20151106175956 dot GA3818 at brightrain dot aerifal dot cx> <563CED63 dot 1070201 at redhat dot com>
On Fri, Nov 06, 2015 at 01:11:47PM -0500, Simo Sorce wrote:
> 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 ...).
On a system configured with DNSSEC you do not allow resolv.conf to be
changed by dhcp clients. Doing so is a bug.
Rich