F23 System Wide Change: Default Local DNS Resolver

[Reindl Harald]

Am 01.06.2015 um 22:57 schrieb Andrew Lutomirski:
> On Mon, Jun 1, 2015 at 1:42 PM, drago01 <drago01 at gmail.com> wrote:
>> On Mon, Jun 1, 2015 at 9:28 PM, Andrew Lutomirski <luto at mit.edu> wrote:
>>> I agree it's not essential for a server, but it can be quite helpful
>>> to work around glibc bugs.  For example, I've hit
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=17802 several times in
>>> production.  Yes, that's a glibc bug, and glibc should fix it.
>>> Nonetheless, bugs like that wouldn't matter as much if there were a
>>> local resolver.
>>
>> That's not how bugs should be dealt with ... if there is a bug it
>> should be fixed where it is not duct taped this way.
>
> This is glibc we're talking about, though.  Have you tried to get a
> glibc bug fixed?  It's not a pleasant experience.

and hence you prefer put your head in the sand and burry it by anotehr 
layer increasing complexity?

> For example, the bug I reported has a candidate patch.  That patch
> isn't applied, and the patch looks like the bug might be a security
> issue.  It's been in that state for months.  This is not unusual for
> glibc.

that don't justify a local resolver on hundrets of servers as default to 
hide a bug somewhere else and frankly if that problem would affect 
naybody i would have faced it in the past 10 years but i did not

> Anyway, even on a LAN, the overhead of a network round trip per
> cacheable DNS query may be non-negligable for some use cases.  A local
> caching resolver fixes that, too

and here you go: because a change is fine for *some use cases* is not a 
justification for introduce an *additional* layer for a default setup

the strategy wrap layers over layers to mask something going wrong in 
the 5 layers below and if there is a problem somewhere two weeks later 
wrap anotehr 2 layers on top to mask the current outbreak in the 
"modern" system development is nothing else than stupidty resulting in 
each years complexer systems where *nobody* knows what they are doing 
and which component is really responsible if things are going wrong

congratulations - maybe if we follow that paradigms often and fast 
enough the whole ecosystem is ruined in a non reveratble way that it 
needs to rebuilt from scratch instead rwap anotehr 10 layers with 9 
minor problems around

a sane system should be as simple as possible so that *one* human is 
able to determine what is happening without hire 10 specialists for each 
layer

in short: leave me in peace with defaults raising complexity more and 
more, i have enough with dbus, a now essential service which cant be 
restarted after updates of underlying libraries while it was no problem 
over many years to type "chkconfig messagebus off" on servers and have 
no single process except the services you installed and configured

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150601/3c4f9e54/attachment.sig>