When our customers look at their UltraDNS Query Reports in our portal, we provide details about how many DNS queries each of their zones on our platform receives. By default, we provide information on total responses and then break out details for different query response types, including NXDOMAIN, SERVFAIL, A, AAAA, CNAME, MX, TXT, and NS.
Many of these response categories are well known to those somewhat familiar with DNS, such as A, AAAA, CNAME, etc., and are all types of DNS records available on UltraDNS and other authoritative DNS servers.
SERVFAIL is also fairly self-explanatory as it signals a failure that results in an answer not being served. But NXDOMAIN responses often raise a question mark for users. Many of our customers ask us what an NXDOMAIN response is, and sometimes they ask why they have so many.
What is a NXDOMAIN response?
First, an NXDOMAIN response is a perfectly normal thing in DNS. It was established in the original DNS framework and defined in the original DNS RFC-1034 as a name error:
A name error (NE).
This happens when the referenced name does not exist. For
example, a user may have mistyped a host name.
RFC2308 made NXDOMAIN synonymous with a “name error” response.
"NXDOMAIN" - an alternate expression for the "Name Error" RCODE as
described in [RFC1035 Section 4.1.1] and the two terms are used
interchangeably in this document.
Simply put, if a resolver requests resolution for a record in a zone from the authoritative DNS server and the authoritative server doesn’t have that record, it returns an NXDOMAIN response.
When are NXDOMAIN responses used?
Why would someone request a record that doesn’t exist? Well, there are several possible reasons.
The first is simply a typo, as the writers of the original DNS RFC have said. If you type ‘ww.vercara.com’ instead of ‘www.vercara.com‘ into your web browser, it will receive an NXDOMAIN response indicating the authoritative server does not have an answer for ‘ww.vercara.com’. Vercara.com’s authoritative server will log this as an NXDOMAIN response.
Another possibility could be that you are trying to go to a site that no longer exists. If you went to julysale.onlineretailer.com in October, that record may no longer exist, so you would get an NXDOMAIN if you tried to go there.
Savvy marketers would use a web forward or URL redirect function to redirect users from the old page to their main site or a current promo. That would not result in an NXDOMAIN.
A third reason could be malicious intent. Vercara and other DDoS mitigation providers are seeing a resurgence of direct query attacks on DNS servers, including advanced randomized domain pre-pending attacks, AKA DNS Water Torture attacks.
The intent behind these attacks is to flood the DNS Server with so many junk queries for records that do not exist that the DNS servers become overwhelmed to the point where they cannot service legitimate queries. We call this a DNS Water Torture attack, and this type of attack has increased in frequency and volume over the past 9 months.
Malicious actors are utilizing cheap botnets composed of compromised systems or even using trial accounts in hosting services to generate these requests using dictionaries that are widely available.
Additionally, hacking reconnaissance tools such as dnsenum or fierce make numerous queries as part of discovering hosts inside of a domain. These tools could be used for legitimate purposes and still impact your DNS negatively.
A fourth source of NXDOMAIN responses comes from “leakage” of internal domains or resources. As workers moved to remote work during the pandemic, they took their computers that were configured to connect to internal servers and printers by default.
Most companies did not update these connections when workers started working remotely, so when their computer boots or wakes up, it attempts to connect to a resource, such as file shares or printers, or uses a function like WPAD or Web Proxy Auto Detect, that is only available in the office.
In these cases, the user’s ISP DNS resolvers ask the authoritative DNS servers for records that don’t exist, resulting in NXDOMAIN responses. Making selected global policy changes on hybrid and remote corporate computers can help reduce this leakage.
NXDOMAIN traffic and billing.
NXDOMAIN responses consume resources and increase costs for both service providers and customers. For Vercara, these queries can affect the number of queries customers receive, potentially leading to additional charges.
To help customers stay on top of their query usage, Vercara has implemented Query Volume Notifications in UltraDNS. These notifications alert customers when their query volume exceeds a specified percentage of their contract, allowing them to investigate potential causes, such as NXDOMAIN traffic or organic growth.
If customers experience excessive NXDOMAIN responses, our NXDOMAIN package can help mitigate the impact by reducing costs and streamlining bills.
Minimizing self-generated NXDOMAIN traffic
Vercara offers several methods to help customers reduce self-generated NXDOMAIN traffic, particularly those resulting from internal DNS leakage. For example, split-horizon domains can be configured to ensure internal and external users receive the correct IP addresses based on their location. If misconfigured, remote employees querying internal resources externally could receive NXDOMAIN responses.
Additionally, older file and print shares configured on portable devices can lead to NXDOMAIN responses when laptops attempt to connect to these services outside of the corporate network. Remediation involves configuring these systems to query internal DNS via VPN for fully qualified domain names (FQDNs).
To further help customers, Vercara has built a self-service DNS Health Check tool inside UltraDNS. This tool allows customers to assess their zones for misconfigurations and recommended improvements. We also offer a publicly available version for non-customers.
Protecting your business from malicious DNS queries.
To ensure that our customer’s applications can be found online, Vercara’s UltraDNS provides several methods to protect our platform from DDoS attacks, the most common malicious reason behind increased NXDomain responses.
The first layer of protection is the 15 Tbps UltraDDoS Protect DDoS mitigation network. UltraDDoS Protect is a cloud-based DDoS mitigation service that redirects traffic through the nearest global, regional scrubbing center for analysis and scrubbing.
UltraDDoS Protect currently has 15 Tbps of dedicated scrubbing capacity distributed across 15 dedicated global scrubbing centers, which are collocated in data centers chosen for resilience, network connectivity, and proximity to population centers.
You might ask why we don’t just block queries that result in NXDOMAIN responses before they get to the DNS infrastructure. Honestly, we can’t because until the query gets to the authoritative DNS server, no other device on the network knows if the DNS query will result in an NXDOMAIN response.
Only the authoritative DNS server knows. It would also be risky to block recursive resolvers that generate a lot of NXDOMAIN responses because you would also inevitably block some legitimate queries that you want to get through.
There are other protections you can put in place to reduce the number of times the authoritative DNS servers are queried for a record that doesn’t exist. The SOA’s minimum value, which represents negative cache, or Min Cache, in a zone Start of Authority specifies how long recursive resolvers should cache a negative response, like an NXDOMAIN.
This should keep recursive resolvers from asking for a non-existent record while it’s in the cache. Care should be used when setting a long Min Cache time as it could generate adverse effects if you make changes to your DNS records or if you accidentally delete a record and need to add it back.
DNS enumeration and attacks.
A large portion of NXDOMAIN traffic is also generated by domain enumeration tools like dnsenum or fierce, which make numerous queries to discover hosts inside a domain. In 2023, Vercara built techniques to detect such enumeration attacks. These attacks often use public recursive DNS servers, making them difficult to block effectively.
In extreme cases, such as DNS Water Torture attacks, enumeration can resemble DDoS attacks, overwhelming the target DNS with queries and preventing legitimate DNS resolution.
NXDOMAIN in UltraDDR
Vercara’s UltraDNS Detection and Response (UltraDDR) provides protection against threats like malware and ransomware. UltraDDR uses NXDOMAIN queries to detect Domain Generation Algorithms (DGAs), which generate NXDOMAIN responses. This allows us to identify potential DGAs in action.
Additionally, UltraDDR offers comprehensive logging, allowing customers to track internal queries that result in NXDOMAIN responses. This visibility helps customers identify DNS misconfigurations and resolve internal queries more effectively.
NXDOMAIN responses: A normal part of DNS.
Remember, NXDOMAIN DNS responses are a normal part of DNS and are not necessarily “bad” queries, although large numbers of NXDOMAIN responses could indicate malicious intent and could drive up your DNS costs.
The use of cloud DNS services focused on platform availability such as UltraDNS can help ensure the availability of your DNS services even if they are targeted for malicious intent.
Be sure to use Vercara’s no-cost DNS health check capabilities here or have one of our experts perform a full DNS assessment of your infrastructure to make sure you are configured optimally to avoid over-exposure to excessive NXD queries or other DNS issues.
