Re: F24 System Wide Change: Default Local DNS Resolver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux