Why isn’t everyone using DNSSEC?

By on 28 Jun 2017

Category: Tech matters

Tags: , , , ,

14 Comments

Blog home

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.

14 Comments

    1. Nikolai

      Thanks for your comment! Yes, this needs consideration during implementation.

      Name enumeration is a problem for all DNS records and plenty of tools exist to walk common host names and brute force less common names. Finding the commonly used host names for an organisation is often only a few thousand DNS queries at the moment, and even less when organisations leak naming conventions through email headers and the like.

      NSEC3 provides some protection to DNSSEC through the use of salted hashes. Host names like mail.example.com and mysql.example.com will fall out almost instantly under a brute force attack, but these same records fall out easily with through direct DNS queries anyway.

      If for some reason you need to protect internal host names of sensitive resources, adding entropy through nonsense or random garbage greatly increases the time to brute force all records. For example: MAIL-BLUE-SPARKLE-80.example.com is going to be harder to brute force hashed or not. And, DB-XE8F7CD-QRL885EE.example.com is going to be years of brute forcing hashes even with a reasonably powerful rig.

      Ultimately though, if your security model _relies_ on hiding host-name records in zone files, you’re doing it wrong.

      Reply
      1. George

        Oh, really, “expert.” Then why are external zone transfers highly discouraged and a fireable offense today?

        Why do sysadmins make sure no one can dig axfr????

        Reply
        1. s

          For one thing, because it’s a giant amplification/DDoS risk. An AXFR query is a few bytes long but can generate a response that’s several thousand times larger, depending on the size of your zone.

          Reply
    2. Anne-Marie Eklund Löwinder

      You should have read it through to the conclusion: “CloudFlare is aware of the complexity introduced by DNSSEC with respect to zone privacy, key management, and reflection/amplification risk. With smart engineering decisions, and operational controls in place, the dangers of DNSSEC can be prevented.” Now there are risks with every protocol, DNSSEC is not an exception. But if you wheigh the risks, there is no chance for a user to discover a DNS hi jacking or cache poisioning where if anyone manage to find out what domains and sub domains you are using is of a minor problem in my opinion that is.

      Reply
      1. George

        Oh, really, “expert.” Then why are external zone transfers highly discouraged and a fireable offense today?

        Why do sysadmins make sure no one can dig axfr????

        Reply
    3. Anne-Marie Eklund Löwinder

      If you read the Cloudflare article through to the conclusion it states: “CloudFlare is aware of the complexity introduced by DNSSEC with respect to zone privacy, key management, and reflection/amplification risk. With smart engineering decisions, and operational controls in place, the dangers of DNSSEC can be prevented.” Now there are risks with every protocol, DNSSEC is not an exception. But if you wheigh the risks, there is no chance for a user to discover a DNS hi jacking or cache poisioning whereas if anyone manage to find out what domains or sub domains you are using is of a minor problem in my opinion that is.

      Reply
  1. Scot

    A lot of security experts are against DNSSEC because it offers no noticeable security gain against the attacks we care about, and at the same time, shoehorns everyone into using 90’s era crypto in perpetuity.

    https://sockpuppet.org/blog/2015/01/15/against-dnssec/

    Not to mention, using DANE to replace CAs is basically giving the United States’ NSA complete control over all of .com.

    Reply
    1. Kerry

      NSA paranoia aside, I have far more faith in the management of the DNS root keys than what the multitude of CAs are doing behind closed doors.

      Reply
  2. Phillip Parker

    The DNS caching vulnerability was found in earlier implementations of BIND for for DNS systems (such as those used on the older Windows NT systems) using BIND architecture. This has long been patched (or decommissioned in Windows NT case), and the case to use DNSSEC is rather redundant. However as millions has been spent in advertising it, it will be forced on everyone eventually – because fear and propaganda go hand in hand.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Please answer the math question * Time limit is exhausted. Please reload CAPTCHA.

Top