F22 System Wide Change: Default Local DNS Resolver

[Jaroslav Reznik]

= Proposed System Wide Change: Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver

This Change was already proposed as Fedora 21 Change but moved to Fedora 22 
(and discussed as Fedora 22 Change), re-announcing it as more details were 
provided as requested by FESCo [0].

Change owner(s): P J P <pjp at fedoraproject.org>, Pavel Šimerda
<pavlix at pavlix.net>, Tomas Hozza <thozza at redhat.com>

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.

The automatic name server entries received via dhcp/vpn/wireless configurations 
should be stored separately, as transitory name servers to be used by the 
trusted local resolver. In all cases, DNSSEC validation will be done locally. 

== Detailed Description ==
There are growing instances of discussions and debates about the need for a 
trusted DNSSEC validating local resolver running on 127.0.0.1:53. There are 
multiple reasons for having such a resolver, importantly security & usability. 
Security & protection of user's privacy becomes paramount with the backdrop of 
the increasingly snooping governments and service providers world wide.

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.

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])

Going forward, as DNSSEC and IPv6 networks become more and more ubiquitous, 
having a trusted local DNS resolver will not only be imperative but be 
unavoidable. Because it will perform the most important operation of 
establishing trust between two parties.

All DNS literature strongly recommends it. And amongst all discussions and 
debates about issues involved in establishing such trust, it is unanimously 
agreed upon and accepted that having a trusted local DNS resolver is the best 
solution possible. It'll simplify and facilitate lot of other design decisions 
and application development in future. (See: [1], [2], [3])

People:
* Petr Spacek
* Paul Wouters
* Simo Sorce
* Dmitri Pal
* Carlos O'Donell

== Scope ==
Proposal owners: Proposal owners shall have to
* define the syntax and semantics for new configuration parameters/files. 
* persuade and coordinate with the other package owners to incorporate new 
changes/workflow in their applications.

Other developers: (especially NetworkManager and the likes)
*  would have to implement the new features/workflow for their applications 
adhering to the new configurations and assuming the availability of the trusted 
local DNS resolver.
* NetworkManager already has features & capability to support local DNS 
resolvers. Though few details are still under development, but are expected to 
realize in near future. Please see -> 
https://lists.fedoraproject.org/pipermail/devel/2014-April/197848.html

Release engineering: 
* would have to ensure that trusted local DNS resolver is available throughout 
the installation stage and the same is installed on all installations 
including LiveCDs etc.

Policies and guidelines: 
* the chosen trusted DNS resolver package(ex dnsmasq or dnssec-trigger etc.) 
would have to ensure that their DNS resolver starts at boot time and works out 
of the box without any user intervention.
* NetworkManager and others would have to be told to not tamper with the local 
nameserver entries in '/etc/resolv.conf' and save the dynamic nameserver 
entries in a separate configuration file.

[0] https://fedorahosted.org/fesco/ticket/1307
[1] https://www.ietf.org/mail-archive/web/dane/current/msg06469.html
[2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html
[3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html