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: Petr Spacek <pspacek at redhat dot com>
- Cc: Simo Sorce <simo at redhat dot com>, libc-alpha at sourceware dot org, Paul Wouters <pwouters at redhat dot com>
- Date: Mon, 9 Nov 2015 13:03:10 -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> <20151106182835 dot GC3818 at brightrain dot aerifal dot cx> <563D0953 dot 9020707 at redhat dot com> <56407C19 dot 2080906 at redhat dot com>
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. All this requires is changing your dhcp client
scripts to store the nameservers somewhere other than resolv.conf and
notify the local nameserver to use them. The difference from normal
dhcp setups is that it's secure against fake/malicious nameservers. If
the dhcp-provided nameservers produce fake records, the signatures
won't match (or won't be present) ansd they won't be used. In that
case the local nameserver can try to fallback to known upstream
sources or doing its own recursion if desired; otherwise all lookups
just fail.
Rich