It’s been nearly two months since the high profile BGP hijack attack against MyEtherwallet, where crypto thieves used BGP leaks to hijack MEW’s name servers, which were on Amazon’s Route53, and inserted their own fake name servers which directed victims to their own fake wallet site, thereby draining some people’s wallets.

It generated a lot of discussion at the time, however, it’s largely died down now, and people are content to carry on with their lives. What isn’t fully appreciated is that attack has, in fact, changed the game somewhat, and this means we all have to reevaluate our assessment of DNSSEC.

Why does DNSSEC factor into a hack that was executed via BGP hijacks? Well here’s the bad news, while it’s debatable how easy it is to execute BGP hijacks, there is no defined security protocol in place to prevent it. Really. Last year easyDNS had some of our own IP space hijacked and it took us about a week to get it straightened out. Thank God it was unused space, but the entire episode had me realize how loose the authentication of routing announcements really is. There’s some talk around implementing RPKI but it’s a long way off, if ever.

That leaves us with DNSSEC as our main line of defence against these attacks, of which there are certainly bound to be more.

Had MyEtherwallet DNSSEC signed its zone, and further, used TLSA pinning for their TLS certs, this attack would have been largely mitigated. Two of the resolver services which picked up the fake IP addresses for MEW were Google Public DNS and Cloudflare’s 1.1.1.1, both DNSSEC aware resolvers which would have instead returned failures instead of fake addresses.

Until now though,

DNSSEC hasn’t really caught on for two reasons:

First, historically speaking, old style DNS poisoning attacks (not using BGP leaks) were theoretically possible but not commonplace. Even without DNSSEC name servers started adding mechanisms like source port randomization and it made it increasingly harder to pull off cache poisoning.

Second, DNSSEC wasn’t easy to implement, and it wasn’t exactly “set-and-forget”. Worse, if you did it wrong like screwed up one of your key rollovers, you would hose your own zone. There is even a website that keeps track of high profile outages stemming from botched DNSSEC rollovers. It includes numerous entire TLD namespaces, the US military and even ISC, opendnssec.org and dnssec-tools.org, organizations that are chief advocates behind DNSSEC. Talk about the cobbler’s children have no shoes!

It’s no surprise then that businesses were reluctant to DNSSEC sign their zones because when they did the calculus, they thought they were more likely to experience a self-inflicted outage via DNSSEC misconfiguration than from having an attacker successfully poison or spoof their zone.

Aside from the difficulty in implementing and maintaining DNSSEC, there are also ideological objections. Those include the ideas that DNSSEC is simply flawed, insecure or doesn’t solve anything because of the centralized nature of DNS’ inverted-tree hierarchy.

A standard bearer for anti-DNSSEC deployment is posting called Against DNSSEC. It raises numerous objections to DNSSEC, some more tenable than others. Not long after, one of our developers, Zach Lym posted a response to it entitled For DNSSEC which rebutted the earlier post point-for-point. Both posts were at some point added to the Wikipedia DNSSEC citations section as embodying the opposite views to the issue.

In my mind the anti-DNSSEC article didn’t age well, considered with this addendum to that post’s mini-FAQ:

”What’s the alternative to DNSSEC?

Do nothing. The DNS does not urgently need to be secured.

All effective security on the Internet assumes that DNS lookups are unsafe. If this bothers people from a design perspective, they should consider all the other protocol interactions in TCP/IP that aren’t secure: BGP4 advertisements, IP source addresses, ARP lookups. Clearly, there is some point in the TCP/IP stack where we must draw a line and say “security and privacy are built above this layer”. The argument against DNSSEC simply says the line should be drawn somewhere higher than the DNS.”

This is bad advice. Because BGP leaks are now a thing (Cloudflare’s 1.1.1.1 was briefly BGP hijacked the morning I typed this), doing nothing is no longer an option. Since RPKI isn’t widespread now and the routing experts I talked to say it may never be able to scale. Since it is a certainty that more high profile, damaging and lucrative BGP hijacks are certain to follow, at this moment DNSSEC is the only game in town to defend against this kind of an attack.

Those who are operating their own ASNs can certainly use something like BGPmon or Artemis, and it’s better to have route monitoring enabled than not, but that’s still a matter of how fast your peers can slam the barn door shut after the horse is away. You want all of your key assets to not resolve to fake values, even for a moment, because there are ways attackers can use that brief window of time to promulgate fake DNS values that will last much much longer than the duration of the attack itself, days, weeks—a year.

Another criticism of DNSSEC is that because it relies on DNS, which is itself an inverted tree with a logically centralized root node, it is a “government or state” security system. Well, sure, in the sense that there exists an internet root and it is overseen by an entity at the discretion of a nation state, that much is true. But as much as I’m into decentralization, zero-knowledge systems, and even ideologically identify as an anarcho-capitalist, there is the practical reality that there is no clear path from where we are now to a fully decentralized anarcho utopia. Even if there is, it’ll be a multi-generational slog to get there.

Eschewing the one defence we have against an attack variant that poses an existential threat to anybody whose livelihood depends on being visible over the Internet today is pretty much tilting at windmills. Even the Ethereum Name Service WG which has been working on deploying ENS enabled domains, both under the Ethereum native .ETH TLD and in legacy DNS integrations like .XYZ went with DNSSEC to authenticate the validity of the ENS integration process.

So what do you do about it?

Easy. You go ahead and sign your zones for DNSSEC. We were already working on a ground-up rewrite of our DNSSEC implementation when this happened (truth be told, I coded the first one and it kinda sucked. It didn’t do anything with your DS records and was pretty shaky with key rollovers. Memo to staff: Don’t let the CEO code anymore.)

When the MEW / Amazon Route53 BGP hijack happened, we went to the mattresses accelerating our rewrite, it was like early days. Sleeping at the office, pizza and coffee at 4am, the works. What we have now, well it’s something else.

Now we have easyDNSSEC™ the world’s first Set-and-Forget DNSSEC™ deployment which fully eliminates the implementation hurdles I outlined above. No more worrying about botched key rollovers or remembering to re-sign the zone after an update, let alone how the hell do you get your DS records into your parent TLD? Just press the button and you’re done. End-to-end DNSSEC in about 1 second.

As always, we’ve pushed the new system live as beta, so start with your non-essential zones. When you enable DNSSEC for your zones you’ll notice your name servers will switch from easydns.* to easydnssec.* hostnames, this is because we’ve also signed those name server hostnames ahead of when we pull the trigger and sign easydns.com for real, which will happen soon.

Other enhanced security measures

Once you’ve decided to take the plunge and DNSSEC sign your zones, there are even more safeguards you can implement to further protect yourself. Some of these measures should have been implemented already anyway, like CAA. Some are not for the novice, and they are similar to the early days of DNSSEC implementations: if you miscalculate or lose track things, you can hose your zone. Still, others won’t work until you sign your zone with DNSSEC (DANE), but if you combine DNSSEC signed zones with the tactics below, you will be fairly well secured against attack vectors which can be launched via BGP leaks:

1. Implement CAA records to assert what CA authorities can issue TLS certs for your domain. You should have these in place anyway, since the CA/Browser forum made Certificate Authority Authorization mandatory for all CA’s in 2017.
2. Enable HTTP Public Key Pinning (HPKP) to guard against a future compromise of your CA. This one is non-trivial and you could potentially “brick” your website if you lose track of your keys. (HPKP is implemented via HTTP server headers, not in your DNS zone.)
3. Publishing TLSA records for your hostnames that are secured via TLS. TLSA records enable, DANE which can be used to issue TLS certificates on your hosts and validate them without using a central CA. Doing so is not yet widely supported in browsers, but here we can also use TLSA to assert what CA’s can issue certificates on our domain and what the validation path should be.

Whether you employ any of the additional tactics above, once you DNSSEC sign your zone, if your upstream DNS provider or the IP space for your website (or any other part of your network) gets hijacked, your DNSSEC validation will break, and those using DNSSEC enabled resolvers will not see any fake sites. An outage is preferable to a spoof at this point.

Most of the large resolver services such as Google. Quad9, OpenDNS and Cloudflare are all DNSSEC enabled.