If your web browser lands on the sad document or the cloud thought bubble, you’ve probably hit an NXDOMAIN error.
NXDOMAIN is the internet’s blunt way of saying “the answer to your question doesn’t exist”. Technically, it’s saying that the domain name referenced in the Domain Name System (DNS) query does not exist. NXDOMAIN, which stands for non-existent domain, is an answer that only an authoritative nameserver can return.
On the other hand, if the domain name exists, nameservers and DNS resolvers will work to return the positive NOERROR response. The specific IP address answer to the DNS query will be returned as well. (It is also possible to receive a NOERROR response without any specific answers. This happens if the domain exists, but not the DNS record type requested.)
This post will examine how admins can leverage NXDOMAIN responses. Further, it will delve into specific examples of what, exactly, an NXDOMAIN response might be indicating. Finally, it will touch on the importance of maintaining NXDOMAIN awareness for the health of your network.
Leveraging an NXDOMAIN response
For the average internet user, NXDOMAINs are usually the result of a typo in the web address. Or they might be an attempt to access a website that no longer exists. At most, they are an inconvenience.
For network and security administrators, NXDOMAIN replies can be far more interesting. Persistent NXDOMAIN messages can actually be an early indicator of network issues or security gaps. With the right DNS security tools in place, these failed responses can become a goldmine of valuable data. (Some unscrupulous ISPs even use a form of DNS hijacking to turn NXDOMAIN into a business opportunity!)
To mine DNS error responses to uncover security and network performance issues, you need comprehensive data from DNS logs. And that data must be in a readily searchable format.
This is a tall order for enterprises operating with decentralized network infrastructures like Microsoft DNS and BIND. In these situations, DNS logs will need to be manually collected from individual DNS servers—a time-consuming process. It’s much easier when you have a unified DNS service operating across the enterprise. It is funneling all that data into a single location.
What is an NXDOMAIN telling you, exactly?
Once you have the right DNS response data at your fingertips, you can search for patterns. From those patterns, you can uncover more details about the root cause of failed DNS requests.
Here’s what some of those NXDOMAIN responses might be telling you:
Malware will try to get instructions from command-and-control systems. However, it doesn’t always know the latest domain to look for. There are many known cases of malware evading blocking by using domain generation algorithms (DGAs).
DGAs generate and register new domains on the internet. The malware, using a similar algorithm, will try a series of domains to find the one that provides an answer. Often times, the installed malware beacons on a somewhat consistent schedule.
Persistent and periodic NXDOMAIN responses can be a clue that a device is infected. Especially if they come from suspicious top-level domains and known malicious sites. There are several statistical methods to score the likelihood that the existent domain was generated via an algorithm.
Reconnaissance and lateral movement
Advanced persistent threats often sit in the background of a network. They bide their time as they search for valuable information and ways to exfiltrate data to the outside. That mapping process often involves a considerable amount of trial and error.
Persistent NXDOMAIN responses from your local DNS service that all originate from a single client could be an indicator. PTR queries can reverse engineer networks and mine for interesting hostnames.
Zone sync issues
DNS zones are often replicated across many servers to reduce latency and increase reliability. If these zones fall out of sync, some users will get the correct response. Others will receive an NXDOMAIN for the same destination, depending on which authority handles the DNS resolution path.
These cases are very difficult to debug without visibility into internal, east-west network traffic. Network admins need the ability to trace specific pathways between clients, networks, and servers.
NXDOMAIN can also be a signal
Certain normal processes utilize the existence of a DNS resource record as an indicator to do or not do something. The presence or lack of an answer indicates how the client will behave. It may include information, such as the address of the content cache, in the answer.
Web proxy auto-discovery (WPAD) is a special domain that allows clients to discover addresses. The goal is to obtain the location of configuration files for web proxies. Usually, clients will attempt to find this record for every DNS search domain configured. In enterprise environments, this often results in millions of NXDOMAIN responses.
Microsoft’s Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) generates a link-local IPv6 address from an IPv4 address. Additionally, it performs neighbor discovery on top of IPv4. It uses a special domain name that should only have an answer if ISATAP is configured. As a result, this process often generates piles of NXDOMAIN responses.
That can look like a problem at first. However, in this case, it’s a completed query that actually points to something interesting.
DNS over HTTPS
Mozilla has a canary domain (use-application-dns.net) that signals Firefox not to use DNS over HTTPS (DOH). Network administrators can configure their DNS to NXDOMAIN this record in order to turn DoH off.
Maintaining NXDOMAIN awareness
In general, the patterns of NXDOMAIN responses are the most interesting to threat hunters and security personnel. Often, the earliest indication that something is amiss is when a consistently queried domain name abruptly starts returning NXDOMAIN responses.
Absent an NXDOMAIN lookup, a unified DNS management system can mine the patterns of NXDOMAIN and other DNS response codes. Certainly, paying attention to your DNS data can pay almost immediate dividends. It can help uncover malware inside your network, lower bandwidth costs, and eliminate performance issues.
Critical conversations on critical infrastructure
Find out how your peers are managing their networks through profound change. Watch this series of live interactive discussions with IT pros & join the debate in Slack.
SUNBURST/Solorigate Situation Briefing
BlueCat leaders discuss how the malware attack via SolarWind’s Orion platform exploited DNS and how BlueCat Edge could have helped to detect it.
React faster at the wire with BlueCat and ExtraHop
With the BlueCat ExtraHop Plugin, automatically create missing PTR records, and detect and react to security threats before they reach DNS servers.
Yes, IT should see what developers do in the cloud
Errors and outages occur when admins lack visibility into DNS and IP allocation in the cloud. With Bluecat, central DDI visibility is within reach.
Cloud DNS: Benefits and obstacles for hybrid networks
Unsure about cloud DNS services and hybrid-cloud enterprises? Learn more with BlueCat, including why it isn’t so simple for managing networks.