{"id":378,"date":"2019-02-27T11:50:33","date_gmt":"2019-02-27T16:50:33","guid":{"rendered":"https:\/\/domainsure.com.wp.easypress.ca\/?p=378"},"modified":"2019-02-27T11:57:51","modified_gmt":"2019-02-27T16:57:51","slug":"why-you-must-learn-to-love-dnssec","status":"publish","type":"post","link":"https:\/\/domainsure.com\/articles\/why-you-must-learn-to-love-dnssec\/","title":{"rendered":"Why You Must Learn to Love DNSSEC"},"content":{"rendered":"

 <\/p>\n

\"\"<\/p>\n

(This is a reprint of an article originally run on our parent company’s blog in June 2018).<\/em><\/p>\n

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

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

Why does DNSSEC factor in to a hack that was executed via BGP hijacks? Well here\u2019s the bad news, while it\u2019s 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\u2019s some talk around implementing RPKI but it\u2019s a long way off, if ever.<\/p>\n

That leaves us with DNSSEC as our main line of defence against these attacks, of which there are certainly bound to me more.<\/p>\n

Had MyEtherwallet DNSSEC signed it\u2019s 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\u2019s 1.1.1.1, both DNSSEC aware resolvers which would have instead returned failures instead of fake addresses.<\/p>\n

Until now though,<\/p>\n

DNSSEC hasn\u2019t really caught on for two reasons:<\/h2>\n
via DNSReactions<\/a><\/figcaption><\/figure>\n

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.<\/p>\n

Second, DNSSEC wasn\u2019t easy to implement, and it wasn\u2019t exactly \u201cset-and-forget\u201d. 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<\/a> stemming from botched DNSSEC rollovers. It includes numerous entire TLD namespaces, the US military and even ISC,\u00a0opendnssec.org and dnssec-tools.org,\u00a0 organizations that\u00a0 are chief advocates behind DNSSEC. Talk about the cobbler\u2019s children have no shoes!<\/p>\n

It\u2019s 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.<\/p>\n

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\u2019t solve anything because of the centralized nature of DNS\u2019 inverted-tree hierarchy.<\/p>\n

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

In my mind the anti-DNSSEC article didn\u2019t age well, considered with this addendum to that post\u2019s mini-FAQ<\/a>:<\/p>\n

\u201cWhat\u2019s the alternative to DNSSEC?<\/strong><\/p>\n

Do nothing. The DNS does not urgently need to be secured.
\nAll 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\u2019t 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 \u201csecurity and privacy are built above this layer\u201d. The argument against DNSSEC simply says the line should be drawn somewhere higher than the DNS.\u201d<\/p><\/blockquote>\n

This is bad advice.<\/strong>\u00a0 Because BGP leaks are now a thing (Cloudflare\u2019s 1.1.1.1 was briefly BGP hijacked<\/a> the morning I typed this), doing nothing is no longer an option. Since RPKI isn\u2019t widespread now and the routing experts I talked to say it may never be able to scale.\u00a0 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.<\/em><\/p>\n

Those who are operating their own ASNs can certainly use a something like BGPmon<\/a> or Artemis<\/a>, and it\u2019s better to have route monitoring enabled than not, but that\u2019s 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 \u2013 a year.<\/p>\n

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 \u201cgovernment or state\u201d 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\u2019m 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\u2019ll be a multi-generational slog to get there.<\/p>\n

Eschewing the one defence we have against an attack variant that poses an existential threat to anybody who\u2019s 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<\/a> integration process.<\/p>\n

So what do you do about it?<\/h2>\n

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\u2019t do anything with your DS records and was pretty shaky with key rollovers. Memo to staff: Don\u2019t let the CEO code anymore.)<\/p>\n

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\u2019s something else.<\/p>\n

Now we have easyDNSSEC\u2122 the world\u2019s first Set-and-Forget DNSSEC\u2122<\/a> 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\u2019re done. End-to-end DNSSEC in about 1 second.<\/p>\n

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

Other enhanced security measures<\/h3>\n

Once you\u2019ve 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\u2019t 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:<\/p>\n

    \n
  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\u2019s<\/a> in 2017.<\/li>\n
  2. Enable HTTP Public Key Pinning (HPKP)<\/a> to guard against a future compromise of your CA. This one is non-trivial and you could potentially \u201cbrick\u201d your website if you lose track of your keys. (HPKP is implemented via HTTP server headers, not in your DNS zone.)<\/li>\n
  3. Publishing TLSA records<\/a> 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\u2019s can issue certificates on our domain and what the validation path should be.<\/li>\n<\/ol>\n

    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.<\/p>\n

    Most of the large resolver services such as Google. Quad9, OpenDNS and Cloudflare are all DNSSEC enabled.<\/p>\n

    Further Reading<\/h2>\n