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: Simo Sorce <simo at redhat dot com>, Rich Felker <dalias at libc dot org>
- Cc: Petr Spacek <pspacek at redhat dot com>, libc-alpha at sourceware dot org
- Date: Sat, 7 Nov 2015 08:31:47 +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>
On 11/07/2015 05:10 AM, Simo Sorce wrote:
> However we are not there, and there are ton of Linux distributions that we have no say over and will continue to allow dhclient, vpn clients, and whatnot to
> change resolv.conf
>
> In order for *any* application to be able to trust glibc's AD bit, glibc must give guarantees that it will not serve data from untrusted servers (or exposes
> indication about trustability).
>
> To do that glibc needs to know that a server *is* indeed trusted. and looking at the nameserver field is obviously not sufficient, because no matter how
> ardently we desire so, common/existing configuration managers slap in random servers with no regard.
>
> So how do we indicate to glibc that a server is trusted in a way that applications can trust it and other commonly used resolver libraries (like c-ares for
> example) can learn to use ?
>
> We need a (positive) way to tell glibc, unequivocally, that the system is handled by a configuration manager (whether that is software or an admin manually
> setting configuration options doesn't matter) that is aware and know how to properly set the system for DNSSEC.
>
> The easiest mostr compatible way to tell glibc is by adding/changing an option in resolv.conf, an option not used by current existing configuration managers.
That still runs the risk of an outside program just reading all of resolv.conf and only changing the bits it wants changed, like nameserver entries, and copying
everything else blindly. So I don't think we can use /etc/resolv.conf for this. We need a file of which all consumers/modifiers know what they are doing.
> A situation in which glibc does not use an explicit configuration option to signal applications that it is using a trusted resolver is not useful ... no scratch
> that, it is actively harmful, because applications developers will quickly realize they cannot trust any information coming from glibc and will simply not use
> it for DNSSEC related information.
I think we have reached the point already where any program which does a serious amount of DNS lookups for crypto and other reasons, is not going to use glibc.
That's not a problem as long as we patch those needed patching to look at this new trusted nameserver configuration option.
Paul