On 12/14/2015 04:26 PM, Oron Peled wrote: >>> 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).
All these dnssec validation errors would be equally invisible if the system used 8.8.8.8 because google would also ServFail these since they do DNSSEC. > 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. The only simple solution here is the "trusted network zone" where the user explicitly states they trust their local server. This is something NetworkManager should expose to the user - possibly on first connect. > 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. I have no problem breaking those kind of setups. >> 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). 20 years of DNS has taught me no one ever fixes any DNS until it is causing an outage. > 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. People will click away the warnings until they upgrade to F-25. >> 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? I don't know. I don't think the integration with firewalld/NM uses the same concept of "zones". > 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? I'd be more sympathetic to this if we haven't gone through major things like /usr move already :P Paul -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
