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(a)actcom.co.il
http://users.actcom.co.il/~oron
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor