On Monday, November 30, 2015 01:50:54 PM Russell Doty wrote: > Is DNS by itself sufficient, or should we also address other network > facing capabilities with security impact such as secure time? The use case for the dnscache_test is to look for evidence of a system trying to reach a known Command and Control system. This would indicate that the server has malware on it. I believe that examining DNS cache by itself is sufficient. -Steve > 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
