Why isn’t everyone using DNSSEC?

It would be easy to make the argument that DNS is perhaps one of the most critical protocols on the Internet. The service, which resolves unintelligible IP addresses to easily readable domain names, is in use by every single Internet user today. It’s the reason you can hit http://www.apnic.net/ rather than an IP address such as 104.20.59.194.

Unfortunately, DNS is inherently weak in its design. The early Internet never anticipated a hostile global network that also ran critical business operations. DNS is susceptible to a range of easy attacks, from simple denial of service to serious hijacking and cache-poisoning attacks.

Given how critical DNS is to the functioning of the Internet, it’s a mystery that the world is prepared to accept such a security-deficient protocol at the core of all its infrastructure. What’s even crazier is that there’s a secure solution that’s been in the pipeline for over a decade: DNS security extensions, or DNSSEC.

DNSSEC defines “security extensions” that can be used to validate any domain record right back to top-level name servers. Using DNSSEC, a user querying http://www.myawesomebankonline.co.au/ can be assured that the returned IP address will actually point to their bank, and not some malicious domain under the control of a hacker or scammer.

The case for security

In the mid 1990s, the first banks migrated from remote access via dedicated dial-up terminals to wide-scale access over the Internet. This roughly coincided with the introduction of a secure HTTP protocol (HTTPs) by Netscape Communications. It was clear that the changing capabilities of the Internet required security and protocols to evolve too.

Only the most sensitive data was initially secured. But, over time, everything from password data to the user’s personal information started to shift under the HTTPs umbrella. Today, no sane corporate or commercial Internet business would implement a new online solution (especially a financial one) without securing the connection between users and services.

The case for security is obvious — when you log in to your bank to enter secret passwords and financial data, you want to make absolutely sure that you’re really talking to your bank and not some imposter. HTTPs makes it impossible for a scammer to impersonate another site — well, almost.

When a user connects to a secure server, they’re presented with that server’s public key, and a signed certificate that authenticates the keys. But, what if I could redirect your request to my own server and never bother to send you any public keys at all? If I force you to talk over plain HTTP, then serve up a compromised website, would you fall for it?

Because you’re on an unsecured site, there’s no reason for your browser to check for certificates: no errors, no warnings, and no security. As an end-user, the onus is on you to check the ‘padlock’ on the URL to make sure everything is secure. A momentary lapse in concentration — and you’ve keyed in your password and become the victim of a phishing attack.

DNS Swiss Army Knife

The explosion of DNS record types further supports the case for DNS security. No longer does DNS simply return web server and mail exchange records for a domain — its flexibility has also seen it become the Swiss Army Knife of online directory services.

The flexible nature of DNS has seen it evolve to provide everything from address records to mail exchangers; IPSEC and TLS keys; SSH keys; SRV records, which point to specific servers and ports; and text records that can be crammed with email sender policies and other protocol and site specific data.

In fact, most domain-validation SSL certificates rely on DNS security to verify site ownership in the first place. The certificate authority might extract owner information from Whois data, but ultimately most of them ping a site or send an email to servers listed in that domain’s DNS record.

Attacking the DNS

Redirecting traffic to malicious sites is surprisingly easy to do. DNS works by sending a record request for a domain or host and then listening for a reply. Because the system is distributed, most likely the initial query will need to be sent to another server to be fulfilled. DNS queries chain together until a server can be located that explicitly declares “I am the authority for the domain you requested!”.

See also: YouTube Animation: How the DNS works

Unfortunately, these DNS interactions don’t happen over controlled connections, but over stateless UDP. The query is broadcast into the void, and the response is blindly sent back with no authentication or verification.

This opens the door to a range of hijack and cache poisoning attacks that can occur. An attacker inserted in a local network can simply intercept and alter DNS requests, while a remote attacker could spray a continuous stream of bogus data at a DNS server hoping to confuse legitimate replies with malicious ones. Admittedly, some of these attacks are more difficult and can be militated against, but these defences all lack the cryptographic certainty of signing and verifying records.

So it seems obvious that every website owner should switch on DNSSEC for their domains ASAP. If users can be assured they’re connecting to validated IP addresses, a whole range of cyber-attacks become much more difficult to orchestrate.

See also:  DNSSEC – Protecting Your Good Internet Name

Problem solved

So, it’s settled. You’ll enable DNSSEC for your domain records, right? Well, even that’s not so easy.

Unfortunately, the uptake of DNSSEC is less than stellar. In a quick scan of my local Australian financial institutions, I found zero uptake of DNSSEC. A look at the ICANN report on domain name registrars that support DNSSEC for .com.au and .net.au is similarly depressing.

For DNSSEC to work, the top-level domains need to be signed, and the registrars also need to support signing of DNSSEC keys. The security must flow down from the root keys in an unbroken chain to the record sets and hosts listed for a domain; any break in continuity and the DNS records cannot be validated.

So, while ICANN mandates that “Registrar must allow its customers to use DNSSEC upon request…” nearly all registrars (while technically compliant), offer no support for creating, maintaining and signing DNSSEC keys and records.

So now what?

Unfortunately, the DNSSEC rollout is creeping along at glacial pace. The case for DNSSEC doesn’t appear to be strong enough to force corporate users to demand their registrars take the issue seriously.

For the time being, the best we can hope for is to increase awareness of DNS security problems. We also need more corporate and commercial end-users to implement DNSSEC where possible, and put pressure on their domain registrars to improve support. Without awareness and demand, we will never reach the critical mass required to make secure DNS a reality.

Until users, software developers and domain administrators are conditioned to expect DNSSEC to be present, the hit-and-miss nature of half-baked implementations will mean that returning no records to a DNSKEY request will confuse matters — is the site’s domain really unsecured, or has the cache already been poisoned?

Nikolai Hampton holds a Master’s Degree in Cyber Security and is a director of Impression Research. He consults on matters of privacy, security, digital forensics, and incident response. His focus is on the correct application of cryptography and he is passionate about educating business on complex security issues.

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.