How do I troubleshoot NXDOMAIN responses when using Route 53 as the DNS service?
Last updated: 2021-04-09
I'm trying to resolve Amazon Route 53 records. However, I'm receiving an NXDOMAIN response from the DNS resolver, or a DNS_PROBE_FINISHED_NXDOMAIN error. How can I troubleshoot this?
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. In the whois output, note the Name Servers that are authoritative for your domain.
Example whois output:
whois testdomain.com Domain Name: TESTDOMAIN.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: firstname.lastname@example.org 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 testdomain.com ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.2 <<>> +trace testdomain.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 184.108.40.206#53(G.ROOT-SERVERS.NET) in 104 ms testdomain.com. 172800 IN NS ns-1470.awsdns-55.org. ------>Name servers of interest. testdomain.com. 172800 IN NS ns-1969.awsdns-54.co.uk. testdomain.com. 172800 IN NS ns-736.awsdns-28.net. testdomain.com. 172800 IN NS ns-316.awsdns-39.com. ;; Received 732 bytes from 220.127.116.11#53(b.gtld-servers.net) in 91 ms testdomain.com. 3600 IN A 18.104.22.168 testdomain.com. 3600 IN A 22.214.171.124 testdomain.com. 3600 IN NS ns-1470.awsdns-55.org. testdomain.com. 3600 IN NS ns-1969.awsdns-54.co.uk. testdomain.com. 3600 IN NS ns-736.awsdns-28.net. testdomain.com. 3600 IN NS ns-316.awsdns-39.com. ;; Received 127 bytes from 126.96.36.199#53(ns-1470.awsdns-55.org) in 90 ms
3. Open the Route 53 console.
4. In the navigation pane, choose Hosted zones.
5. On the Hosted zones page, choose the radio button (not the name) for the hosted zone. Then, choose View details.
6. On the details page for the hosted zone, choose Hosted zone details.
7. 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.testdomain.com, then check the testdomain.com hosted zone for the www.testdomain.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.testdomain.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 testdomain.com).
2. If the delegation isn't valid, then delete the NS record for the domain. Confirm that the parent hosted zone (testdomain.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.testdomain.com and receives a response code of NXDOMAIN. The reason for this response is that the record neg.testdomain.com doesn't exist.
This user also owns testdomain.com, so they create a new record for neg.testdomain.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.testdomain.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.testdomain.com @ns-1470.awsdns-55.org