NXDOMAIN, meaning and suggested actions
Completed
This article is about NXDOMAIN responses, and what you might want to do about some types of NXDOMAIN responses. I'll assume that you know about DNS response codes, and about NXDOMAIN in particular. There is a separate article in the Best Practices and Configuration Tips" section of the UltraDNS Community. You should be able to find it at:
Because NXDOMAIN responses don't actually return a record, they can't return a TTL to control how long recursive resolvers can cache NXDOMAIN replies. There is another mechanism to control how long NXDOMAIN responses can be cached. You can find an article about this in the Best Practices and Configuration Tips section. You should be able to view it at:
Briefly, in DNS, resolvers return a status code which clarifies the type of answer being returned. For example, a server could return "NOERROR" and the requested record(s). If it is responsible for the zone, but there are no records of any type for the name you request, the server will let you know that by returning a response code (also called STATUS) of "NXDOMAIN" and 0 answers. For example, if you run:
dig @a.iana-servers.net nosuchname.example.comit would return "status: NXDOMAIN" and "ANSWERS: 0". That says "there are no records with that name". (a.iana-servers.net is the authoritative server that is responsible for the example.com domain.)
How can you find out about NXDOMAIN responses for zones in your account? If your account contract includes advanced reporting, there's an "Advanced NXDomain" report in the portal, which lets you see NXDOMAIN responses for all your zones in a single table. If you don't have advanced reporting, you can still see NXDOMAIN responses on a zone by zone basis, by going to the Query Analytics report, selecting the zone you're interested in, and clicking the Host Report button. The resulting table will show the number of responses for various types of responses, including NXDOMAIN responses.
Why would you care about NXDOMAIN responses? It is common to have a fairly high number of NXDOMAIN responses, which can affect your query count. They can also indicate missing or misspelled records. They can occur for a variety reasons, most commonly:
- typos
- missing records
- leakage of queries that should go to your internal servers
- attack traffic
- qname minimization
Typos, either typing errors by users, or incorrectly configured data in your UltraDNS configuration, are not uncommon. It's worth periodically looking at your NXDOMAIN responses, at least for your busier zones, to see if there are high numbers of queries for names which look likely to be typos (e.g. "wwww.yourdomain.com", note that there are 4 "w" characters, which is very likely a typo by the person trying to resolve “www.yourdomain.com”). Any which look like they "should work" should be investigated...you may be losing customer traffic that you want! In particular, you can discover data entry errors (misspelling the name for the record, etc.) Even if the problem is a typing error by your clients, it might be worth adding records to redirect traffic (e.g. a CNAME that says "if they ask for "wwww.yourdomain.com", have them go to "www.yourdomain.com" if the misspelling is common.)
Missing records are similar to typos in that they can prevent customers from finding the records they need. They're typically encountered when you want to add a new server, but someone forgets to add the record...if people try to resolve the record, it would cause NXDOMAIN responses. As with typos, if you get a lot of queries for a record related to a new service, it indicates a problem. It's likely to be a sign that someone missed adding the requested record(s).
Attack traffic does happen occasionally. If it's very heavy, it will show up in our monitoring, and we'll mitigate it. However, it can be at a level which is below our detection thresholds, but still could add up to a significant number of queries for you. It is common for attackers to try to evade detection and mitigation by sending just a few queries for each of a lot of bogus qnames ("qname" is DNS lingo for “the Query NAME for this request”), so it's worth exporting the NXDOMAIN report, or the Query Analytics report for busy zones, and looking at the bottom of the (sorted) list of NXDOMAIN queries to see if there are a lot with just a few queries per name, and with names that don't make sense. If you see something that you think is attack traffic, it's worth opening a support case to see if it really is an attack, and whether we can do something to help.
Internal leakage is a very common source for NXDOMAIN responses. This occurs when you have separate internal and external DNS with the same zone names...for example, you might want to configure A records for "www.mydomain.com" and "mydomain.com", in your external DNS (e.g. on UltraDNS, if you're a customer.) They would be visible for external queries, so customers can reach your servers. You might also want the same names in your internal DNS (possibly with different addresses if you want different WWW servers for internal and external use.) You might also want to have a record for "oursecretserver.mydomain.com" which is configured on internal DNS servers, so your employees can resolve it, but outsiders won't be able to. Normally you would tell internal clients to use your internal DNS servers (often Microsoft AD servers); in that case, UltraDNS should never see internal queries. But if this client configuration is missed, (e.g. you missed configuring it for a particular DHCP scope, or your VPN software doesn't direct DNS queries to the internal servers), queries will typically go to your external DNS servers (such as your UltraDNS servers). This can cause a lot of queries for names which only exist in your internal DNS.
It's often fairly simple to spot this sort of misconfiguration. If a zone has a lot of NXDOMAIN responses, look through the query counts for the zone (or for your entire service if you have Advanced Reporting enabled), and look for NXDOMAIN queries. Once you have a list of names for which we often returned NXDOMAIN, look at the most common names. Look for things like “autodiscover”, "wpad" and for names which are clearly AD related (typically names with things like "_tcp", "_udp", “_msdcs”, etc. in the name; these only make sense in internal DNS. If you find a significant number of internal queries, it's worth investigating. They add to your query count, and more important, they can show that your staff is trying to do things which aren't working, which can interfere with their work.
A final, and increasingly common, reason for NXDOMAIN responses is "qname minimization". In DNS lingo, a "qname" is "the query name" (that is, the name of the record being requested.) Understanding qname minimization requires some understanding of how clients resolve DNS queries. Typically an end user's computer will see a name (e.g. "www.marketing.somebusiness.com"), and will ask the recursive resolver configured for their system. (That is often their ISP's recursive resolver, an internal server, or possibly it's something like Google's 8.8.8.8, or any of a number of other recursive resolvers.) That resolver will typically send the query to the root servers asking "what's the address of 'www.marketing.somebusiness.com'?"; the root servers will reply, saying "I don't know, but ask the servers responsible for .com". Your recursive will then repeat their "what's the address of www.marketing.somebusiness.com'?", but sending it to the servers that know about .com. The .com servers will reply, saying "I don't know about that, but I know that UltraDNS is responsible for 'somebusiness.com'" (Of course it may not be UltraDNS, but since you're on an UltraDNS community page, I'll assume it is...) At this point your recursive server will ask the UltraDNS servers "what's the address of 'www.marketing.somebusiness.com'?", and the UltraDNS servers either reply with the address, tell you that the record doesn't exist, or refer you to yet another DNS server. (NOTE: This is an oversimplified overview, for example, some steps may be bypassed because the answer is already in the recursive server's cache..it's common for the “ask the .com servers” to already be cached, for example.)
Many people are starting to worry about privacy ("I don't want the root servers, the TLD servers, etc. to know what name I really need.") There is now a process called "qname minimization", which means that the recursive resolver tries to avoid giving the full name till it's actually needed. Typically, this is done by stepping through the qname, and replacing all the parts not needed with an "_". So it would ask the root servers for "_.com", then it would ask the .com servers for “_.somebusiness.com”, etc. That tends to mean that you'll see a significant number of queries for "_.yourdomain.com" (or whatever your zone is called). They're actually valid: qname minimization is being standardized as an approach to resolving a DNS query and it does mean that UltraDNS gets a lot of requests for "_" in many of the zones we serve, and they'll send NXDOMAIN responses. For most of these queries (the ones to the root servers, the .com servers, etc.), the response will be a referral to the servers that know the next level (e.g. the .com servers would reply saying "Ask UltraDNS' servers".) But once the query reaches the servers that are ultimately responsible for the domain, the response would be an NXDOMAIN (in this example, the “_.somebusiness.com” query would return NXDOMAIN, indicating “I know about ”somebusiness.com", but there are no records for '_.somebusiness.com'." At that point, the recursive will try again, but with the full qname, and hopefully will get a response with the data the client wants. Unfortunately, this means that UltraDNS often gets and answers two queries (the one with “_” and the one with the full qname, which affects your query count, but it's just part of how DNS works...)
In all of these cases, the reason for the response is that the servers got queries for a particular domain name which doesn't exist; in all of the cases, UltraDNS has to do all the work of a normal query, and has to send some sort of response, so the UltraDNS servers send the appropriate "status: NXDOMAIN" (accompanied "ANSWER: 0") response.
Some NXDOMAINs are simply inevitable. People are fallible, so typos in the qname are just going to happen. Missing records will happen. It's worth looking for these and seeing if you need to update your configuration. The qname minimization queries will just happen, and there's really nothing to do about them.
Attack traffic can't be avoided, though if it is large enough to stand out, UltraDNS may mitigate by blocking clearly bad queries; if you think that there is high attack traffic, you can talk to UltraDNS' support team to see if anything can be done.
As explained earlier, it's very well worth looking for NXDOMAIN responses for qnames that should be internal. It is common to have these be a very significant part of your total queries; that's both expensive and usually indicates that your internal users are having problems accessing information needed for their work. If you do have significant numbers of NXDOMAIN responses for records that should be internal, check your VPN (these queries went WAY up when people started "work from home" because of Covid!) The VPN should ideally redirect DNS queries to your internal servers. The problem can also come from badly configured AD Group Policy, or from one or more DHCP scopes that aren't configured to tell users to use the internal servers.