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: Zack Weinberg <zackw at panix dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 18 Nov 2015 22:53: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> <56429E2A dot 7050208 at panix dot com> <20151114172504 dot GI3818 at brightrain dot aerifal dot cx> <564A805B dot 4090103 at panix dot com> <564C32DD dot 8030703 at redhat dot com>
On 11/18/2015 03:12 AM, Florian Weimer wrote:
> On 11/17/2015 02:18 AM, Zack Weinberg wrote:
>
>> Don't you see that the entire rest of this thread demonstrates that
>> trying to eliminate all the "broken things distros and dhcp client
>> software are doing" is a lost cause?
>
> But there is no quick way around cleaning up this mess. If we just slap
> on a band-aid, eventually all software that writes /etc/resolv.conf
> today will learn about it (whether the band-aid is a new file, or an
> option in an existing file) and do things that break the configured
> security policy of the system. I don't know if it takes one year or
> three years, but it will happen.
To me this sounds like you are saying "Not only is /etc/resolv.conf a
lost cause, so is everywhere else we could possibly put DNSSEC
configuration; no matter where it is, network management software will
screw with it."
Whereas it seems to me that existing files other than /etc/resolv.conf
(such as nsswitch.conf and nscd.conf) do not have a history of being
screwed with by network management software, and therefore, perhaps,
there is a better chance of being able to say "no, only the sysadmin
touches that one" and have it stick.
zw