== Overview ==
Back at the beginning of the Fedora.next initiative when we created the
working groups, we tasked them with creating "Product Requirement
Documents" (PRDs) to guide the development of each of these core
More than a year has passed and the Fedora Council feels that it's a
good time to give another pass at these documents and re-align them,
both with the current reality and the next phase of this process.
Additionally, the Council feels that it would be good to perform such a
re-alignment and update each year.
This year, we have set an admittedly short deadline: the PRDs need to
be updated and ready for review on June 12th (11 days from now). In the
future, this will be scheduled further in advance and with more time to
address it (see below).
== What do we have to do? ==
There are two things that should be done during a PRD refresh exercise
(though their implementation is left as an exercise to the Working
1) Review the PRD for plans that are outdated. Some examples:
* Support for CPU architectures that no longer make sense
* Features that have been de-prioritized or indefinitely deferred
* References to technology that has been replaced or obsoleted
2) Add new plans and requirements for the evolving technology. Some
* Fedora Cloud commits to producing an implementation of the Nulecule
* Fedora Server commits to producing Server Roles that can be
migrated to a Fedora Atomic deployment
* Fedora Workstation integrates seamlessly with a self- or publicly
-hosted ownCloud deployment.
(Optional): The PRD review period may be an excellent time for those
WGs with persistent membership to evaluate whether it is time to
refresh the WG membership as well.
== Future PRD Refreshes ==
Starting at Flock 2016 (yes, *next* calendar year), each working group
will have a workshop scheduled at Flock to go over its PRD and plan for
the following year. Note: because Flock generally falls between Alpha
and Beta of a Fedora release, all PRD planning is presumed to be a
directive for Fedora N+1 and N+2 at that time, not retroactively
applied to the current release.
The workshops are expected to cover the majority of the update, and
then they will be brought back to the respective mailing lists for
further review before being due to the Council one month after Flock
= Proposed System Wide Change: Default Local DNS Resolver =
Change owner(s): P J P <pjp at fedoraproject.org>, Pavlix <pavlix at pavlix.net>, Tomas Hozza <thozza at redhat.com>, Petr Špaček <pspacek at redhat.com>
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 (e.g. this is stored in the NetworkManager internal state), 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: , , )
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: , , )
== Scope ==
* Proposal owners: Proposal owners shall have to
** define the syntax and semantics for new configuration parameters/files.
** properly document how to test and configure the new default setup
** persuade and coordinate with the other package owners to incorporate new changes/workflow in their applications.
** discuss with WGs in which products the change makes sense and what are the expectations of WGs for different Fedora products
** resolve interoperability issues for Docker and other containers use-cases
* Other developers: (especially NetworkManager and the likes)
** No new features/workflow should be needed from other applications, since the use of trusted local DNS resolver should be seamless.
** Ideally other developers and user should test their software and application in this setup and verify that it is working as expected
* 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.
** Add services needed for the setup into the default presets (dnssec-trigger and Unbound)
* Policies and guidelines:
** the chosen trusted DNS resolver package (Unbound) 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.