How do I troubleshoot NXDOMAIN responses when using Route 53 as the DNS service?

8 minute read

I'm receiving an NXDOMAIN response from the DNS resolver, or a DNS_PROBE_FINISHED_NXDOMAIN error when resolving Amazon Route 53 records.


Determine if the domain is in the active or suspended state

1.    Run a whois query against the domain.

Note: Make sure that whois is installed before running the following commands.

For Windows: Open a Windows command prompt, and then enter whois -v
For Linux: Open your SSH client. In the command prompt, enter whois

Note: If the domain is registered with Amazon Registrar, then you can use the Amazon Registrar whois lookup tool.

2.    Check the status of the domain. If the value of Domain Status is clientHold, then the domain is suspended.

Example whois output:

   Domain Name: EXAMPLE.COM
   Registry Domain ID: 87023946\_DOMAIN\_COM-VRSN
   Registrar WHOIS Server:
   Registrar URL:
   Updated Date: 2020-05-08T10:05:49Z
   Creation Date: 2002-05-28T18:22:16Z
   Registry Expiry Date: 2021-05-28T18:22:16Z
   Registrar:, LLC
   Registrar IANA ID: 146
   Registrar Abuse Contact Email:
   Registrar Abuse Contact Phone: 480-624-2505
   Domain Status: clientDeleteProhibited
   Domain Status: clientHold  
   Domain Status: clientTransferProhibited
   Domain Status: clientUpdateProhibited
   Name Server:
   Name Server:
   Name Server:
   Name Server:

To make a domain available on the internet again, remove it from suspended status. The following are the most common reasons that a domain might be suspended:

  • You registered a new domain, but you didn't click the link in the confirmation email.
  • You turned off automatic renewal for the domain, and the domain expired.
  • You changed the email address for the registrant contact, but you didn't verify that the new email address is valid.

For more information, see My domain is suspended (status is ClientHold).

Confirm that the correct name servers are configured on the domain registrar

1.    In the whois output, note the Name Servers that are authoritative for your domain. See the preceding whois output for an example.

You can also use the dig utility to check the configured name servers.

Example dig +trace output:

dig +trace

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.2 <<>> +trace
;; global options: +cmd
.                       518400  IN      NS      H.ROOT-SERVERS.NET.
.                       518400  IN      NS      I.ROOT-SERVERS.NET.
.                       518400  IN      NS      J.ROOT-SERVERS.NET.
.                       518400  IN      NS      K.ROOT-SERVERS.NET.
;; Received 239 bytes from in 0 ms

com.                    172800  IN      NS
com.                    172800  IN      NS
com.                    172800  IN      NS
com.                    86400   IN      RRSIG   DS 8 1 86400 20210329220000 20210316210000 42351 . 
;; Received 1174 bytes from in 104 ms         172800  IN      NS  	------>Name servers of interest.         172800  IN      NS         172800  IN      NS         172800  IN      NS

;; Received 732 bytes from in 91 ms         3600    IN      A         3600    IN      A         3600    IN      NS         3600    IN      NS         3600    IN      NS         3600    IN      NS

;; Received 127 bytes from in 90 ms

2.    Open the Route 53 console.

3.    In the navigation pane, choose Hosted zones.

4.    On the Hosted zones page, select the radio button (not the name) for the hosted zone. Then, choose View details.

5.    On the details page for the hosted zone, choose Hosted zone details.

6.    Confirm that the Name Servers listed in the hosted zone details are identical to the Name Servers in the whois or dig +trace output.

Important: If the name servers aren't identical, then update them at the domain registrar. For domains registered with Route 53, see Adding or changing name servers and glue records for a domain. For domains registered with a third party, refer to the provider's documentation for steps on how to update the name servers.

Confirm that the requested record exists

Check that the hosted zone for the domain contains the requested record. For example, if you're receiving an NXDOMAIN response when trying to resolve, then check the hosted zone for the record. For steps on how to list records in Route 53, see Listing records.

If you have a CNAME record pointing to another domain name, make sure that the canonical name exists and is resolvable.

Example CNAME record is configured with a value of In this case, verify that the record exists and is resolvable.

Check for subdomain delegation issues

1.    Check the parent hosted zone for a Name Server (NS) record for the domain name that you're resolving. If an NS record for a subdomain exists, then the authority for the domain and its subdomains is delegated to another zone. For example, if an NS record for exists, then the authority for www is delegated to the name servers in the NS record. If the delegation is valid, then you must create the record for the domain in the delegated zone, not the parent zone of

2.    If the delegation isn't valid, then delete the NS record for the domain. Confirm that the parent hosted zone ( contains a record for the domain name that you're trying to resolve.

3. Resolvers that implement QNAME minimization include minimum detail in each query, as is required for that step in the resolution process. This might cause an NXDOMAIN issue in some resolvers. When you configure multiple levels of subdomain delegation, follow strict delegation at every level. For more information, see Routing traffic for additional levels of subdomains.

Determine if the DNS resolution issue exists only in the VPC

1.    Check the resolver IP address that's configured on the client operating system (OS). For Linux, check the /etc/resolv.conf file. For Windows, check the DNS servers in the ipconfig /all output. Look for the default virtual private cloud (VPC) DNS resolver (VPC CIDR+2). For example, if the VPC CIDR is, then the DNS resolver IP address is If you don't see the VPC DNS resolver in /etc/resolv.conf, then check the custom DNS resolver.

2.    If you're using the VPC DNS resolver, then check the private hosted zones and Route 53 resolver rules.

When using resolver rules and private hosted zones

If the resolver rule and private hosted zone domain name match, then the resolver rule takes precedence. For more information, see Considerations when working with a private hosted zone. In this case, the DNS query is sent to the target IP address that's configured as the target in the resolver rule.

When using a private hosted zone and no resolver rule

Verify that there's a private hosted zone with matching domain names associated with the VPC. For example, you might have a public hosted zone and a private hosted zone for the domain that's associated with a VPC. This is a split-view or split-horizon DNS. In this case, clients in the VPC can't resolve records created in the public hosted zone. If the record isn't present in the private hosted zone, then the VPC DNS doesn't fall back to the public hosted zone.

When using only resolver rules and no private hosted zone

Check the Route 53 resolver rules. If there's a rule that matches the domain name, then the query for the domain routes to the configured target IP addresses. This means that the query isn't routed to the default public resolvers.

Determine if your issue is the result of negative caching

Negative caching is the process of storing a negative response from an authoritative name server in the cache. An NXDOMAIN response is considered a negative response. Consider the following example:

A client makes a DNS query for and receives a response code of NXDOMAIN because the record doesn't exist.

This user also owns, so they create a new record for The user continues to receive an NXDOMAIN response when users in other networks can successfully resolve the record.

When the user makes a query to before creating the new record, they receive an NXDOMAIN response. If the user turned on negative caching in their resolver settings, then the resolver caches this response. After the user creates the new record, they make the query again. The resolver previously received this query and cached it, so it returned the response from the cache.

There's no record returned in the answer of a negative response, so there's no Time to Live (TTL) value compared to a positive response. In this case, the resolver uses the lowest value from the following:

  • The minimum TTL value of the Start of Authority (SOA) record.
  • The TTL value of the SOA record to cache the NXDOMAIN response.

To confirm this issue, send a query directly to the name server to see if you're getting a response. For example:

AWS OFFICIALUpdated a year ago