How I think DNSSec will have to be used in the real world

December 28, 2014

Back when I started reading about DNSSec, it seemed to be popular to assume that how DNSSec would work for clients is that if a particular DNS lookup failed DNSSec checks, the DNS resolver would tell you that the name couldn't be resolved. In light of my personal DNSSec experience and the general security false positives problem, I no longer accept this as workable approach.

The reality of the world is that there are almost certainly going to be two common reasons for DNSSec failures, namely DNSSec screwups by the origin domain and mandatory interposed DNS resolvers that tinker with the answers people get back. Neither are an attack as such, at least as users will accept, and so real users will not find failing to return DNS results in either situation to be acceptable.

Instead, I think that DNSSec results will have to be used as a reputation signal; good DNSSec results are best, while bad DNSSec results are a bit dubious. Many and perhaps most applications will ignore these reputation signals and continue to accept even bad DNSSec results. Some applications will use the DNSSec trust signal as one of a number of heuristic inputs; a browser might shift to considering such resources as less trustworthy, for example. Only a few extremely high security applications will refuse to go on entirely if the DNSSec trust results come back bad (and browsers are not one of them as they will be usually configured).

(Possibly this is already obvious to people who deal with DNSSec on a regular basis. On the other hand, it doesn't seem to be how Fedora 20's copy of Unbound comes configured out of the box.)

I'm sure that this sloppy approach will enrage a certain number of believers in secure DNS and DNSSec. They will no doubt tell us that the DNS lookup failures are a cost worth paying for secure DNS and that anyways, it's the fault of the people making configuration mistakes and so on, and then grind their teeth at my unwillingness to go along with this. I do not have a pleasant, soft way to put this, so I will just say it straight out: these people are wrong, as usual.

Sidebar: the case of intercepting DNS servers

At one level, a nosy ISP or wireless network that forces all of your DNS lookups to go through its DNS servers and then mangles the results is definitely an attacker. Preventing this sort of mass interception is likely one reason DNSSec exists, just like it's one reason HTTPS exists. However, from a pragmatic perspective it is not what most people will consider an attack; to put it bluntly, most people will want their DNS lookups to still work even in the face of their ISP or their wireless network messing with them a bit, because people would rather accept the messing than not have Internet access at all.

(If none of your DNS lookups work, you don't really have Internet access. Or at least most people don't.)

Comments on this page:

By Alan at 2014-12-29 04:35:11:

I do struggle to see the benefit of dnssec (vs. SSL, for example). It seems to be more an enabler for DANE and such, and that seems consistent with your prediction.

However I thought unbound / dnssec-trigger are designed to

  1. support a temporary disable for "captive portal" logins which use dns hijack (auto-detecting them where possible)

  2. support a fallback dns-over-https where there's pervasive dns mangling

I also wonder why you couldn't fall back to full recursion from the roots. I think it's quite common for manglers to let that work. At least if you're running something like unbound. I think non-recursive validators like dnsmasq? have a few more challenges anyway :(.

That doesn't answer the problem of screwups at the origin though.

Written on 28 December 2014.
« My ZFS On Linux memory problem: competition from the page cache
How I have partitioning et al set up for ZFS On Linux »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Dec 28 03:36:37 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.