From Fedora Project Wiki
 
(33 intermediate revisions by 7 users not shown)
Line 2: Line 2:


== Summary ==
== Summary ==
To 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.
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.


== Owner ==
== Owner ==
Line 20: Line 21:


== Current status ==
== Current status ==
* Targeted release: [[Releases/23 | Fedora 23 ]]  
* Targeted release: [[Releases/24 | Fedora 24 ]]  
* Last updated: 2015-05-28
* Last updated: 2015-12-02
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
Bugzilla states meaning as usual:
Bugzilla states meaning as usual:
Line 31: Line 32:
-->
-->
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1182488 #1182488]
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1182488 #1182488]
* Progress is tracked in Taiga: http://taiga.fedorainfracloud.org/project/thozza-default-dns-resolver/


== Detailed Description ==
== 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.
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.


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: [1], [2], [3])
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.


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.
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.


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: [1], [2], [3])
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])


* '''People:-'''
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])
** Petr Spacek
** Paul Wouters
** Simo Sorce
** Dmitri Pal
** Carlos O'Donell


---<br/>
---<br/>
Line 54: Line 50:
[2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html<br/>
[2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html<br/>
[3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html
[3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html
=== Decisions made based on discussion between change owners, Gnome and NetworkManager developers ===
# dnssec-trigger will not do any Hot-Spot detection
# dnssec-trigger panel will not be installed by default on Fedora Workstation
# if dnssec-trigger determines that the connection provided resolvers are not usable for DNSSEC validation, it is not able to do the full recursion and it is not able to tunnel the communication over SSL, then it automatically switches to the "non-validating" mode. '''This is not to break user experience with name resolution and rather fall back to the state, which is basically the actual state in default installation of Fedora 23 or older -> no DNSSEC validation.''' This will be the default behavior - but configurable. The insecure mode will be implemented using one of these approaches:
## resolv.conf's content will be modified to contain connection provided resolvers
## Unbound will not do the validation for the necessary time. '''In this mode Unbound will NOT set the AD bit in the DNS response.'''
# Hot-Spot detection is done only by NetworkManager
# NetworkManager should be able to notify services (dnssec-trigger) via dispatcher or some other means, on any connectivity state change (This part is yet to be sorted out with NM developers)
# Hot-Spot login is handled by Gnome
# Gnome uses the connection provided DNS resolvers instead of the ones in resolv.conf for Hot-Spot login purposes.


== Benefit to Fedora ==
== Benefit to Fedora ==
'''What is the benefit to the platform?'''  <!-- If this is a major capability update, what has changed?  If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?-->
'''What is the benefit to the platform?'''  <!-- If this is a major capability update, what has changed?  If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?-->


Fedora distribution has been the industry leader when it comes to shipping the best and latest of the software to its users. In many cases Fedora has been the trend setter in accepting new technologies like Systemd. With the '''trusted''' local DNS resolver running on 127.0.0.1:53, Fedora will not only provide greater security and usability to its users, but will also take an '''important step''' towards the '''secure by default''' computing future. Wherein users do not have to worry about privacy, security and trust.
Fedora distribution has been the industry leader when it comes to shipping the best and latest software to its users. In many cases Fedora has been the trend setter in accepting new technologies like Systemd. With having a '''trusted''' local validating DNS resolver, Fedora will not only provide greater security and usability to its users, but will also take an '''important step''' towards the '''secure by default''' computing future, wherein users do not have to worry about privacy, security and trust.
 
'''Specific benefits:'''
* Improved security when using Internet services, thanks to local DNSSEC validation
* User and applications will be able to trust the AD bit set in the DNS answer.
* Existence of system-wide DNS cache (in Unbound server) will speed up the resolution of frequent domain names and in general will save network traffic.
* Have a real split-DNS configuration - e.g. forward only specific DNS queries to the VPN-provided resolvers.


== Scope ==
== Scope ==
Line 69: Line 83:


* Other developers: (especially NetworkManager and the likes)
* 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.
** 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
** Ideally other developers and user should test their software and application in this setup and verify that it is working as expected


* Release engineering:
* 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.
** 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-trigger and Unbound)
** Add services needed for the setup into the default presets (dnssec-triggerd.service)


* Policies and guidelines:  
* 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.
** 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.
** 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.


== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==
As long as the new packages, which do the Network and DNS configurations are installed and they know about the local DNS resolver; None of the other packages need any changes. Because they'll continue to access name servers in '/etc/resolv.conf'.
 
* Any packages directly modifying the content of /etc/resolv.conf will not be able to modify the content any more. The software should notify about the changes the default network configuration management software (e.g. NetworkManager), rather than do the changes directly.
* Any packages that use the system name resolution libraries should continue to work without any problems, as the name resolution library usually use the resolvers listed in '/etc/resolv.conf'.
 
=== Search domains in resolv.conf ===
 
Domain search list supplied by DHCP can not be trusted and therefore it is ignored. If you need some search domains to be set in <code>/etc/resolv.conf</code>, you have to use the '''search''' option in <code>/etc/dnssec-trigger/dnssec-trigger.conf</code>.
 
The reasoning is that any DHCP server can send you any search domains list (and this can be even intercepted by an attacker, because DHCP is not secure) and it would make your traffic to go elsewhere for domain names that are not FQDN.
 
This means that users will not see the DHCP provided search domains in the <code>/etc/resolv.conf</code> as they did before.


=== Docker ===
=== Docker ===
Docker and other users of network namespaces, like systemd-nspawn, would break. When docker runs, it picks up the current '/etc/resolv.conf' and puts it in the container. But the container itself runs in a network namespace, so it gets its own loop-back device. This means 127.0.0.1:53 points to the container itself, not the host. So DNS resolving in the container will not work. [https://lists.fedoraproject.org/pipermail/devel/2014-April/198706.html -> https://lists.fedoraproject.org/pipermail/devel/2014-April/198706.html]


Docker and containers could be able to use host's DNSSEC resolver via a dedicated interface and iptables(8) rules. Though such configurations need to be investigated for their feasibility. Please see:
Docker and other users of network namespaces, like systemd-nspawn, would break. When docker runs, it picks up the current '/etc/resolv.conf' and puts it in the container. '''Currently Docker would work with the local DNS resolver, but would not use it.''' When /etc/resolv.conf contains the localhost address, Docker ignores it and rather puts the Google's DNS resolvers (8.8.8.8 and 8.8.4.4) into the containers's resolv.conf.
 
Docker and containers could be able to use host's DNSSEC resolver via a dedicated interface and iptables(8) rules, though such configurations need to be investigated for their feasibility. Please see:


* [https://bugzilla.redhat.com/show_bug.cgi?id=1258350 Bug #1258350]
* [https://github.com/docker/docker/issues/6388 https://github.com/docker/docker/issues/6388]
* [https://github.com/docker/docker/issues/6388 https://github.com/docker/docker/issues/6388]
* [https://www.piratepad.ca/p/dnssec-requisites-configurations https://www.piratepad.ca/p/dnssec-requisites-configurations]
* [https://www.piratepad.ca/p/dnssec-requisites-configurations https://www.piratepad.ca/p/dnssec-requisites-configurations]
==== Docker & iptables(8) ====
Docker server creates a virtual bridge interface - '''docker0''' - as a link between containers and the host. When docker starts a container, it creates two network interfaces each bound to the '''docker0''' bridge. At one end of the 'docker0' bridge is the container's '''eth0''' interface and at the other end is '''veth*''' interface on the host. Ie. all network traffic from containers passes through the '''docker0''' bridge. [https://docs.docker.com/articles/networking/ -> https://docs.docker.com/articles/networking/]
For container applications to take advantage of the DNSSEC resolver on the host, we need to divert DNS traffic from '''docker0''' interface to the local '''lo''' interface on the host. This can be accomplished by following these steps:
* Enable local '''lo''' routing via '''docker0''' bridge interface. (it is '''off''' by default)
  $ sysctl -w net.ipv4.conf.docker0.route_localnet=1
* Enable unbound(8) server to accept requests from 172.17.0.0/16 docker sub-network.
  $ vi /etc/unbound/unbound.conf -> access-control: 172.17.0.0/16 allow
* Use iptables(8) destination nat(DNAT) feature to divert DNS traffic from '''docker0''' to '''lo''' interface
  $ iptables -t nat -I PREROUTING -p UDP -s 172.17.0.0/16 --dport 53 -i docker0 -j DNAT --to-destination 127.0.0.1:53
=== Hot-Spot detection ===
Based on previous discussion with GNOME and NetworkManager developers we agreed, that NetworkManager will be the only one doing the Hot-Spot detection and that the Hot-Spot detection functionality in dnssec-trigger will be turned off by default (until network connectivity state change notifications are implemented in NM, only in Fedora Workstation).
=== Hot-Spot login ===
Based on previous discussion with GNOME developers, on Fedora Workstation, the Hot-Spot login is handled only by Gnome Shell and the Hot-Spot login functionality in dnssec-trigger is disabled.
=== dnssec-trigger panel ===
dnssec-trigger panel is not installed by default any more. For spins / products that don't have their own way of handling the Hot-Spot login, the dnssec-trigger panel should be added to the kickstart / compose.


== How To Test ==
== How To Test ==
=== Expectations ===
=== Expectations ===
Everything should work as usual, out of the box. You should be (automatically) protected when visiting DNSSEC-secured DNS domains.


DNSSEC-secured DNS domains which fail the validation (e.g. because you are under DNS spoofing attack) should be unreachable.
Ideally everything should work as usual, out of the box. Responses for DNSSEC-protected domains will be validated automatically. In case the validation fails for DNSSEC-protected domain (e.g. due to misconfiguration or some ongoing attack) it will stop working.


You can use http://dnsviz.net/ service to finding out if there is any problem with the domain.
Site http://www.dnssec-failed.org/ has intentionally invalid DNSSEC signatures to simulate an attack. The site should not be reachable if your configuration is correct.
Site http://www.dnssec-failed.org/ has intentionally invalid DNSSEC signatures to simulate an attack. The site should not be reachable if your configuration is correct.


=== Option 1 - Use experimental implementation available in Fedora 20 ===
=== How to get Unbound and dnssec-trigger running? ===
 
* Install dnssec-trigger daemon:
$ sudo dnf install dnssec-trigger
 
* If you use NetworkManager, configure it to use unbound. Add the following line into /etc/NetworkManager/NetworkManager.conf
dns=unbound


* Install and enable dnssec-trigger daemon:
* Enable and start dnssec-trigger
$ sudo yum install dnssec-trigger
  $ sudo systemctl enable dnssec-triggerd.service
  $ sudo systemctl enable dnssec-triggerd.service
$
 
 
  $ # disable and stop any existing DNS service, e.g., dnsmasq
  $ # disable and stop any existing DNS service, e.g., dnsmasq
  $ sudo systemctl start dnssec-triggerd.service
  $ sudo systemctl start dnssec-triggerd.service
Line 110: Line 172:
* Now it should ''just work''. Please file a bug against [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=dnssec-trigger dnssec-trigger component in Fedora] if it doesn't.
* Now it should ''just work''. Please file a bug against [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=dnssec-trigger dnssec-trigger component in Fedora] if it doesn't.


* Validation failues should be recorded to the system log:
* Validation failures should be recorded to the system log:
  journalctl -f -l -u unbound.service
  journalctl -f -l -u unbound.service
  unbound[1062]: [1062:0] info: validation failure <www.dnssec-failed.org. A IN
  unbound[1062]: [1062:0] info: validation failure <www.dnssec-failed.org. A IN
Line 117: Line 179:
* See dnssec-trigger documentation for more details: http://www.nlnetlabs.nl/projects/dnssec-trigger/
* See dnssec-trigger documentation for more details: http://www.nlnetlabs.nl/projects/dnssec-trigger/


=== Option 2 - Configure local resolver manually ===
== User Experience ==
* Make sure local DNS resolver (e.g. unbound or BIND) is running on 127.0.0.1:53.
* Make sure it is the only name server entry in /etc/resolv.conf.
* Make sure that DNSSEC validation is enabled on your resolver.
* Make sure that applications are able to resolve domain names with such setup. (Try browsing few sites on the Internet.)
* Add domain specific name server entries (aka ''forwards'') into local name server's configuration file and ensure that applications are able to resolve internal (company wide) domain names too. (Try connecting to company mail/IRC server.)
* Make sure that NetworkManager/vpnc/dhcp etc. programs do NOT tamper with the primary name server entry in /etc/resolv.conf.
* If NetworkManager is not used, dnssec-trigger seamlessly handles lot of its responsibilities for '''unbound''' server. Other decent DNS servers should also have their means to accept domain specific name servers(forwarders) via DHCP/VPNC/WiFi etc.


== User Experience ==
The change is something the user should ideally not even notice, however the experience may change for misconfigured domains.
It is not something user would notice really.


Note: There's a [https://labs.nic.cz/page/1253/dnssec-validator-2.0-pro-webove-prohlizece/ DNSSEC/TLSA validator] for Firefox (and some other browsers) developed by CZ.NIC Labs.
Note: There's a [https://labs.nic.cz/page/1253/dnssec-validator-2.0-pro-webove-prohlizece/ DNSSEC/TLSA validator] for Firefox (and some other browsers) developed by CZ.NIC Labs.
Line 134: Line 188:


== Dependencies ==
== Dependencies ==
* N/A
* Changes in Docker
* Changes in NetworkManager
* Changes in Gnome Shell
* Changes in default presets and products kickstarts


== Contingency Plan ==
== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?)
* Contingency mechanism: (What to do?  Who will do it?)
** At the minimum, if we only manage to install a local DNS resolver and enable it to run at boot up and configure it to be the primary name server in /etc/resolv.conf, we will be in the safe. Because other applications won't notice any change as long as they are able to resolve domain names.
** Release Engineers will have to reverse all the changes done to default presets and kickstart files, so that Unbound and dnssec-trigger won't be installed and enabled by default in Fedora Products.
** If NetworkManager/dhcp/vpnc etc. are not able to incorporate new syntax/semantic changes, worst case, they'll continue to over-write the name server configuration in /etc/resolv.conf, even in that scenario, user/application won't notice any difference for they will continue to be able to resolve domain names and access internet.
** Only drawback would be that it won't be as safe as using the '''trusted''' local resolver.


<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
Line 147: Line 202:


* Blocks release? - No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? - No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks product? product - No <!-- Applicable for Changes that blocks specific product release/Fedora.next -->
* Blocks product? product - No <!-- Applicable for Changes that block specific product release/Fedora.next -->


== Documentation ==
== Documentation ==
<!-- Is there upstream documentation on this change, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
<!-- Is there upstream documentation on this change, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* https://fedoraproject.org/wiki/Networking/NameResolution/DNSSEC
For more information on name resolution, DNS and DNSSEC, please check:
 
* [[Networking/NameResolution]]
* [[Networking/NameResolution/DNS]]
* [[Networking/NameResolution/DNSSEC]]
* [[Networking/NameResolution/DNSSEC/Design]]


== Release Notes ==
== Release Notes ==
Line 161: Line 221:
-->
-->


[[Category:ChangeAnnounced]]
[[Category:ChangePageIncomplete]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->

Latest revision as of 11:23, 10 December 2015

Default Local DNS Resolver

Summary

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.

Owner

  • Release notes owner:

Current status

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

Decisions made based on discussion between change owners, Gnome and NetworkManager developers

  1. dnssec-trigger will not do any Hot-Spot detection
  2. dnssec-trigger panel will not be installed by default on Fedora Workstation
  3. if dnssec-trigger determines that the connection provided resolvers are not usable for DNSSEC validation, it is not able to do the full recursion and it is not able to tunnel the communication over SSL, then it automatically switches to the "non-validating" mode. This is not to break user experience with name resolution and rather fall back to the state, which is basically the actual state in default installation of Fedora 23 or older -> no DNSSEC validation. This will be the default behavior - but configurable. The insecure mode will be implemented using one of these approaches:
    1. resolv.conf's content will be modified to contain connection provided resolvers
    2. Unbound will not do the validation for the necessary time. In this mode Unbound will NOT set the AD bit in the DNS response.
  4. Hot-Spot detection is done only by NetworkManager
  5. NetworkManager should be able to notify services (dnssec-trigger) via dispatcher or some other means, on any connectivity state change (This part is yet to be sorted out with NM developers)
  6. Hot-Spot login is handled by Gnome
  7. Gnome uses the connection provided DNS resolvers instead of the ones in resolv.conf for Hot-Spot login purposes.

Benefit to Fedora

What is the benefit to the platform?

Fedora distribution has been the industry leader when it comes to shipping the best and latest software to its users. In many cases Fedora has been the trend setter in accepting new technologies like Systemd. With having a trusted local validating DNS resolver, Fedora will not only provide greater security and usability to its users, but will also take an important step towards the secure by default computing future, wherein users do not have to worry about privacy, security and trust.

Specific benefits:

  • Improved security when using Internet services, thanks to local DNSSEC validation
  • User and applications will be able to trust the AD bit set in the DNS answer.
  • Existence of system-wide DNS cache (in Unbound server) will speed up the resolution of frequent domain names and in general will save network traffic.
  • Have a real split-DNS configuration - e.g. forward only specific DNS queries to the VPN-provided resolvers.

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.

Upgrade/compatibility impact

  • Any packages directly modifying the content of /etc/resolv.conf will not be able to modify the content any more. The software should notify about the changes the default network configuration management software (e.g. NetworkManager), rather than do the changes directly.
  • Any packages that use the system name resolution libraries should continue to work without any problems, as the name resolution library usually use the resolvers listed in '/etc/resolv.conf'.

Search domains in resolv.conf

Domain search list supplied by DHCP can not be trusted and therefore it is ignored. If you need some search domains to be set in /etc/resolv.conf, you have to use the search option in /etc/dnssec-trigger/dnssec-trigger.conf.

The reasoning is that any DHCP server can send you any search domains list (and this can be even intercepted by an attacker, because DHCP is not secure) and it would make your traffic to go elsewhere for domain names that are not FQDN.

This means that users will not see the DHCP provided search domains in the /etc/resolv.conf as they did before.

Docker

Docker and other users of network namespaces, like systemd-nspawn, would break. When docker runs, it picks up the current '/etc/resolv.conf' and puts it in the container. Currently Docker would work with the local DNS resolver, but would not use it. When /etc/resolv.conf contains the localhost address, Docker ignores it and rather puts the Google's DNS resolvers (8.8.8.8 and 8.8.4.4) into the containers's resolv.conf.

Docker and containers could be able to use host's DNSSEC resolver via a dedicated interface and iptables(8) rules, though such configurations need to be investigated for their feasibility. Please see:

Docker & iptables(8)

Docker server creates a virtual bridge interface - docker0 - as a link between containers and the host. When docker starts a container, it creates two network interfaces each bound to the docker0 bridge. At one end of the 'docker0' bridge is the container's eth0 interface and at the other end is veth* interface on the host. Ie. all network traffic from containers passes through the docker0 bridge. -> https://docs.docker.com/articles/networking/

For container applications to take advantage of the DNSSEC resolver on the host, we need to divert DNS traffic from docker0 interface to the local lo interface on the host. This can be accomplished by following these steps:

  • Enable local lo routing via docker0 bridge interface. (it is off by default)
 $ sysctl -w net.ipv4.conf.docker0.route_localnet=1
  • Enable unbound(8) server to accept requests from 172.17.0.0/16 docker sub-network.
 $ vi /etc/unbound/unbound.conf -> access-control: 172.17.0.0/16 allow
  • Use iptables(8) destination nat(DNAT) feature to divert DNS traffic from docker0 to lo interface
 $ iptables -t nat -I PREROUTING -p UDP -s 172.17.0.0/16 --dport 53 -i docker0 -j DNAT --to-destination 127.0.0.1:53

Hot-Spot detection

Based on previous discussion with GNOME and NetworkManager developers we agreed, that NetworkManager will be the only one doing the Hot-Spot detection and that the Hot-Spot detection functionality in dnssec-trigger will be turned off by default (until network connectivity state change notifications are implemented in NM, only in Fedora Workstation).

Hot-Spot login

Based on previous discussion with GNOME developers, on Fedora Workstation, the Hot-Spot login is handled only by Gnome Shell and the Hot-Spot login functionality in dnssec-trigger is disabled.

dnssec-trigger panel

dnssec-trigger panel is not installed by default any more. For spins / products that don't have their own way of handling the Hot-Spot login, the dnssec-trigger panel should be added to the kickstart / compose.

How To Test

Expectations

Ideally everything should work as usual, out of the box. Responses for DNSSEC-protected domains will be validated automatically. In case the validation fails for DNSSEC-protected domain (e.g. due to misconfiguration or some ongoing attack) it will stop working.

You can use http://dnsviz.net/ service to finding out if there is any problem with the domain. Site http://www.dnssec-failed.org/ has intentionally invalid DNSSEC signatures to simulate an attack. The site should not be reachable if your configuration is correct.

How to get Unbound and dnssec-trigger running?

  • Install dnssec-trigger daemon:
$ sudo dnf install dnssec-trigger
  • If you use NetworkManager, configure it to use unbound. Add the following line into /etc/NetworkManager/NetworkManager.conf
dns=unbound
  • Enable and start dnssec-trigger
$ sudo systemctl enable dnssec-triggerd.service



$ # disable and stop any existing DNS service, e.g., dnsmasq
$ sudo systemctl start dnssec-triggerd.service
  • Validation failures should be recorded to the system log:
journalctl -f -l -u unbound.service
unbound[1062]: [1062:0] info: validation failure <www.dnssec-failed.org. A IN
  >: no keys have a DS with algorithm RSASHA1 from 192.168.2.1 for key dnssec-failed.org. while building chain of trust

User Experience

The change is something the user should ideally not even notice, however the experience may change for misconfigured domains.

Note: There's a DNSSEC/TLSA validator for Firefox (and some other browsers) developed by CZ.NIC Labs.

Note: We need to describe how automatic split DNS and DNSSEC affects the user when accessing local resources, resources not secured by DNSSEC and spoofed resources.

Dependencies

  • Changes in Docker
  • Changes in NetworkManager
  • Changes in Gnome Shell
  • Changes in default presets and products kickstarts

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?)
    • Release Engineers will have to reverse all the changes done to default presets and kickstart files, so that Unbound and dnssec-trigger won't be installed and enabled by default in Fedora Products.
  • Contingency deadline: Beta freeze.
  • Blocks release? - No
  • Blocks product? product - No

Documentation

For more information on name resolution, DNS and DNSSEC, please check:

Release Notes

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/Default_Local_DNS_Resolver&oldid=429918"