On Monday 14 December 2015 09:34:56 Paul Wouters wrote:
> On 12/12/2015 09:11 PM, Oron Peled wrote:
> > 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.
IMO, the question is not if I can do that (or others on Fedora-devel mailing list).
It's if we can have such a warning setup be the *default* for end-users in Fedora-24.
> > 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.
Good point, but that could be mitigated at both ends:
* The local DNS server can apply a "rate-limit" for these DBus signals.
* Also, the display don't have to use desktop "notifications".
Alternatively, it can be implemented as a single process that listen to
these signals and show one popup with minimal info (global warning,
with a possible list of latest problematic domains).
> > * 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.
Those DNS deployments are good for general DNSSEC technology validation.
They have nothing to do with the problem I pointed:
* They do not test the crazy DNS world *inside* NAT'ed networks.
* In these private networks is where most bad DNS setups exists.
* This is the environment that the new Fedora DNS setup will likely encounter.
factoid: In a medium corporation I know (few thousands desktops/servers across ~5 timezones),
they still use internal domains like "foobar.local" (which practically kill
great technologies like mDNS).
This is pretty obvious as "<something>.local" was considered *best-practice*
by some Microsoft Active Directory setups when this corporation was small.
> 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.
I agree, but still think doing it in *two steps* would be beneficial for both
Fedora and DNSSEC.
First make it default and analyze the backlash (which won't be fatal, as it's only warnings)
Than make it "enforcing" and force the pain (after you already have clear
notification mechanisms that are *familiar* to the end-users).
> > 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.
As I said -- "you" (or me) running it for some time is nothing like few million Fedora users.
My proposal does not "just postpone" -- Let's make it Fedora-24 default,
but *warn* about bad replies instead of *rejecting* them -- this would give us
valuable information.
> 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".
Hmmm... "easily solved" is not "solved":
* Has this "biggest issue" really been solved? Do we have this NM integration?
Does it show in "nm-applet" (I avoid bringing up KDE which I personally use,
or other desktops)
* What other issues we don't know, simply because this Fedora setup hasn't been *widely* deployed?
Thanks,
--
Oron Peled Voice: +972-4-8228492
oron@xxxxxxxxxxxx http://users.actcom.co.il/~oron
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
