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

Short description

You might receive an NXDOMAIN response or DNS_PROBE_FINISHED_NXDOMAIN error when a DNS resolver can't find the requested domain name. This can be caused by domain suspension, misconfigured name servers, or absent DNS records.

Resolution

Check whether the domain is active or suspended

To check if the domain is active or suspended, complete the following steps.

1. Run a WHOIS query against the domain.
   Make sure that WHOIS is installed before you run the following commands.
   For Windows: Open a Windows command prompt, and then enter whois -v example.com.
   For Linux: Open your SSH client. In the command prompt, enter whois example.com.
   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.

Common reasons for domain suspension:

• The confirmation email wasn't verified after domain registration.
• Automatic renewal was turned off and the domain expired.
• The registrant's email address was changed but never verified.

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

Example WHOIS output:

whois example.com
   Domain Name: EXAMPLE.COM
   Registry Domain ID: 87023946_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.godaddy.com
   Registrar URL: http://www.godaddy.com
   Updated Date: 2020-05-08T10:05:49Z
   Creation Date: 2002-05-28T18:22:16Z
   Registry Expiry Date: 2021-05-28T18:22:16Z
   Registrar: GoDaddy.com, LLC
   Registrar IANA ID: 146
   Registrar Abuse Contact Email: abuse@godaddy.com
   Registrar Abuse Contact Phone: 480-624-2505
   Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
   Domain Status: clientHold https://icann.org/epp#clientHold  
   Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
   Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
   Name Server: ns-1470.awsdns-55.org.
   Name Server: ns-1969.awsdns-54.co.uk.
   Name Server: ns-736.awsdns-28.net.
   Name Server: ns-316.awsdns-39.com.

Confirm that the correct name servers are configured

You can view authoritative name servers by using the WHOIS output or the dig +trace command.

To verify hosted zone settings in Route 53, complete the following steps:

1. Open the Amazon Route 53 console.
2. In the navigation pane, choose Hosted zones.
3. Choose the hosted zone you want, and then choose View details.
4. Choose Hosted zone details.
5. Compare the listed name servers with those in the WHOIS or dig +trace output.

Important: If the name servers differ, then update them at your domain registrar.

• For domains registered in Route 53, see Adding or changing name servers and glue records for a domain.
• For domains registered elsewhere, refer to the provider's documentation.

Example dig +trace output:

dig +trace example.com  
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.2 <<>> +trace example.com
;; 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 10.0.0.2#53(10.0.0.2) in 0 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
C41A5766
com.                    86400   IN      RRSIG   DS 8 1 86400 20210329220000 20210316210000 42351 . 
;; Received 1174 bytes from 192.112.36.4#53(G.ROOT-SERVERS.NET) in 104 ms

example.com.         172800  IN      NS      ns-1470.awsdns-55.org.  	------>Name servers of interest.
example.com.         172800  IN      NS      ns-1969.awsdns-54.co.uk.
example.com.         172800  IN      NS      ns-736.awsdns-28.net.
example.com.         172800  IN      NS      ns-316.awsdns-39.com.

;; Received 732 bytes from 192.33.14.30#53(b.gtld-servers.net) in 91 ms

example.com.         3600    IN      A       104.200.22.130
example.com.         3600    IN      A       104.200.23.95
example.com.         3600    IN      NS      ns-1470.awsdns-55.org.
example.com.         3600    IN      NS      ns-1969.awsdns-54.co.uk.
example.com.         3600    IN      NS      ns-736.awsdns-28.net.
example.com.         3600    IN      NS      ns-316.awsdns-39.com.

;; Received 127 bytes from 173.201.72.25#53(ns-1470.awsdns-55.org) in 90 ms

Confirm that the requested record exists

In the hosted zone, check if the requested record exists.

If you use a CNAME, then confirm the target domain (canonical name) also exists and is resolvable.

For example, if the example.com CNAME record is configured with a value of blog.example.com, then verify that the record blog.example.com exists and is resolvable.

Check for subdomain delegation issues

To check for subdomain delegation issues, consider the following actions:

• Look in the parent hosted zone for NS records for the domain. For example, if www.example.com has an NS record, it's delegated.
• If delegation is valid, add the record to the delegated zone.
• If delegation isn't valid, delete the NS record and add the record to the parent zone.

Note: QNAME minimization in DNS resolvers might cause NXDOMAIN errors with deep subdomain delegations. For more information, see Protection from dangling delegation records in Route 53.

Determine if the DNS resolution issue exists only in the VPC

Check if the DNS resolver is configured on your operating system.

• For Linux: Open the /etc/resolv.conf file.
• For Windows: Run the following in Command Prompt: ipconfig /all

Look for the DNS resolver address. If the virtual private cloud (VPC) CIDR is 10.0.0.0/8, then the resolver should be 10.0.0.2.

If you're using the Amazon Virtual Private Cloud (Amazon VPC) resolver, review the following scenarios:

Scenario A: You have both a resolver rule and a private hosted zone

• The resolver rule takes precedence.
• The DNS query is forwarded to the IP address in the resolver rule.

For more information, see Working with private hosted zones.

Scenario B: You only have a private hosted zone

• Clients inside the VPC can't resolve records in the public zone.
• This configuration is called split-horizon DNS.

Scenario C: You only have a resolver rule

• The DNS query is forwarded to the configured IP address.
• The default public resolvers aren't used in this case.

Check whether the issue results from negative caching

An NXDOMAIN response might be cached by the resolver if negative caching is active.
Example scenario:

• You query neg.example.com, and it doesn't exist.
• The resolver caches the NXDOMAIN result.
• Later, you create the record, but the resolver still returns NXDOMAIN.

Resolvers use the following to determine how long to cache negative responses:

• The minimum TTL from the SOA record
• The TTL of the SOA record (whichever is lower)

To confirm whether negative caching is active, send a query directly to the name server to get a response, such as in the following example:

dig www.example.com @ns-1470.awsdns-55.org