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: "Carlos O'Donell" <carlos at redhat dot com>, Rich Felker <dalias at libc dot org>, Simo Sorce <simo at redhat dot com>
- Cc: Petr Spacek <pspacek at redhat dot com>, libc-alpha at sourceware dot org
- Date: Tue, 17 Nov 2015 17:20:03 +0900
- Subject: Re: Building consensus over DNSSEC enhancements to glibc.
- Authentication-results: sourceware.org; auth=none
- References: <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> <5649A3F3 dot 2060309 at redhat dot com> <20151116161642 dot GQ3818 at brightrain dot aerifal dot cx> <564A0FED dot 9010408 at redhat dot com> <20151116181740 dot GS3818 at brightrain dot aerifal dot cx> <564A1E3E dot 5090703 at redhat dot com> <20151116182322 dot GU3818 at brightrain dot aerifal dot cx> <564AB3F9 dot 4020404 at redhat dot com> <564AC146 dot 1040305 at redhat dot com> <564AD51D dot 4040100 at redhat dot com>
On 11/17/2015 04:19 PM, Carlos O'Donell wrote:
>> If that is the only API to be offered, I recommend we patch the
>> applications with the "postfix method" instead and for now limit
>> ourselves with dnssec only if localhost is specified in resolv.conf.
>
> Why? It will never be enough to guarantee what you want. Such a check
> is only a heuristic.
>
> If you want something more sane we could make a synthetic hwcap bit
> like we did for Xen's "nosegneg" and use that to alter the behaviour
> of the stub resolver. This gives you something which would allow you
> to lock down the called recursive resolver from the very first userspace
> process. It could also be disabled on a per-process basis if you had
> a kernel interface for it. We have also had a thread local storage
> synthetic hwcap bit when we transitioned to using that feature, so
> there is some precedent.
>
> So you'd have:
>
> (a) New synthetic hwcap bit "local-validating-resolver" which forces
> glibc to only talk to 127.0.0.1 from the very first userspace process.
>
> (b) New options flag "dns-strip-dnssec-ad-bit" which forces glibc to
> remove AD-bit data.
>
> Mix-and-match.
That still does not do fail safe.
Paul