Domain name service (DNS) attacks threaten every internet connection because they can deny, intercept, and hijack connections. With the internet playing an increasing role in business, securing DNS plays a critical role in both operations and security.
This article explores how to secure the DNS protocol, DNS servers, and DNS access against a spectrum of attacks through:
Table of Contents
For a higher-level overview of DNS Security, consider first reading What Is DNS Security? Everything You Need to Know.
3 General DNS Attack Prevention Best Practices
Although DNS servers make all connections to the internet, they also resolve hostnames and IP addresses for all local devices (Ex: printers) on the local network. These diverse roles ensure that a huge range of devices, applications, and services connect to the DNS server – and that attackers will exploit these connections when possible.
To protect against attack, best practices must be applied to protect the DNS protocol, the server on which the DNS protocol runs, and all access to the DNS processes. Implementing these best practices will not only protect DNS but also network security in general because properly protected DNS can also protect email, endpoints, and other network systems from attack.
Protect the DNS Protocol
The venerable DNS protocol did not anticipate our current environment filled with aggressive adversaries. DNS communicates in plain text and, without modification, DNS assumes that all information it receives is accurate, authentic, and authoritative.
To protect the protocol, best practices will add additional protocols to the process that encrypt the DNS communication and authenticate the results. Since these protocols do not cost money to implement, these will usually be the first steps taken to improve DNS security.
DNS Encryption
DNS encryption can be achieved through the DNSCrypt protocol, DNS over TLS (DoT), or DNS over HTTPS (DoH). The DNSCrypt protocol requires a server agent and is improved by installing an endpoint agent to make a fully-encrypted connection. TLS and HTTPS inherently create secured and encrypted sessions for communication.
DNS Authentication
DNS authentication will usually be facilitated by the DNS security extension (DNSSEC) protocol. URLs that support DNSSEC publish a public encryption key along with their domain name and IP address.
When a DNS server makes a request to a DNS resolver, the DNS resolver will download and check the public encryption key to verify the authenticity and accuracy of the IP address associated with the requested URL address.
Protect the DNS Server
With the DNS protocol hardened, an organization can turn to protecting the DNS server. Organizations that manage their own servers will need to isolate, harden, maintain, and audit DNS servers the same as they would any other high-risk server managing sensitive information. Organizations lacking internal resources can outsource DNS services to a third-party provider such as Cloudflare, Google, or F5.
DNS Server Isolation
DNS server isolation helps to secure the DNS process by allowing for more stringent control over the open ports, applications, and services allowed to run on the server. Isolation also improves monitoring and anomaly detection because it reduces server activity in general.
Smaller organizations or branch offices that cannot afford separate physical servers can run separate virtual servers. However, the security team must still appropriately protect the virtual machine environment for critical resource protection.
DNS Server Hardening
DNS server hardening can be very complex and specific to the surrounding architecture. We will go into more detail below, but at a high level:
- Deny unnecessary services on the server that are not required for DNS.
- Design robust server architecture to improve redundancy and capacity for resilience against failure or DDoS attacks.
- Firewalls should be hardened to close unneeded ports.
- Implement rate limiting to harden against DDoS and DNS tunneling attacks.
- Information should be limited and hide software version numbers, user names, and other clues attackers can use to probe for weaknesses.
DNS Server Maintenance
DNS server maintenance requires that DNS servers and software be prioritized for updates and patching as part of an organization’s critical infrastructure. Attackers regularly target DNS servers and services which categorizes DNS servers as high risk, high value, and high likelihood for attack. These priority maintenance requirements should also be extended to other security solutions that protect DNS servers such as firewalls and antivirus applications.
DNS Server Audits
DNS server audits require regular use and examination of log files for the DNS server and DNS requests. Audits can be performed continuously by a security operations center (SOC), a managed IT security service provider (MSSP), or a security information and event management (SIEM) system.
Continuous monitoring is preferred, but log files can also be audited on a periodic basis. However, the period should be shorter than monthly for timely detection of attacks.
In addition to checking requests captured in log files, audits should periodically check the DNS settings. Changes since the last audit should be examined to verify their authorization and accuracy and the oldest settings should be periodically reviewed to ensure they remain accurate.
Protect DNS Access
Once the protocol and the servers are hardened, a security team will need to monitor the ongoing services of the protocol and to protect the server against malicious changes.
DNS Traffic Inspection
DNS traffic inspection using next-generation firewalls (NGFW), DNS firewalls, intrusion protection services (IPS), and anomaly detection can be used to protect against DNS tunneling and block malformed DNS queries used in DDoS attacks. DNS protection can also be built into other security offerings such as secure service edge (SSE), secure access service edge (SASE), or zero trust network access (ZTNA) solutions.
The widespread adoption of artificial intelligence (AI) and machine learning (ML) algorithms in more advanced security solutions can be used to enhance anomaly detection. Events such as excessive data transfers or excessive requests from a particular source can trigger automated and proactive actions to block potential attacks faster than a human-only team.
DNS Filtering
DNS filtering examines the URLs requested by users and the URLs sending data through the DNS. Known-malicious URLs will be blocked and suspicious URLs will be quarantined. DNS filtering will often be included in the same tools that provide DNS traffic inspection as well as secure web gateways (SWG) or DNS security services such as those from Cloudflare, Cisco Umbrella, Palo Alto DNS Security, and NS1.
DNS Access Control
DNS access control must be implemented strictly, limited to trusted administrators, and protected against unauthorized access and changes. Servers can be protected by allowlisting specific users and trusted devices, privileged access management (PAM), and multi-factor authentication (MFA).
MFA methods should be carefully selected. SMS should not be used because it is too vulnerable to interception, spoofing, and SIM swap attacks. Better security uses authentication apps, security dongles, or ID cards.
Superior MFA will also:
- Limit access to specific devices using certificates or allowlisted MAC addresses.
- Limit access to specific networks using allowlisted IP addresses.
- Limit access to groups or users through allowlisted users/groups.
Prevention Tips for DNS Server Attacks
It is easy to require best practices but harder to implement them – especially for DNS servers that can be implemented in many different ways. Security becomes further complicated by the different needs of the various DNS components:
- Authoritative DNS servers hold the organization’s DNS information (domain name and IP address pairings); typically hosted by the domain registrar for the organization but can be managed by the organization.
- External DNS resolvers lookup external (internet) domains and addresses; typically hosted by an internet service provider (ISP) or a public DNS resolver (Google, Cloudflare, etc.) but can also be managed by the organization.
- Internal DNS resolvers lookup of local internal network resources (printers, network accessible storage (NAS) arrays, etc.); typically hosted and managed locally on a server.
To help provide advice for a range of needs, we segregate details into the following categories:
- Prevention Tips for All DNS Servers
- Prevention Tips for Internal DNS Servers (Resolver)
- Prevention Tips for Hosted DNS Servers (Authoritative and Resolver)
- Prevention Tips for Domain Name Registrar Servers (Authoritative DNS Servers)
Prevention Tips for All DNS Servers
Only larger organizations manage their own DNS authoritative servers, but it is very common for organizations of all sizes to manage internal DNS resolvers within each branch office to improve the speed for DNS resolution. Regardless of the implemented architecture, all organizations should implement the following additional DNS server protections:
- Backup DNS server information or implement disaster recovery solutions as one would for any other critical data:
- Use automation to avoid human error.
- Relatively high frequency backups (daily or at least weekly).
- Local backups for quick access.
- Cloud backups in case of local failure.
- Offline backups to prevent deletion.
- Service isolation further enhances the best practice of server isolation by separating the authoritative DNS service from the DNS resolver or recursive services; segregated services simplify security and allow further DNS hardening.
- Service resilience avoids a single point of failure by running redundant servers or backup DNS services in case of failure.
Smaller and more focused organizations do not want the hassle of managing and monitoring all of the various DNS attacks. These organizations will attempt to outsource as many DNS functions as possible to MSPs or DNS server solution providers such as Cisco Umbrella, Cloudflare DNS, Google Cloud DNS, or F5 Distributed Cloud DNS.
However, even with many aspects outsourced, the organization bears the final responsibility to verify all service functions according to the terms of the agreement and satisfy all security and compliance requirements. Larger organizations can perform audits and all organizations can request confirmation that the service provider has conducted and passed penetration tests or security audits.
Prevention Tips for Internal DNS Servers
All but the most simple network will need to run internal DNS servers to manage access to network devices such as printers, NAS, and other network resources. These internal DNS servers will need to be set up separately within each branch office and may require some level of local management to support local network resource changes.
Many organizations neglect to implement best practices on assumed-safe local networks. However, increasing cyberattack volumes make assumptions extremely risky and sometimes costly. Even internal DNS servers need to follow the best practices to prevent a compromised device from intercepting DNS traffic or exploiting poorly protected local servers.
In addition to best practices, the local DNS servers should explicitly define and allowlist specific external DNS resolvers or DNS services. The communication between local and external DNS servers will need to be encrypted and monitored.
Prevention Tips for Hosted DNS Servers
Some larger organizations want the control of fully self-managed DNS functions. However, managed service providers (MSPs) and ISPs will manage DNS services for some of their clients as well. In either of these cases, the hosting of DNS services will require a robust architecture, secure configuration, and additional layers of protection.
Secure DNS Server Architecture
Careful design of server architecture can reduce risk and improve performance in the face of many different types of DNS attacks.
Disaster resilience for DNS servers requires redundancy of local servers as well as both primary and secondary DNS resolvers as protection against device or process failure.
Capacity planning resists DDoS attacks by specifying capacity requirements significantly above expected traffic, using load balancers, and implementing response rate limiting.
Restrict resolver usage to users on serviced networks (internal network, within the ISP, etc.) to help prevent its cache from being poisoned by hackers. Hackers target internet-exposed, or open resolvers, which can be detected using the Measurement Factory’s online tool.
Hide the primary DNS server from public access through network isolation and firewall configuration. Internally or publicly available DNS servers should be slave devices that can only be updated by the hidden DNS master server, which makes the visible servers read-only devices for attackers.
Centralize external DNS functions to enable more secure and efficient management. Many configuration elements are small details that can be cumbersome to deploy to many different implementations. While local DNS may need to be locally managed, they can all link to an allowlisted and centrally managed DNS function to perform external searches. For geographically dispersed environments, servers may also need to be dispersed, but they can still be remotely managed by a centralized team to minimize discrepancies, gaps, and outdated instances.
Secure DNS Server Configuration
To adequately protect DNS functions, the DNS protocol and host must be configured for resilience and security. These details can be implemented to further improve best practices for access control and to counter specific types of attacks.
Access control configuration improves general access control security by explicitly defining primary and secondary DNS resolver IP addresses to prevent hijacking, spoofing, and cache poisoning. Using explicitly defined access can also help to trigger alerts for monitoring systems and for anomaly detection. Examples of specifically configured access control include:
- Allowlist specific IP addresses and device MAC addresses for master-slave DNS architecture, primary, and redundant DNS servers.
- DNS Zone transfers should be explicitly limited to specific servers to prevent unauthorized zone transfers to learn about internal network devices and architecture.
- Firewall rules can be set to block outgoing DNS traffic except to authorized and allowlisted DNS resolvers.
Anti-cache poisoning configuration built into DNS software and server options can make it harder for a hacker to insert a bogus response into the cache. Configuration options include:
- Lock the DNS cache stored on a DNS server with a well-defined and enforced time-to-live (TTL) to prevent an attacker’s overwrite.
- Randomize the DNS query source port using a socket pool instead of always using UDP port 53; some operating systems support this option by default.
- Randomize the query ID so that an attacker cannot spoof the next number in a sequence.
- Randomize the case of the letters of the domain names that are sent out to be resolved; name servers treat example.com and ExaMPle.com identically for resolution but will reply using the same case as the original query.
Anti-DDoS configurations can enhance server architecture DDoS to protect DNS. Some of the detailed configurations to consider include:
- Drop non-DNS requests to UDP port 53 (or to the current DNS port if using a sprocket pool.
- Drop abusive DNS queries for malformed fully qualified domain name (FQDN) structures or record types and DNS ANY requests.
- Learn FQDNs being requested to prevent fake pseudo-random subdomains.
- Limit total queries to the protected DNS server.
- Limit response times for DNS queries to prevent DDoS attacks from the same source.
- Limit rates at which queries are accepted (can mitigate DDoS attacks) or data delivered (can mitigate tunneling attacks) to any single IP address.
- Track NXDomain responses from requesters and set a maximum threshold.
Additional DNS Security
A carefully designed and hardened DNS server remains vulnerable to outside attacks – even if the risk is reduced. To further reduce the risk, external DNS security solutions can add layers of protection.
DDoS mitigation services monitor traffic, can provide additional bandwidth, and block many types of DDoS attacks.
Cloud-based DNS filtering and security services such as Cisco Umbrella, Palo Alto DNS Security, and NS1 protect the DNS process by tracking and blocking known malicious sources. The filtering can be expanded to also block unneeded sites such as gambling websites or sites hosting adult content.
Prevention Tips for Domain Name Registrar Managed DNS
For authoritative domain name servers managed by a registrar or other third party, the following features, if offered, can help ensure that your DNS records remain secure:
- DNS change locking offers specific security processes such as to call a specific number for verification from a named individual in the organization before changes to the DNS information can be made.
- IP-dependent login specifies a single or range of IP addresses for login to limit access for external hackers; pro tip: use multiple IP addresses to prevent a single point of failure if one network or device fails.
How to Prevent Each DNS Attack Type
To fully understand why multiple layers of protection are required to protect DNS, we list 14 distinct DNS attacks, how they work, if they can be detected, and how to protect against the attack.
DNS Beaconing
DNS beaconing is a type of DNS tunneling attack that runs botnets through port 53 or encrypted DNS (HTTPS, TLS, etc.) traffic. This type of attack can primarily be detected by packet inspection or anomaly analysis. To eliminate an attack may require both blacklisting the control URL and elimination of botnet infection on the endpoints.
DNS Cache Poisoning
DNS cache poisoning hacks a local DNS server or a DNS resolver to replace IP addresses in the cache. This type of attack replaces the IP address of legitimate websites with malicious IP addresses, which can then be delivered to users on future DNS queries.
Attackers can perform direct manipulation of the cache, but another technique sends a bogus DNS query “reply” with a spoofed source IP address. This technique attempts to appear as the DNS resolver’s answer to an information request from the DNS server.
Servers not using techniques to check for this type of attack will simply store the bogus answer for future DNS queries as an authoritative answer. Once poisoned, any subsequent information requests will pull the false information from the cache until the information expires.
DNS cache poisoning can be detected and countered by:
- DNSSEC
- DNS cache lock
- DNS query capitalization manipulation
- Tight access controls
Internal networks hit by DNS cache poisoning will need to be reset so that the poisoned DNS information does not propagate.
DNS Domain Lock-up DDoS Attack
DNS domain lock-up distributed denial of service (DDoS) attacks overwhelm legitimate DNS servers by creating TCP connections and then slowly sending back random packets to consume resources. This is a common DDoS technique, but not all teams proactively prepare DNS against DDoS attacks.
DDoS attacks can be countered by hardening DNS servers against DDoS attacks, anti-DDoS services (Cloudflare, etc.), and DNS firewalls.
DNS Flood DDoS Attack
DNS flood DDoS attacks overwhelm a DNS server with UDP protocol DNS requests with an enormous volume. Most of the time, DDoS attacks will affect primarily the victim organization, but related services and companies can also be affected.
Flood attacks can also be performed within a network using compromised customer premises equipment (CPE). This form of the DNS Flood DDoS attack may be called a botnet-based CPE attack.
DNS Flood DDoS attacks can be countered by hardening DNS servers against DDoS attacks, anti-DDoS services (Cloudflare, etc.), and DNS firewalls.
DNS Interception
DNS interception captures a DNS inquiry and re-routes the request to a malicious resource that will redirect users to malicious websites. Most commonly, this type of attack will be performed through phishing attacks on an endpoint where the DNS query of the URL or IP address in the phishing email will be redirected to a malicious DNS server.
This type of attack typically requires detection on the endpoint or through email security because it can bypass centralized monitoring – especially for remote users. Solutions that redirect remote endpoint inquiries, such as DNSCrypt, secure service edge (SSE), secure web gateways (SWG), zero trust network access (ZTNA), and secure access service edge (SASE), may also prevent this attack if DNS is forced to go through centralized monitoring and processing for all users and devices.
DNS Hijacking
DNS hijacking redirects queries to malicious sites through malware, a compromised DNS server, or compromised network equipment (routers, etc.) by replacing information in the DNS record. These attacks effectively act the same as DNS cache poisoning but directly compromise the DNS records or DNS authoritative name server instead of only the cache.
Attackers access the server by stealing credentials or compromising devices holding DNS information. DNS servers will often be exposed to attack by direct exposure to the internet and network devices will sometimes be exposed to the internet for admin access or exposed through compromised network endpoints (phishing, stolen credentials, compromised VPN servers, etc.).
The worst form of DNS hijacking compromises the authoritative DNS records at the domain name registrar and turns an organization’s URL into a redirect to a malicious IP address. This attack compounds the headaches of DNS hijacking by possibly adding an organization’s domain to the blacklists of many antivirus products and threat intelligence feeds.
These types of attacks can be detected or countered by monitoring log files, intrusion detection or protection systems (IDS or IPS), next-generation firewall (NGFW) packet inspection, anomaly detection, and tight access controls. DNS domain name registrar compromise may be impossible to detect, so it must be countered with tight access controls and multi-factor authentication.
DNS Malformed Query DDoS Attack
DNS malformed query DDoS attacks overwhelm a DNS server with requests that have been intentionally misconfigured to increase the DNS server resources needed to process them. When delivered in volume, the processing resources can overwhelm and shut down a DNS server.
DDoS attacks can be countered by hardening DNS servers against DDoS attacks, anti-DDoS services (Cloudflare, etc.), and DNS firewalls.
DNS NXDOMAIN DDoS Attack
DNS NXDOMAIN (non-existent domain) DDoS attacks overwhelm a DNS server with requests for non-existent records or fake domain names. The DNS server will make connections with DNS resolvers and with the requesting client, which will consume resources to the point that legitimate DNS queries cannot be processed. DDoS attacks can be countered by hardening DNS servers against DDoS attacks, anti-DDoS services (Cloudflare, etc.), and DNS firewalls.
DNS Phantom Domain DDoS Attack
DNS phantom domain DDoS attacks overwhelm a DNS server with requests to connect to non-existent or slowly responding domain servers. DDoS attacks can be countered by hardening DNS servers against DDoS attacks, anti-DDoS services (Cloudflare, etc.), and DNS firewalls.
DNS Reflection-Amplification DDoS Attacks
DNS reflection-amplification DDoS attacks use bots to send DNS queries with spoofed IP addresses using the victim’s IP address so that the DNS response will be sent to overwhelm the resource at that spoofed IP address. DNS DDoS attacks seek to block general access to the internet for users. DNS reflection-amplification DDoS attacks can be countered by hardening DNS servers against DDoS attacks, anti-DDoS services (Cloudflare, etc.), and DNS firewalls.
DNS Spoofing
DNS spoofing introduces forged DNS IP addresses into a DNS cache either through DNS cache poisoning or by impersonating a legitimate DNS server; similar to DNS hijacking but targets the cache, not the DNS record itself.
DNS spoofing can be detected and countered by DNS server monitoring, and server hardening against tampering (access control, allow/deny-listing, etc). Services or protocols, such as DNSSEC, that verify the authenticity of DNS responses can also counter spoofing.
DNS Subdomain DDoS
DNS subdomain DDoS attacks overwhelm a DNS server with requests for non-existent URL subdomains (EX: idonotexist.esecurityplanet.com, esecurityplanet.com/idonotexist/). DDoS attacks can be countered by hardening DNS servers against DDoS attacks, anti-DDoS services (Cloudflare, etc.), and DNS firewalls.
DNS Tunneling
DNS tunneling does not attack the DNS process but instead uses the DNS traffic as camouflage to deliver malware to users, execute commands, or exfiltrate data. By default, most firewalls and servers trust DNS communication on port 53 and attackers can take advantage of this to hide their actions. In some cases, attackers will also use encrypted DNS queries over SSH, TCP, or HTTP protocols to further obscure their actions.
DNS tunneling can be detected and blocked by inspecting DNS traffic, strictly controlling access to the DNS server, and by monitoring the IP address or domain to which the DNS information is sent. If using logs to detect tunneling attacks, look for many paired requests and replies from complex or suspicious domains and many more requests than normal.
Unencrypted DNS Interception
Unlike other attacks, the interception of unencrypted DNS information will not typically be used to compromise, control, or deny access to DNS processes or network devices. Instead, attackers merely intercept the DNS queries sent by default in plain text to track and monitor internet access requests.
The stolen information can be used in information gathering for future attacks and is nearly impossible to detect because it does not impact or affect systems or processes. This type of attack can only be defeated by adopting an encrypted DNS query protocol.
Bottom Line: Protect Business Operations By Protecting DNS
Without DNS, users cannot locate network printers, access SaaS applications, or make connections to internet resources. For many organizations, a DNS failure will cause the entire organization’s IT systems to fail, which can incur significant business losses and recovery costs.
Whether using outsourced DNS services, a modest internal-only DNS resolver, or a robust multi-function DNS architecture, an organization must recognize DNS as a mission-critical resource under regular attack. To ensure secure and operational DNS functions, every organization should at least maintain best practices and, if possible, even better security for this critical IT service.
For more information on related security, consider:
This article was originally written by Paul Rubens and published on October 18, 2017. It was updated by Chad Kime on December 8, 2023.
