Is DNS by itself sufficient, or should we also address other network facing capabilities with security impact such as secure time?
On Mon, 2015-11-30 at 17:14 +0100, Jan Kurik wrote: > = 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
