- Products & Solutions
- Access choices
- Application performance management
- Dedicated Services
- Internet services
- IP address management
- Managed network services
- Virtual Private Network Services
- Network services solutions
- Business technology services
- CRM professional services
- IT professional services
- Network professional services
- Unified communications professional services
- Field force automation
- Flexible working services
- Managed mobility services
- Secure remote access
- Telecom expense management
- Mobility solutions
- Why BT
We are proud that our work is recognised time and again by customers, analysts and professional organisations.
Learn how organisations just like yours get better when they work with us.
Innovation is at the heart of BT’s business.
Catch up on the thoughts and opinions of our experts in our blog.
Explore and debate the big issues with us as we bring together the latest insight on the hottest IT trends.
How we put our customer first.
- About us
We’re well placed to be your trusted partner as you digitally transform your business.
Where the exchange of fresh ideas and information gets up close and personal.
Meet Luis Alvarez, CEO, Global Services and the rest of his leadership team.
- My Account
04 October 2016
Blogs by author: Tim Rooney , Diamond IP Product Management Director, BT.
The vulnerabilities on legitimate queries, and how various strategies can mitigate them.
A recap of DNS.
In part one of this series, we walked through what DNS is, and the basic processes your computer or mobile device uses to translate a ‘www’ address into an Internet Protocol (IP) address. We then looked at a few of the ways the integrity of the domain name system (DNS) could be compromised. In this post, we will review how DNS data can become compromised and what you can do about it.
Improper device configuration.
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).
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.
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.
Securing DNS also requires application of this disciplined approach. Securing your DNS infrastructure will give your users confidence in network and DNS availability, integrity and security.
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.
For more information on DNS and how it can be effectively managed, visit BT’s Diamond IP information page.