There are a couple of areas in IT security that are often glossed over or deemed as unimportant. The DNS service is one of these, and ignored at our own peril. Let’s do a deep(-ish) dive into this often misunderstood service that is critical to everyone’s IT infrastructure.
First, some background …
DNS as a holistic topic is fairly complex. In its most simplest form though, and as used by end-users, DNS is the service that converts the language-based names of websites, email servers/addresses and other internet services, into IP addresses, that in turn are used by the underlying systems to access the requested service.
In other words, the address entered by the user, eg. www.domain.com, is converted into w.x.y.z (the IP[v4] address).
Types of DNS queries
DNS queries are the computer code that tells the DNS servers what kind of query it is and what information it wants back. There are three DNS query types available in a standard DNS lookup.
- Recursive query: In a recursive query the computer requests an IP address or the confirmation that the DNS server doesn’t know that IP address. In this case. the server continues recursing the DNS tree until it finds the answer.
- Iterative query: With an iterative query, the requester asks a DNS server for the best answer it has. If the DNS server doesn’t have the IP address, it will return the authoritative name server or TLD name server. The requester will query the name server and continue this iterative process until it finds an answer or times out.
- Non-recursive query: A DNS resolver will use this query to find an IP address that it doesn’t have in its cache. These are limited to a single request to limit network bandwidth usage.
DNS Caching
The global DNS system can be seen as a hierarchy with root servers at the top, flowing down to TLD systems, 2nd-level domain servers and then to authoritative servers.
A query moves from a resolver to the next system which has some information on the query, and so on. This could involve a query to a root server, then a TLD server and then finally, the authoritative server.
There are some 350 million domains currently registered globally, with an order more DNS records associated to those domains.
Performance-wise, it’s impossible for a single system to host all these domains and respond to queries for them. Therefore the original design for DNS (a multi-level inverted tree system) is in fact ingenious. But there are still performance limitations and DNS caching improves this system immensely.
Essentially, resolvers cache responses to DNS queries so that they can serve future queries for the same domains/hostnames locally, rather than traverse the DNS system to run the same queries again.
Public Resolvers
A number of commercial (and some non-commercial) companies offer public DNS resolver services. Examples of these include CloudFlare, Umbrella, Google DNS and Quad9. In addition, some of these offer filtering services to control or block access to malicious, adult or other categories of sites.
These services provide a compelling option to those without the expertise or systems to provide internal secured DNS services (eg. home users and SMB organisations).
It should be noted that one then depends on this service to maintain privacy for your DNS queries. In flight, your queries could use DoH/DoT for encryption and at rest, the service provider would offer additional protections.
DNS Security in general
DNS is a core building block of the internet, without which the internet would be far less useful.
But DNS was never intended for the myriad of ways in which it is currently used. At least, current usage was not envisaged at the time that DNS was designed. It was designed to be extensible, but that flexibility was/is limited and has its downsides, especially when it comes to security.
And DNS is one of the few internet technologies that has not equally kept pace with security requirements in the modern age. Making any fundamental change to DNS is going to be very difficult.
The problem with DNS is that the system it uses to signal capability (flags or parameters) can be used to store malicious data or information. DNS records too. And there are no systems that do more than cursory checks on this data, to find malicious intent.
It also doesn’t help that different DNS clients react to, and process, DNS results in different ways, making it difficult to have a fit-for-all solution.
The endpoint is logically the best place to do all-encompassing security however it’s not entirely practical. You’d need a bevy of agents to cover everything (epp, edr, xdr, ndr, etc.) and at that point, your endpoint would be so weighed down, you wouldn’t get any work done on it.
So typically, we have an assortment of systems to cover a variety of security scenarios – systems that include edge, in- or out-of-band, endpoint, proxy, cloud and so on.
But DNS security is always going to be best suited somewhere between the endpoint and the DNS resolver (the system that does the DNS lookup of the client’s request) as that is the location that has the best insight into the query. Note that encrypted DNS options (DoH and DoT) have impact here.
Security Issues related to DNS
Let’s take a look at some of the security issues related to DNS, and potentially how to resolve them.
DNS Spoofing: This is an attack where forged DNS data is introduced into a DNS resolver’s cache, resulting in the resolver returning an incorrect IP address for a domain. Instead of going to the correct website, traffic can be diverted to a malicious machine or anywhere else the attacker desires; often this will be a replica of the original site used for malicious purposes such as distributing malware or collecting login information.
DNS leakage: A DNS leak is a security flaw that occurs when requests are sent to an ISP’s DNS servers even when a VPN is being used to protect users.
DNS tunneling: This attack uses other protocols to tunnel through DNS queries and responses. Attackers can use SSH, TCP, or HTTP to pass malware or stolen information into DNS queries, undetected by most firewalls.
DNS hijacking: In DNS hijacking, the attacker redirects queries to a different domain name server. This can be done either with malware or with the unauthorized modification of a DNS server. Although the result is similar to that of DNS spoofing, this is a fundamentally different attack because it targets the DNS record of the website on the nameserver, rather than a resolver’s cache.
NXDOMAIN attack: This is a type of DNS flood attack where an attacker inundates a DNS server with requests, asking for records that do not exist, in an attempt to cause a denial-of-service for legitimate traffic. This can be accomplished using sophisticated attack tools that can auto-generate unique subdomains for each request.
Phantom domain attack: A phantom domain attack has a similar result to an NXDOMAIN attack on a DNS resolver. The attacker sets up a bunch of ‘phantom’ domain servers that either respond to requests very slowly or not at all. The resolver is then hit with a flood of requests to these domains and the resolver gets tied up waiting for responses, leading to slow performance and denial-of-service.
Botnet-based CPE attack: These attacks are carried out using CPE devices (Customer Premise Equipment; this is hardware given out by service providers for use by their customers, such as modems, routers, cable boxes, etc.). The attackers compromise the CPEs and the devices become part of a botnet, used to perform random subdomain attacks against one site or domain.
There are other types of attacks but this gives you a good overview of the attacks that a resolver/client/authoritative server might need to deal with.
There are also internal privacy and security issues that need to be considered:
- Internal DNS servers hold all the server names and IP addresses for their domains and will share them with anyone that asks: This makes DNS a great source of information for attackers when they’re trying to do internal reconnaissance. (OSINT)
- DNS relays query information from internal workstations to outside servers, and attackers have learned how to use this behavior to create “covert channels” to exfiltrate data.
- Use DNS for Reconnaissance – Once an attacker is inside a firewall and has control of a computer, they can use DNS to find important server names. Attackers can lookup up names that are associated with internal IP addresses – mail servers, name servers – all sorts of valuable stuff.
- Use DNS to Redirect Traffic – Attackers have figured out a way to spoof DNS responses or make responses look like they’re coming from legitimate DNS servers.
- Use DNS as a Covert Channel – Attackers use a technique called “DNS tunneling” to do just that. They set up a DNS domain (evil-domain.com, for example) on the internet and create an authoritative name server. Then, on the compromised host, the attacker can use a program that breaks up the data into small chunks and inserts it into a series of lookups
Prevention/Cure
There are many methods available to stop DNS attacks. The following is a short summary to be used as a start point. Beginning with sound security design.
Prevention: Design your DNS for Security
Let’s talk secure DNS design for a moment. It needs to be said that having clients go out onto the internet for DNS queries is a recipe for disaster. Endpoints should not be querying public resolvers directly. This avenue for queries should be blocked at the perimeter, at the least, for all options including the newer encrypted DNS protocols (DoT and DoH).
The reason for this is that you have no control over what an endpoint is requesting, and what responses are received, if you don’t do the resolution locally or have insight into the queries due to encryption.
By using an internal resolver, you have the most control over queries:
- you now need only allow queries from the resolver to public systems – this means only 1 system to monitor and manage
- endpoints query the local resolver keeping queries internal to the organisation which has privacy benefits
- endpoints do not need any special handling or support for encrypted DNS as this can be done on the resolver and you certainly don’t want your corporate endpoints doing encrypted DNS directly
- your edge security can block all queries except from the resolver (make sure your edge protection supports blocking of encrypted DNS)
- apply DNS filtering either at the resolver or edge level
- apply other DNS transforms like address translation, local DNS (split DNS), etc.
In addition, making use of an iterative resolver which executes direct queries to authoritative servers, bypasses a whole host of issues that would be present should you use, or chain to, public resolvers.
DNSSec
Prior to DNSSec, there was never a way for a client to confirm the integrity of a DNS response. DNSSec adds the capability of signing DNS zones (and their records content) on authoritative servers, offering DNS resolvers the ability to check that the response matches that which is offered by the server.
If the response is not correct, then the client can assume that some form of spoofing or poisoning is taking place.
DNSSec is then a critical component of securing the DNS system, however it’s elaborate implementation means that in the main, it’s seldom used.
Response Policy Zones
The use of response policy zones (RPZ) is an additional method for enhancing DNS security. A nameserver administrator can use RPZ to provide alternative responses to queries by superimposing custom data on top of the global DNS.
General security
It shouldn’t be necessary to state the obvious, but it’s critical that all components in the DNS path are kept updated, and tested for vulnerabilities. This should include:
- firewall/routers
- resolvers and/or forwarders
- clients
- filtering systems
Configuration is also absolutely critical as mis-configuration for either public-facing authoritative servers or internal-facing recursive resolvers can offer a large attack surface to malicious actors, and potentially offer a stepping stone for lateral internal movement.
LMR (log, monitor, report) is another crucial aspect of DNS, the result of which can be used to track usage and operational efficiency of your DNS system, but also be used for post-exploit remediation. This, in conjunction with SIEM and SOAR systems, provides a compelling solution to real-time analytics and protection within organisations.
Remote access systems should be configured with DNS settings that offer both security and privacy, considering that employees may often use these in a split-tunnel situation. In other words, use split-tunnel for both the tunnel traffic and DNS queries.
And yes, of course prevention is better than the cure. But we all have to make the assumption that we might be compromised at some point in time. Incident Response Plans, breach protection, recovery plans, insurance, etc. all play a part of salvaging a bad situation so make sure your business IT (continuity) processes are in place.
Sample topology
The following sample topology includes these components:
- client
- local zone DNS (eg. Active Directory)
- recursor
- firewall/router
A brief description of the various components …
Client: the client is configured with the local zone suffix, as well as DNS pointing to the local DNS server or domain controller; DNS queries are unencrypted
Local DNS: the local DNS server serves up the local/internal zone as well as forwards non-local zone queries onto the recursor
Recursor: receives DNS queries from the local/internal server; does recursive lookups to authoritative servers; performs DNSSEC checks; allows for ECS/EDNS routing queries
Firewall: blocks all outbound queries (including encrypted) except from the recursor; does DNS filtering;
Conclusion
Like many Internet protocols, the DNS system was not designed with security and scale in mind, and contains several design limitations. These limitations, combined with advances in technology, make DNS servers and clients vulnerable to a broad spectrum of attacks, including spoofing, amplification, DoS (Denial of Service), or the interception of private personal information. And since DNS is an integral part of most Internet requests, it can be a prime target for attacks.
In addition, DNS attacks are frequently deployed in conjunction with other cyberattacks to distract security teams from the true target. An organization needs to be able to quickly mitigate DNS attacks so that they are not sidelined from handling simultaneous attacks through other vectors.
Always the bridesmaid, DNS security deserves a much closer look in all organisations.