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

Resolution

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

1.    Run a whois query against the domain.    
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.
Note: If the domain is registered with Amazon Registrar, you can use the Amazon Registrar whois lookup tool.

2.    Check that your domain isn't suspended. For more information and how to resolve this scenario, see My domain is suspended (status is ClientHold).

3.    In the whois output, note the Name Servers that are authoritative for your domain.

        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: clientRenewProhibited https://icann.org/epp#clientRenewProhibited
   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.

Another way to check the name servers configured in Linux machine is to use the dig utility.

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

4.    Open the Route 53 console.

5.    In the navigation pane, choose Hosted zones.

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

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

8.    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 you must update them at the domain registrar. If the domain is registered with Route 53, then see Adding or changing name servers and glue records for a domain. If the domain is registered with a third party, then refer to their 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 www.example.com, then check the example**.com** hosted zone for the www.example.com record. For steps on how to list records in Route 53, see Listing records.

Check for subdomain delegation issues

1.    Check the parent hosted zone for a Name Server (NS) record for the domain name you're resolving. If an NS record for a subdomain exists, then the authority for the domain and its subdomains was delegated to another zone. For example, if an NS record for www.example.com 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 (rather than the parent zone of example.com).

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

Determine if the DNS resolution issue exists only in the VPC

1.    Check the resolver IP address 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 VPC DNS resolver (which is the VPC CIDR+2). For example, if the VPC CIDR is 10.0.0.0/8, then the DNS resolver IP address should be 10.0.0.2. 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 overlap, 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 configured as the target in the resolver rule.

When using a private hosted zone and no resolver rule:

Check if there's a private hosted zone with matching domain names associated with the VPC. For example, you might have both a private hosted zone and a public hosted zone for the domain associated with a VPC. Clients in the VPC can't resolve a record that was created in the public hosted zone. The VPC DNS doesn't fall back on the public hosted zone if the record isn't present in the private 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 is routed to the configured target IP addresses instead of 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 neg.example.com and receives a response code of NXDOMAIN. The reason for this response is that the record neg.example.com doesn't exist.

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

When the user made a query to neg.example.com before creating the new record, they received an NXDOMAIN response. If negative caching is turned ON in their resolver settings, the resolver caches this response. After the user created the new record, they made the query again. The resolver previously received this query and had it cached, 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 whichever value is lower: the minimum TTL value of the Start of Authority (SOA) record, or 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:

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