Changes/Default Local DNS Resolver

Default Local DNS Resolver

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.

Owner

• Name: P J P | Pavel Šimerda | Tomas Hozza | Petr Špaček
• Email: P J P <pjp@fedoraproject.org> | Pavlix <pavlix@pavlix.net> | Tomas Hozza <thozza@redhat.com> | Petr Špaček <pspacek@redhat.com>

• Release notes owner:

Current status

• Targeted release: Fedora 23
• Last updated: 2015-05-28
• Tracker bug: #1182488

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, 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 DNS resolver not only makes sense but is, in fact, badly needed. It has become a need of the hour. (See: [1], [2], [3])

Going forward, as DNSSEC and IPv6 networks become more and more ubiquitous, having a trusted local DNS resolver will not only be imperative but unavoidable as well because it will perform the most important operation of establishing trust between two parties.

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])

• People:-
  • Petr Spacek
  • Paul Wouters
  • Simo Sorce
  • Dmitri Pal
  • Carlos O'Donell

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

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

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)
  • No new features/workflow should be needed from other applications, since the use of a trusted local DNS resolver should be seamless.
  • Ideally other developers and user should test their software and application in this setup and verify that it is working as expected

• Release engineering:
  • would have to ensure that a trusted local DNS resolver is available throughout the installation stage and the same is installed on all installations including LiveCDs etc.
  • Add services needed for the setup into the default presets (dnssec-trigger and Unbound)

• 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.
  • NetworkManager and others would have to be told not to tamper with the local nameserver entries in '/etc/resolv.conf' and save the dynamic nameserver entries in a separate configuration file.

Upgrade/compatibility impact

As long as the new packages which handle 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'.

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

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://github.com/docker/docker/issues/6388
• 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/

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 unbonud(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

How To Test

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.

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 and newer

• 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

• Now it should just work. Please file a bug against dnssec-trigger component in Fedora if it doesn't.

• Validation failues 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

• See dnssec-trigger documentation for more details: http://www.nlnetlabs.nl/projects/dnssec-trigger/

Option 2 - Configure local resolver manually

• 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

It is not something user would notice really.

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

• N/A

Contingency Plan

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

• Contingency deadline: Beta freeze.

• Blocks release? - No
• Blocks product? product - No

Documentation

• https://fedoraproject.org/wiki/Networking/NameResolution/DNSSEC
• https://fedoraproject.org/wiki/Networking/NameResolution/DNSSEC/Design