----- Original Message -----
= Proposed System Wide Change: Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Change owner(s): P J P <pjp(a)fedoraproject.org>, Pavel Šimerda
<pavlix(a)pavlix.net>, Tomas Hozza <thozza(a)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.
Jaroslav
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 &
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 [4]
* 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.
[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
[4]
https://lists.fedoraproject.org/pipermail/devel/2014-April/197848.html
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce