Fedora mulls providing a local DNSSEC resolver

The Domain Name System (DNS) has never been secure, yet a great many other Internet services would not function without it. That is why the DNS Security Extensions (DNSSEC) were created. But the security of DNSSEC hinges on validating that the information returned from a DNS server has not been tampered with. Any application can perform its own DNS lookups—as is true in non-DNSSEC DNS—but most rely on an external resolver to perform the function on their behalf. Consequently, applications place a considerable amount trust in the DNS resolver: DNSSEC can safeguard against cache poisoning and other attacks, but the system does not offer protection if the resolver itself is compromised. To provide the most trustworthy DNSSEC service it can, Fedora is considering making a local DNSSEC resolver the default for the forthcoming Fedora 22 release—although most of the changes should land in time for Fedora 21, giving users and developers an opportunity to battle test them.

The proposed change is meant to ensure that there is always a trusted DNSSEC resolver available, even though the average portable computer is used on a variety of untrusted networks (such as on a public WiFi access point). On many of these untrusted networks, DNS server information is provided to client machines by DHCP. At best, a remote DNSSEC resolver on such an untrusted wireless LAN should be regarded with caution, and in practice many public hotspots do not offer DNSSEC at all, which means that DNS queries fall back to unverified DNS. With a DNSSEC resolver running as a local process, however, less trust is placed in unverified systems.

In a nutshell, DNSSEC is designed to permit cryptographic verification of DNS record lookups by having DNS servers digitally sign all of their messages: IP address lookup, MX records, certificate records, and so on. Notably, DNSSEC servers sign—but do not encrypt—DNS messages, although Daniel J. Bernstein's DNSCurve protocol does perform encryption, including encrypting DNSSEC. DNSCurve, however, is not widely supported among the major DNS service providers.

DNSSEC is broadly available, but, for any given domain, it is up to the domain owner to create and deploy the public/private key pair used to sign authoritative DNS messages for the domain. The root and top-level name servers (i.e., .com, .org, .net, etc.) have already implemented DNSSEC, though, as have many domains, and many recursive name servers are already DNSSEC aware.

As is usual for Fedora proposals, program manager Jaroslav Reznik posted the local-DNSSEC-resolver proposal on the Fedora development list on April 29, on behalf of change owners Prasad J. Pandit, Pavel Šimerda, and Tomas Hozza. The list of benefits to implementing the proposal include providing increased security and privacy for users (in light of how many public networks are not trustworthy), providing a more reliable DNS-resolving solution than that often found on public networks, and the simple principle of pushing forward with items like DNSSEC and IPv6 adoption. DNSSEC and IPv6 are the future, after all; it would be better to get implementations in working order before they become mandatory.

The change proposes setting up a validating DNSSEC resolver running on the Fedora machine, bound to 127.0.0.1:53. The resolver software to be used has yet to be selected, although unbound was suggested as a likely candidate. Paul Wouters said that the Fedora project has been working with the unbound team on adding necessary features, and it has also been selected by FreeBSD.

With the DNSSEC resolver running on a local port, applications configured to use the system default would automatically send their queries to the local server. By default, Fedora uses NetworkManager to configure DNS and other basic network options; if the machine joins a network on which a DHCP server supplies DNS server recommendations, the local DNSSEC resolver would pick those up as transient resolvers. Naturally, implementing the change would have a ripple effect on a number of other components for some systems. Users who manually edit their /etc/resolv.conf or /etc/sysconfig/network-scripts/ifcfg-* files would need more effort to migrate.

There are a few issues yet to be resolved with the proposal. First, the mailing list discussion revealed that there is not a clear, bright line between "trusted" and "untrusted" networks. A network may provide DNS service for machines in the local domain. In that case, the Fedora system can either choose not to trust the LAN's DNS server (and thus be unable access to local machines), or to trust the LAN's DNS server and run the risk that it will respond to queries with malicious replies. Of course, the root of this problem is that it is not entirely clear how the local DNS resolver (DNSSEC or otherwise) could automatically distinguish between a trusted and untrusted network.

But that is not a problem limited just to DNS or DHCP; which networks are trusted and which are untrusted is a question generally only the user can answer. The user knows which locations (home and office, for example) are trustworthy and which are not (like the neighborhood coffee franchise). There is some risk of confusing the two in NetworkManager's saved network information, such as in the case of multiple networks that use the same SSID (e.g., "linksys," "dd-wrt," or other defaults). But that possibility of confusion is already present. In all likelihood, Fedora will delegate the decision to trust a network or not to the user, as it does for other security questions such as firewall policy.

Matthew Miller asked whether the team working on Fedora's cloud product had been consulted, noting that DNS resolvers are not lightweight processes, and cloud admins prefer to run as few services as possible. Also, the stated justification that Fedora machines are portable/mobile devices moving between networks assumes things that are not true for the cloud product.

There is another major challenge with less clarity about possible solutions, however: Docker. Fedora is moving forward with a plan to offer Docker containerization for applications, but as Alexander Larsson pointed out, Docker (as well as, potentially, some other applications) makes use of network namespaces. Inside the namespace, 127.0.0.1:53 would point to the container itself rather than to the host, so DNS resolution would fail.

Several possible solutions were proposed, each of which include some drawbacks. Colin Walters suggested offering a local API for the resolver (either using Unix sockets or over kdbus); that suggestion was rejected because it would require modifying every program that performed DNS queries. Simo Sorce proposed modifying Docker, providing it with an IP address that would be redirected to the host. The problem there is finding an IP address that would be guaranteed to be available for both the container and the host.

Larsson pointed out that the Docker container and the host both reserve the entire 127.0.0.* address block for loopback usage; finding another usable address would probably mean hijacking an address officially reserved for some other purpose (Sorce suggested something from 192.168.*.*, which is used for similar reasons by libvirt, or 169.254.*.*, which is owned by Microsoft but designated for auto-address-assignment by hosts experiencing local collision).

Chuck Anderson asked whether the DNS resolver could simply listen on another address, such as 127.0.0.53. That would also interfere with the 127.0.0.* loopback reservation already mentioned, but Pandit responded that it would be easier to modify the container to forward 127.0.0.1:53 to the host system. Since it seems like modifying Docker's behavior is required for any solution, how best to proceed is still up in the air. As Sorce had noted earlier, the problem of how an application inside a Docker container might communicate with the host system is akin to the problems tackled by other virtualization projects, so it is certainly not unsolvable.

Although the cloud and Docker cases have yet to be resolved, the change is proposed for deployment a full release cycle away, which should provide plenty of time to explore and test possible solutions. For the Fedora 21 release, users may choose to install and run unbound (or another DNSSEC-validating local resolver), gaining the benefits of DNSSEC validation—as well as always having a relatively trustworthy DNS resolver on hand, regardless of the state of the network itself.