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: Paul Wouters <pwouters at redhat dot com>
- To: Rich Felker <dalias at libc dot org>, Petr Spacek <pspacek at redhat dot com>
- Cc: Simo Sorce <simo at redhat dot com>, libc-alpha at sourceware dot org
- Date: Mon, 16 Nov 2015 18:37:55 +0900
- 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> <20151106182835 dot GC3818 at brightrain dot aerifal dot cx> <563D0953 dot 9020707 at redhat dot com> <56407C19 dot 2080906 at redhat dot com> <20151109180310 dot GO3818 at brightrain dot aerifal dot cx>
On 11/10/2015 03:03 AM, Rich Felker wrote:
> On Mon, Nov 09, 2015 at 11:57:29AM +0100, Petr Spacek wrote:
>> One of reasons why 'nameserver 127.0.0.1' only cannot work are systems which
>> boot from network. Imagine that the system is booting so it does not
>> necessarily have local resolver running (yet) but the system might need to
>> mount NFS share with / from somewhere, probably from a NFS server which is
>> identified by DNS name.
>
> That works perfectly well. You simply configure it to use the
> nameservers from dhcp as the upstream sources for the nameserver
> running on localhost.
That does not address the problem of the network being able to set AD bits in DNS packets.
AD bits are _not_ protected by a signature of any kind.
Obviously, a fully validating locally running resolver is the best solution. It's the corner cases we are trying to address.
Paul