F22 System Wide Change: Default Local DNS Resolver

[Tomas Hozza]

On 01/13/2015 08:56 PM, William B wrote:
>> To install a local DNS resolver trusted for the DNSSEC validation
>> running on 127.0.0.1:53. This must be the only name server entry
>> in /etc/resolv.conf.
> 
> .... snip ...
> 
>> People use Fedora on portable/mobile devices which are connected to
>> diverse networks as and when required. The automatic DNS
>> configurations provided by these networks are never trustworthy for
>> DNSSEC validation. As currently there is no way to establish such
>> trust.
> 
> 
> I have a number of concerns about the "readiness" of the proposal.
> 
> Right now, enabled unbound and dnssec-trigger on a laptop is an
> extremely difficult experience. I have since taking up this challenge
> found that turn it off and on again, has become the default solution on
> my linux install now as a result of these problems.

Personally I have completely different experience. I have unbound and dnssec-trigger
on by default and it works at home, on WiFi, at work, with VPN...

> For example, crashes in unbound that are not caught in abrt, forwarders
> that do not get added (but they display in the list), queries that
> don't ever get replies (But they work when you by-pass unbound to your
> glibc forwarder), inability to flush dnscache without sudo, and that
> dns caches are held over network boundaries to name a few of my
> concerns.

Did you file an issue to ABRT (or anywhere?)

As for the cache, are you able to do that with dnsmasq? Without sudo you
can't even change /etc/resolv.conf. I think we disagree on what should
non-privileged user should be allowed to do.

> As a result, at this time, enabling this on your system is actually
> more of a deteriment that the "benefit" being touted. I would prefer
> working DNS over non working "secure" dns. (I guess it's secure because
> I can send any traffic out).

Yes, without DNSSEC all the hackish network setups just work.

>> Apart from trust, these name servers are often known to be flaky and 
>> unreliable. Which only adds to the overall bad and at times even
>> frustrating user experience. In such a situation, having a trusted
>> local DNS resolver not only makes sense but is in fact badly needed.
>> It has become a need of the hour. (See: [1], [2], [3])
> 
> Unbound creates more flakiness than it solves. Unbound caches "no
> answer" as a negative cache entry. If your wireless blips for an
> instant, that's it, result vanishes.
> 
> 
> I think that there should be a large amount of QA focus on this change. 
> Configurations involving split-view dns should be involved in testing,
> testing stability of unbound between suspend/resume, or even
> NetworkManager restarts, testing that quieries resolve in esoteric
> networks (IE networks that capture and redirect DNS traffic).

We will be more than happy to receive any test cases and use-cases (with
steps to setup) and use them for testing the readiness of the Change.

However more than a relatively non-technical discussion about unclear
use-cases that we are unable to reproduce due to insufficient information,
we would welcome clear descriptions and clear statements describing
what specifically is not working as it should.

> This is a change, that currently, has the potential to seriously damage
> the user experience of anyone using fedora. I think that much more
> rigorous testing and thought should go into this before we just steam
> ahead. If in it's current state you install unbound, you will begin to
> notice little issues quickly, especially on laptops. That is not a
> defalt we should aim for.

We are willing to work on resolving user issues. If the change will be
proven not ready, we are ready to work on issues and deffer it to F23.

However from the past experience there is no way everyone will be happy
with the changes, regardless of what those changes are.

> NOTE: I'm not just raging here, I actually have opened BZ's for these
> issues that I have. I think that awareness of these issues is low, and
> that it should be brought to light. I hope that more thorough testing
> is carried out in a wider set of environments to eventually get this to
> a point where it's a seamless change to enable this service. However at
> this time, that is not the case.

We are thankful for your contributions in testing the setup. Hopefully
you recognize some of the improvements done based on your reports.

Regards,
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.                               http://cz.redhat.com