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: Paul Wouters <pwouters at redhat dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Simo Sorce <simo at redhat dot com>, Petr Spacek <pspacek at redhat dot com>, libc-alpha at sourceware dot org
- Date: Tue, 17 Nov 2015 21:04:28 -0500
- Subject: Re: Building consensus over DNSSEC enhancements to glibc.
- Authentication-results: sourceware.org; auth=none
- References: <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> <564AE333 dot 9090200 at redhat dot com> <564B7A42 dot 6050603 at redhat dot com> <564BD6E6 dot 5040506 at redhat dot com>
On Wed, Nov 18, 2015 at 10:39:50AM +0900, Paul Wouters wrote:
> On 11/18/2015 04:04 AM, Carlos O'Donell wrote:
>
> >>> 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.
> >
> > Thanks for bringing that up again.
> >
> > So I am willing to concede flipping the meaning of (b) and defaulting
> > to always stripping AD-bit if that means we have consensus for a way
> > forward.
> >
> > I have background work in the Nuclear industry in Canada and I know
> > what fail safe means and the value it provides. Both from a certification
> > *and* usability perspective.
>
> That would work for me. Thanks Carlos.
>
> I don't think we then have a use for a) anymore unless that
> mechanism could somehow be extended to be configured - eg if a user
> uses NM to mark a wifi network as "trusted" that it would then
> somehow be able to add the network's nameservers IP's to the
> "trusted" set.
Obviously glibc can't set policy for NetworkManager, but I do not
think NM should offer such functionality; it's inherently unsafe. I
would almost say we should go so far as ignoring any 'trusted' flag
unless the only nameserver is 127.0.0.1, but I can imagine valid
setups where a virtual network interface with a different address is
used to route queries to a particular server on the same physical
host.
Rich