How do I troubleshoot NXDOMAIN responses when using Route 53 as the DNS service?
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 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, 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:
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: firstname.lastname@example.org 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.
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 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 184.108.40.206#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 220.127.116.11#53(b.gtld-servers.net) in 91 ms example.com. 3600 IN A 18.104.22.168 example.com. 3600 IN A 22.214.171.124 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 126.96.36.199#53(ns-1470.awsdns-55.org) 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 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.
If you have a CNAME record pointing to another domain name, make sure that the canonical name exists and is resolvable.
example.com CNAME record is configured with a value of blog.example.com. In this case, verify that the record blog.example.com 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 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, not 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 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 10.0.0.0/8, then the DNS resolver IP address is 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 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 neg.example.com and receives a response code of NXDOMAIN because 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 when users in other networks can successfully resolve the record.
When the user makes a query to neg.example.com 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:
dig www.example.com @ns-1470.awsdns-55.org
- Anitabuglg...asked a year agolg...
- Is there a way to redirect DNS request to the DNS public zone if a record was not found in the DNS private zone?Accepted AnswerUladzimir Skavinskilg...asked 4 months agolg...
- AWS-User-7355042lg...asked 2 years agolg...
- RKlg...asked 3 months agolg...
- Stevenlg...asked 8 months agolg...
- AWS OFFICIALUpdated 8 months ago
- AWS OFFICIALUpdated 8 months ago
- AWS OFFICIALUpdated 6 months ago
- AWS OFFICIALUpdated 7 months ago
- EXPERTJonathan_Dlg...published a month agolg...