You are not mistaken. This is the third time, because previously we rather moved the change to the next Fedora to bring better user experience. Every time there was something enhanced, since we learned a lot about user use-cases, so this is definitely not the same change as before, only the root idea is the same. The Change Wiki is up-to-date and contains the current information.
Also with many projects involved - Gnome Shell, NetworkManager, Unbound, dnssec-trigger, SELinux (always a pleasure:), Docker... it is not the easiest thing to agree on changes and coordinate everything on time. What changed from the top of my head: - We decided not to install the dnssec-trigger panel by default and rather better integrate dnssec-trigger with NM and Gnome Shell - We decided not to query user for security decisions, and for the beginning if there is no other option just fall back to the current state that that is in Fedora today - better handling of environments, where the resolvers on the network don't support DNSSEC by new Unbound plugin. This is still not in upstream, since we wanted to get the algorithm to the RFC draft that is currently discussed on IETF WG (http://www.ietf.org/id/draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt) - dnssec-trigger does not do the Captive Portal detection and handling and we rather rely on NM for the detection and on Gnome Shell for the Portal login - Some enhancements of the portal helper in Gnome Shell are being reviewed, (it will not rely on the resolv.conf content and rather use sandboxed environment with resolv.conf containing resolvers for the connection from NM). If you check the "decisions made" part of the change wiki, it discusses the important outcomes of discussions. Some of these things are not polished, implemented or merged upstream yet, but we are working on them with the F24 schedule in mind. We are also communicating with NM and Gnome devels and will discuss the defaults with WGs with some Product, once FESCo approves the change. Regards, Tomas On 01.12.2015 09:14, Vít Ondruch wrote: > If I am not mistaken, this is at least 3rd time this change is proposed. > Can somebody post some short summary what was changed, that you believe > it will be successful this time? > > Thx > > > Vít > > > Dne 30.11.2015 v 17:14 Jan Kurik napsal(a): > > = Default Local DNS Resolver = > > https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver > > > > Change owner(s): > > * P J P <pjp AT fedoraproject DOT org> > > * Pavel Šimerda <pavlix AT pavlix DOT net> > > * Tomas Hozza <thozza AT redhat DOT com> > > * Petr Špaček <pspacek AT redhat DOT com> > > > > Plain DNS protocol is insecure and therefore vulnerable from various > > attacks (e.g. cache poisoning). A client can never be sure that there > > is no man-in-the-middle, if it does not do the DNSSEC validation > > locally. > > We want to have Unbound server installed and running on localhost by > > default on Fedora systems. Where necessary, have also dnssec-trigger > > installed and running by default. Unbound and dnssec-trigger will be > > properly integrated with the default network configuration manager > > (e.g. NetworkManager for Fedora Server and Workstation) and with the > > graphical user interface (especially GNOME). The localhost address > > will be the only record in /etc/resolv.conf and no other software > > except dnssec-trigger will be allowed to change its content. > > > > > > > > == Detailed Description == > > Plain DNS protocol is insecure and therefore vulnerable from various > > attacks (e.g. cache poisoning). DNSSEC is a DNS extension which > > enabled the client to verify the DNS query response and make sure > > there is no attacker to spoof some records. A user connected to > > network usually receives a set of resolvers from DHCP, which should be > > used for name resolution. These resolvers may also do the DNSSEC > > validation. However a client can never be sure that there is no > > man-in-the-middle, if it does not do the DNSSEC validation locally. > > Purpose of this Fedora change is to have a validating DNS resolver > > installed on Fedora systems by default. This includes necessary > > discussions, coordination and integration with other components > > installed on Fedora by default. > > > > There are growing instances of discussions and debates about the need > > for a trusted local validating DNS resolver. There are multiple > > reasons for having such a resolver, most importantly security and > > usability. Security and 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 validating DNS resolver not only makes sense but is, in fact, > > badly needed. It has become a need of the hour. (See: [1], [2], [3]) > > > > All DNS literature strongly recommends it and amongst all discussions > > and debates about the 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 will simplify and > > facilitate a lot of other design decisions and application development > > in the future. (See: [1], [2], [3]) > > > > [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 > > > > > > > > == 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) > > * NetworkManager has to implement notifications on connectivity state > > changes > > * Gnome Shell has to use the connection provided resolvers (fetched > > directly from NM) for Hot-Spot login purposes > > * Ideally other developers and user should test their software and > > application in this setup and verify that it is working as expected > > > > Release engineering: > > * Make sure that the necessary packages (dnssec-trigger, unbound) are > > part of the composes for the appropriate Fedora Products. > > * Add services needed for the setup into the default presets > > (dnssec-triggerd.service) > > > > Policies and guidelines: > > * Any software, including NetworkManager, will have to be configured > > to not tamper with the content of '/etc/resolv.conf' by default. The > > connection-provided resolver entries should be stored in a separate > > configuration file or in memory and accessible via some API. > > > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D UTC+1 (CET) Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
