How to Prevent DNS Attacks

In October 2016, hackers used malware known as Mirai to create a botnet consisting of hundreds of thousands of Internet-connected devices. They then launched the biggest distributed denial of service (DDoS) attack to date – at times reaching a staggering 1.2 terabytes per second – against a New Hampshire-based company called Dyn, now part of Oracle Corp.

Under normal circumstances, the result would have been that Dyn’s servers would have been unreachable, and the company’s Internet-facing activities would have ground to a halt. But Dyn was responsible for a lot more than just one company’s websites. That’s because it provides managed DNS services to many of the world’s best known websites, including BBC, CNN, Comcast, and Spotify. With their DNS services blocked by the attack, these websites went dark to vast areas of North America and Europe.

The attack shows the truth of the old mantra that cybersecurity is only as strong as the weakest link in the security chain. In this case the weakest link was the DNS system, and specifically a part that was outside the control of many of the companies that were affected by the DDoS attack.

If you’re in the market for DDoS security, see our list of top DDoS protection vendors

How does DNS work?

To understand the problem, let’s think about how DNS works. If you want to visit www.example.com, your browser needs to find the IP address of that particular web server. The first thing it does is consult the system’s hosts file, a text file with the IP addresses of any domain names that are effectively “hard-coded” into that system.

If that web address isn’t in the system’s hosts file, and this will almost always be the case, your browser will ask a DNS server – either a resolver on your organization’s network, or an external, public resolver which may be operated by an ISP, or by an organization like Google or OpenDNS.

Put simply, if the resolver has recently been asked for the IP address for that domain name, it will have that information in its cache and it will provide it directly. But if it hasn’t got it in its cache – either because it has never been asked for that information before or because the information has “expired” and been removed from the cache – then it will refer the request to a root server, which can tell the resolver where to get information about the .com top-level domain.

It will then ask that server where to get information about example.com, and then go to that server, called the authoritative server, which will provide it with the IP addresses of any servers in the example.com domain (such as web and email servers).

How hackers use DNS

The problem with this system is that if a hacker can find a way to make the resolver report back the wrong IP address, then anyone trying to get to one web address will be sent to a bogus one, without any obvious way for the user to detect that anything is wrong. Likewise, email could be delivered to the wrong destination, and so on.

The underlying problem is one of DNS server configuration. “DNS servers tend to be forgotten about, and their default configuration is not necessarily secure,” warns Chris Brenton, a fellow of the SANS Institute and director of security at Dyn.

Before looking at configuration and other changes that can be made to keep DNS secure, let’s look at some ways that DNS can be compromised.

Cache poisoning

Cache poisoning involves putting false information into the cache of a server that is part of the domain name system. A typical way to do this is by sending a bogus “reply” with a spoofed source IP address to an information request. If the bogus reply arrives back before the genuine response comes from the server that was asked, the bogus reply may be cached.

Once a cache has been poisoned with false information in this way, any subsequent information request will be answered with this false information until the information expires. So if a corporate resolver is poisoned, local users will receive the poisoned information. If an ISP’s resolver or a public resolver is poisoned, the effects will be much more widespread.

How long does the cache remain poisoned? DNS information has a time to live (TTL) associated with it – the amount of time that it is valid before it expires and needs to be retrieved again from the authoritative server. The TTL for DNS information can be specified by the domain name owner, but getting it right is a fine balancing act.

If it is set to a long duration, any changes that the domain owner makes will take a long time to propagate through the Internet because the old, out-of-date information will stay in resolver caches for a long time before expiring. But if it is set to a short duration, any malicious changes made by a hacker will propagate more quickly – and thus are more likely to come in to effect before the malicious changes are detected.

(In theory, a hacker who manages to poison a cache could set the TTL of their malicious records to a period of weeks or months for a long-lasting effect, but most DNS software has a maximum TTL: seven days in the case of BIND, or 24 hours for Microsoft DNS.)

Compromising DNS servers

A more effective way to compromise DNS is by changing the information in the authoritative name servers themselves. That can be done by compromising the server, perhaps by exploiting an unpatched vulnerability in the server’s operating system or the DNS software itself. A simpler way is to use a technique similar to the one used by a hacker gang called the Syrian Electronic Army (SEA) in 2013 to change the New York Times‘ records so that it dropped off the Internet.

Here’s how that technique works: A name server may be run internally by an organization or run by a third party like a domain name registrar on behalf of the domain name owner. In either case, the domain name records it contains will need to be changed or updated from time to time. To do this, an administrator needs to log on and carry out the changes or updates.

So if a hacker can access login credentials (perhaps by a simple social engineering or phishing email attack) then they can alter the DNS records and redirect traffic to their own site as effectively as if they had hacked the genuine web server itself.

Denying DNS services

Perhaps the easiest way for a hacker to compromise a company’s DNS servers is simply by DDoSing them – launching a DDoS attack against the servers using a botnet that can be rented by the hour. DDoSing a large managed services provider like Dyn is not easy (although not impossible, as the events of October 2016 demonstrated), but DDoSing most corporate DNS servers could be trivial for most hackers unless steps have been taken to mitigate the risk of a DDoS attack.

Preventing a DNS attack

So what can you do to prevent your organization being the victim of a DNS attack?

Keep your resolver private and protected. If you operate your own resolver, its usage should be restricted to users on your network to help prevent its cache being poisoned by hackers outside your organization. It should not be open to external users. You can check for open resolvers on your network using The Measurement Factory’s online tool.

Configure it to be as secure as possible against cache poisoning. Protections built into DNS software to protect against cache poisoning include adding variability to outgoing requests, to make it harder for a hacker to get a bogus response accepted. Possible ways of doing this include:

• using a random source port (instead of UDP port 53)
• randomizing the query ID
• randomizing the case of the letters of the domain names that are sent out to be resolved. (That’s because name servers will treat example.com and ExaMPle.com the same when it comes to resolving the IP address, but it will reply using the same case as the original query.)

Manage your DNS servers securely. When it comes to your authoritative servers, you need to decide whether to host them yourself or have them hosted at a service provider or domain registrar. “No one cares about your security as much as you do, so we advise hosting and managing yourself – if you have the skills to do so,” says Brenton. “If you don’t have those skills, then of course it is better to get someone else to do it for you. It’s not just a matter of expertise, but also of scale because many organizations need to have DNS servers in three or four places around the world.”

If you host your own DNS servers

Mitigate the risk of a DDoS attack.Wherever you place your DNS servers, they are susceptible to a DDoS attack which will likely overwhelm them. Few organizations have the capacity to defend themselves against a DDoS attack by themselves, so it’s vital to ensure that they (and probably the rest of your servers) are protected by a DDoS mitigation service that can help scrub some of the unwanted traffic and provide the bandwidth to ensure your DNS servers remain reachable.

Don’t get caught by known vulnerabilities. If you run your own name servers (probably BIND or Microsoft DNS), then it’s vital to keep them (and the operating system on which they run) patched and up-to-date to prevent them being exploited by known vulnerabilities. A patch management system is a pretty critical security tool in general.

Another reason to keep them updated is to help prevent your name servers from being used in reflection attacks on third parties. In these types of attacks, a hacker can send DNS requests with spoofed sources to your servers, resulting in your servers responding by sending unwanted traffic to the spoofed source. Since the replies are often much larger than the original requests, the result is that the attack is amplified by going through your servers. Newer versions of DNS software use a technique called Response Rate Limiting (RRL) to prevent them from sending responses multiple times to the same spoofed source in a short period of time.

Separate the authoritative function from the resolving function using different servers. This reduces the possibility of your domains going offline from a denial of service attack.

Use a hidden primary master name server. If your primary name server is only used to serve data to slave name servers, this makes it much easier to carry out maintenance and upgrades on it without rendering your domain unreachable.

Restrict zone transfers. In some circumstances, slave name servers may request a zone transfer, which effectively is a copy of part of the master server’s DNS database. The zone records contain plenty of information that could help an attacker understand the topology of your network, which is useful if they are planning an attack. For that reason, you should ensure at the very minimum that your names servers are configured only to carry out zone transfers to the specific IP addresses of your slave servers.

Monitor your name servers. Ensure you have visibility into their status and any changes made to them or unexpected behavior. The quicker you can spot malicious activity, the less likely your domain can be subverted.

Use PKI to protect your server. Use digital certificates to authenticate your SSH session when you log on to your DNS servers to make changes.

Use a hardened operating system or specialist DNS appliance. Minimize the attack surface of your DNS servers by closing unneeded ports and stopping unwanted services. DNS appliances typically offer hardened operating systems with automatic updates and protection against denial of service attacks – but Brenton warns that vendors are often slow to supply updates and patches for their appliances.

If you use a domain name registrar

If your domain name servers are managed by a registrar or other third party, it’s important to satisfy yourself that their operations and security measures are up to scratch. The following features, if offered, can help ensure that your DNS records remain secure:

• Two-factor authentication. If an administrator can be social engineered or phished into giving up your DNS account details, your account may still be safe if access depends on a second authentication factor such as a security dongle or one-time password delivered to a mobile phone.
• DNS change locking. Some registrars offer specific security processes that have to be carried out before changes can be made to DNS settings. For example, a registrar employee may have to call a specific number to get verification from a named individual in your organization before changes can be made.
• IP-dependent log in. Some registrars allow you to specify a single or range of IP addresses from which you can log in to their systems. This won’t protect against insider threats, but it can help keep you safe from external hackers. Brenton warns against specifying a single IP address, as this can cause problems if the machine at that address goes down, recommending instead a range of addresses.
• DNSSEC. DNSSEC technology allows DNS information to be digitally signed so that a hacker can’t forge it. “If a provider has not implemented DNSSEC, then you should be nervous,” says Brenton. “If they don’t have DNSSEC, then you have to ask yourself what other security measures they have missed out as well.”

For more cybersecurity recommendations for DNS, the National Institute of Standards and Technology has published a Secure DNS Deployment Guide.

Paul Rubens has been covering enterprise technology for over 20 years. In that time he has written for leading UK and international publications including The Economist, The Times, Financial Times, the BBC, Computing and ServerWatch.