Re: F24 System Wide Change: Default Local DNS Resolver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/12/2015 09:11 PM, Oron Peled wrote:
> On Friday 11 December 2015 09:09:28 Paul Wouters wrote:
>> On 12/09/2015 06:02 PM, Oron Peled wrote:
>>> Why don't we plan this feature in two stages:
>>>  * Fedora 24: turn it on by default, but *keep using results* from bad DNS servers,
>>>    just issue a user-visible warning, possibly with a link to a page with friendly
>>>    explanation and suggestions for further action.
> 
> I'll answer both Paul and Reindl which replied "there's no safe and clean way to solve that"...
> 
>> DNS lookups don't have users like web browsers.
> 
> First, that's only partially correct:
>  * The client (resolver) normally *does* have a user (the uid of the process calling the resolver library).
>  * But after that, your are correct that the caller identity is gone.
> 
> Still, IMO, the goal to warn users can be achieved quite easily. Two examples from the top of my head.
> 1. log + notify:
>    * The information may be logged with special prefix (or special field via sd-journal).
>    * Users would have a small desktop service that would monitor for these messages and notify about them.

You can do that logging using tools like dnssec-system-tray pointing to the unbound log file.

> 2. dbus:
>    * The local DNS server would send specific DBUS signal (e.g: net.dnsseq.InsecureDNSReply).
>    * A desktop process would listen on these signals and show proper desktop notification.

But these solutions can quickly become a denial of service through popups.

>> I have been running this setup since Fedora 17. Breakage is not that bad.
> 
> Hmmm... even if all of us, fedora-devel subscribers, would run this
> it's still a far cry from a full release cycle of Fedora:

the problem with bad DNS deployments is that it keeps becoming a bigger house of cards until
it actually fails to work, similarly how raided disks that write a log message that one of the
two disks is failing usually gets found when the second disk failed.

>    * large-numbers: millions of machines would reveal much more varied use-cases
>      than what a 500-1000 machines of "fedora-devel" people can show.

google dns, verisign dns and many large DNS deployments already validate and break setups of
people using 8.8.8.8 manually. We've gone out of our way to try and be nice to existing DNS
deployments, but at some point you got to treat the wound, cause some pain and fix things.

> So my hunch feeling is still: make F24 with DNSSEC by default, but not
> "enforcing". Than, F25 will enforce DNSSEC validation.

That just postpones the hurt for 6 months. We've already had a few of these cycles. As I said,
I run this since fedora 17.

Really, the biggest issue people fear is their split view DNS. Which is easilly solved by extending
the concept of firewalld zones into Network Manager, and always use broken DNS forwarders on
"trusted networks".

Paul
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux