Distributions

Fedora and DNSSEC

A proposal to have a local DNS resolver installed by default, which would enable DNSSEC for Fedora 24, was recently floated on the fedora-devel mailing list. It shows, once again, the tension between purists and those who are more pragmatic about security. While the public internet may be ready to support DNSSEC, at least from an infrastructure perspective, there are a huge number of internal networks in homes, companies, and public wireless zones that are not. Finding a balance that "just works" for a Fedora installation (or, really, any operating system) in these diverse configurations will be quite difficult—bordering on the impossible, perhaps.

DNSSEC provides a way to turn hostnames into addresses but, unlike regular DNS, those mappings can be checked for authenticity. Essentially, domain owners can publish a public key and sign their DNS records such that others can determine that a particular lookup is authoritative. If that checking is done, it stops a man in the middle from intercepting a DNS query and responding with an answer that redirects traffic for nefarious (or, sometimes, not so nefarious) purposes. This kind of attack is known as DNS cache poisoning.

The proposal, which is also on the Fedora wiki, was posted by Fedora Program Manager Jan Kurik and is owned by four Fedora developers: Prasad J. Pandit (also known as "P J P"), Pavel Šimerda, Tomas Hozza, and Petr Špaček. This is not the only time that this proposal has been made; the first was during the Fedora 22 cycle in 2014. As Hozza noted, this is the third round for the proposal after addressing the feedback from the previous two, as well as coordinating needed changes with a number of different projects. While some of the technical hurdles that came up for the two previous incarnations have been cleared, there are still some concerns that seem likely to push the change out for another release cycle or more.

The idea is to run the Unbound DNS resolver locally on all Fedora systems. It would be configured to locally do the validation of the DNSSEC query responses, which is the only way that a client machine can truly know that the validation was successful. There are ways to forward DNSSEC requests to trusted systems but, without doing the local validation, there is no way to ensure that the responses from that system haven't been spoofed. If the DHCP-provided resolvers are capable of DNSSEC, the local Unbound service will forward requests to them, but it will still gather everything needed to create a root of trust locally and validate all responses.

But, as Lennart Poettering pointed out, there are lots of routers out there that have resolvers that intercept certain queries. For example, the FRITZ!Box routers that are heavily used in Germany intercept queries for the ".box" top-level domain:

Hozza replied that it would be difficult to handle cases where top-level domains are abused in this manner. The root servers will return an authoritative answer that the domain does not exist, which the local resolver should honor. A whitelisting approach might work, he said, but that would require user intervention since the full list of potentially abused (or hijacked) top-level domains is unknowable. For .box, though, things may get a bit more complicated, since it was recently added as a top-level domain, as Paul Wouters noted. If router makers using .box (and there are more than just FRITZ!Box) wanted to, they could presumably register things like "fritz.box" with the new registrar—but that doesn't solve the problem for hosts on the local network that are currently reachable using hostname.box as Poettering described.

Another alternative might be to try using the DHCP-provided resolvers for top-level domains that do not exist based on the DNSSEC response, as Poettering suggested in a sharply worded response to Hozza. That has security implications, of course, but would at least allow hostname.box and the like to resolve correctly. Poettering is quite unhappy with the local-resolver proposal because it will break numerous working configurations, he said, so it has no place in Fedora. He did also put in a disclaimer: "We are working on adding DNSSEC support to systemd-resolved, and about ways to make this available by default, without breaking too much stuff."

Fedora Project Leader Matthew Miller agreed with Poettering's complaints: "Whether or not this is expected to work with DNSSEC is of academic interest given that people will expect it to work with _their computers_, regardless of what they're running." Hozza was irritated that Poettering's disclaimer was largely just "PR for systemd-resolved", but Miller pointed out that wasn't part of his thinking; there are broken configurations out there, and Fedora must play nicely with them.

But Wouters suggested that the networks using invalid top-level domains are already broken. The four foundations of Fedora (Freedom, Friends, Features, First) might justify making the switch:

It seems unlikely, however, that Fedora really wants to be the first to disallow router configuration or cause other problems on its users' networks, so some kind of solution needs to be found (or the feature needs to be pushed back again).

There is another aspect of the proposal that only came to light in the discussion. In answer to a query from Florian Weimer, Hozza described how Unbound would be configured as well as the fallback for networks where the DNS port (53) is blocked, as it sometimes is in hotel and coffee shop wireless networks:

Those pieces seem to have come as a big surprise to Poettering at least. Once again, he posted a blistering reply. He is convinced that the local resolvers (provided by DHCP or otherwise) will need to be consulted, whether they do DNSSEC or not. In addition, he is concerned about Fedora infrastructure handling the load from systems that need to fall back. But Wouters seems unconcerned about that problem, saying that it should be "extremely rare" since there have to be multiple problems in the network's DNS configuration to trigger it: "It should never happen on networks that normal people build." That remains to be seen, however. Also, though it didn't come up in the thread, there would seem to be some privacy implications of funneling a user's DNS queries through Fedora's servers.

The Fedora Engineering Steering Committee (FESCo) took up the issue at its December 9 meeting. Hozza attended and noted that the proposal was being withdrawn for Fedora 24. It turns out that he is the only owner working on it and, with the holidays coming up, he simply won't have enough time to resolve any of the outstanding problems in time for the alpha release, which is scheduled for March 1. He was quick to point out that "the decision has nothing to do with any devel list discussion".

But some FESCo members were concerned that the questions raised in that thread did need to be addressed. Hozza said that there were ideas for solving the problems raised, but that it would take more time than he had available to pull it all together for Fedora 24. He was also encouraged to look into what Android, OS X, Windows, and other systems do, so that Fedora's solution was in line with theirs. In addition, FESCo made a non-binding resolution in favor of DNSSEC support, with a request that anyone who could help out getting the feature into Fedora do so.

While there are questions about the overall efficacy of DNSSEC, using it to resolve names authoritatively does have some advantages. For domains that sign their DNS records, it is useful to be able to determine that the reply is authoritative by default. But there are a lot of networks out there that play fast and loose with the standards and top-level domains, so finding a way to transparently (and as securely as possible) support them will be important.

Comments (8 posted)

Distribution quotes of the week

Comments (6 posted)

Linux Mint 17.3 "Rosa" Cinnamon released

Comments (1 posted)

DragonFly BSD 4.4

Comments (none posted)

Announcing the openSUSE Board election for 2016

Full Story (comments: none)

Distribution newsletters

• DistroWatch Weekly, Issue 639 (December 7)
• 5 things in Fedora this week (December 4)
• openSUSE Tumbleweed – Review of the week (December 5)
• Ubuntu Weekly Newsletter, Issue 445 (December 6)
• Ubuntu Kernel Team newsletter (December 8)

Comments (none posted)

Mozilla Will Stop Developing And Selling Firefox OS Smartphones (TechCrunch)

Comments (17 posted)

BSD for the desktop user: A review of PC-BSD (Opensource.com)

Comments (none posted)