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: Petr Spacek <pspacek at redhat dot com>
- To: libc-alpha at sourceware dot org
- Date: Tue, 10 Nov 2015 11:17:56 +0100
- 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 9.11.2015 19:03, 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. 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.
This can work in theory but you would have to have whole DNSSEC
validator/crypto stack in the init ramdisk, which may not be an option.
As Simo said, failing safe is the an important principle in security land so
saying 'that should not happen' is not good enough.
What would be an acceptable way to implement this in a fail-safe way?
--
Petr Spacek @ Red Hat