F21 System Wide Change: Default Local DNS Resolver
jreznik at redhat.com
Tue Apr 29 20:13:39 UTC 2014
----- Original Message -----
> = Proposed System Wide Change: Default Local DNS Resolver =
> Change owner(s): P J P <pjp at fedoraproject.org>, Pavel Šimerda
> <pavlix at pavlix.net>, Tomas Hozza <thozza at redhat.com>
Ops, I was just pinged by Pavlix that the team planned this Change for F22 time-
frame but I still live in the flood of F21 Changes and missed it.
So the current state is - this Change targets Fedora 22 but most of the
development should land into Fedora 21 - not enabled by default - to get
test coverage. To make sure this Change is in the state it could be shipped
in the release as default, corner cases has to be identified and worked on,
there's also NetworkManager integration that has to happen.
I'm sorry for confusion.
> 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.
> This change was submitted after the Submission deadline.
> == 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 &
> Security & protection of user's privacy becomes paramount with the backdrop
> 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
> 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: , , )
> 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
> and application development in future. (See: , , )
> * 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
> realize in near future. Please see 
> * 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
> 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
> entries in a separate configuration file.
>  https://www.ietf.org/mail-archive/web/dane/current/msg06469.html
>  https://www.ietf.org/mail-archive/web/dane/current/msg06658.html
>  https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html
>  https://lists.fedoraproject.org/pipermail/devel/2014-April/197848.html
> devel-announce mailing list
> devel-announce at lists.fedoraproject.org
More information about the devel