Re: Building consensus over DNSSEC enhancements to glibc.

[Florian Weimer <fweimer at redhat dot com>]

On 11/19/2015 04:53 AM, Zack Weinberg wrote:
> 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."

Such software exists, but these programs usually touch those files only
once to connect the system to centralized account management etc.  I
wouldn't be surprised if there are tools to switch between different
Windows Active Directory domains, but they are certainly not as
widespread as VPN software.

> 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.

Manipulation of routing tables and iptables is also extremely common.
Basically, these programs will do *anything* to get the job done, and do
only very limited interoperability testing.

I expect that if a missing AD bit causes things to break, these programs
will do the simplest possible thing to add it back.

Florian