The first vulnerability relates to improper device configuration. Devices, particularly mobile devices, generally rely on another Internet standard mechanism. This is called dynamic host configuration protocol (DHCP) and is used to obtain an IP address (enterprise, home, wi-fi, etc.) as well as additional parameters such as which local DNS server to query.

As long as the administrator of the network you’re connecting to is trustworthy, getting repointed to an imposter DNS server should be relatively low-risk. However, even with trustworthy networks, errors in the configuration of the DHCP server could result in DNS-responsiveness issues. And this could lead to network unavailability (even more so than malicious activity through redirection).

Pharming.

Malicious activity know as pharming is a form of attack where your device installs a virus or Trojan which manipulates your DNS server settings, thereby directing queries to the attacker’s DNS servers. Anti-virus software on devices should help prevent such forms of malicious attack. You can check your DNS server settings within your device’s settings for the network to which you are connected or by typing ipconfig with a command-line window on Microsoft Windows.

Service provider’s DNS.

If you utilise a service provider’s DNS service, such as OpenDNS, you should statically configure your DNS server IP addresses in accordance with the instructions from your provider. When connecting through a virtual private network (VPN), e.g., to your enterprise network via a public wi-fi service, make sure your DNS server settings link to your enterprise DNS servers, not the local network to which you are connected.

Local DNS server misconfiguration.

Mitigating a second vulnerability stemming from erroneous or malicious local DNS server misconfiguration requires server hardware, operating system and application controls. These can all help minimise hacking vulnerabilities. This includes applying patches for operating system, kernel, and DNS application software as well as any other software running on your local DNS servers. This should be standard practice across all of your network and computing infrastructure, as should denial of service mitigation approaches such as packet-rate limiting.

Protection against erroneous misconfiguration requires disciplined configuration checking such as through the use of an IP address management (IPAM) system like IPControl™ from BT Diamond IP. This system greatly reduces the probability of configuration errors.

Another way to reduce exposure to illicit update attempts is to apply access controls for users trying to access the servers, as well as controls over which systems (e.g., IPAM systems, DHCP servers) can update the DNS configuration.

Security practices.

A third vulnerability relates to the security practices of those operating external DNS servers used to refer and resolve DNS queries for devices. This is where you have little to no control, though the root servers and most top-level domain administrators exercise stringent security practices.

For your own namespace, if you desire to register your domain name within a given top-level domain (e.g., .bank, .diamonds, .pub, etc.), then you need to review the domain operator’s security policies. This will help you to confirm a reasonable approach to mitigating attacks on the DNS servers you rely on to accurately point to your DNS servers.

Alternatively, if there are domains you don’t trust (or that are known malware domains which you don’t want your network users asking about), then block them by configuring your recursive servers as DNS firewalls. We’ll discuss DNS firewalls more in part three.

A valid answer.

The fourth vulnerability is when an attacker provides a seemingly valid answer to a query from your local recursive DNS server — prior to the receipt of a valid legitimate answer. In this scenario, the recursive server applies a set of match criteria on the answer to map it to the original query, based on parameter settings in the DNS response.

If everything checks out, the recursive server will respond to the querying device and cache the answer to provide to others asking the same question. Due to the potential impact on multiple users by virtue of the caching of this data, this form of attack is known as cache poisoning.

DNS security extensions.

Most DNS-server vendors have implemented basic steps to hinder cache poisoning, such as randomisation of DNS parameters. But DNSSEC provides the most effective protection against cache poisoning.

DNSSEC lets the answering DNS server sign DNS data. This allows the recursive server to validate the signatures and confirm that the DNS data did originate with the domain operator in question — and that the data wasn’t manipulated en route to the recursive server.

Should an attacker provide a falsified answer (including all matching parameters), DNSSEC validation will disqualify the answer as invalid. This occurs even if the attacker signed the answer, unless the attacker stole the private keys of the corresponding domain owner. This risk should be very small, assuming domain signers secure their private keys.

A secure DNS infrastructure.

IT security is a complex discipline and requires a multi-faceted approach involving defences at the network, software, hardware, and user level.

But even with a secure DNS infrastructure, if an attacker infiltrates user devices with malware to gain a foothold within your network perimeter, the core function of DNS can be put to use by attackers to conduct illicit activity within your network.

So how do you protect your DNS and networks from an attack like this? Keep an eye out for part three to find out.