Why can't I access my website that uses Route 53 DNS services?

Resolution

Check the website's public hosted zone resource records sets

Verify that the public hosted zone for your website's domain name in Route 53 is populated with the appropriate resource records sets. To update the values for records sets, see Editing records. For record type-specific values, see Values that you specify when you create or edit Amazon Route 53 records.

Important: The public hosted zone must contain an address record (A record) for your domain. If a record doesn't exist for the domain name that you queried, then you receive an NXDOMAIN error.

Verify that the resource records sets are publicly accessible

For instructions, see How do I check if resource record sets in my Route 53 public hosted zone are accessible from the Internet?

Check the NS records of the domain name registrar

Check that the name servers (NS) configured at the domain registrar are the same four authoritative NS records in the domain's Route 53 public hosted zone.

1. Get the name servers for a public hosted zone.
2. Use your preferred WHOIS utility (domain registration lookup tool) to search for your website's domain name.
3. Verify that the NS records for your domain in the WHOIS output matches the NS records in your Route 53 public hosted zone.
4. If the NS records don't match and your registrar is Route 53, then update the name servers for your domain. Update the name servers to the four authoritative NS records assigned to your Route 53 public hosted zone.
   Note: For domains registered with third-party registrars, follow your registrar's documentation to change the domain's NS.

Note: It might take until the TTL (up to 48 hours) for the previous registrar's NS to expire from the top-level domain (TLD). During this period, DNS queries for the domain might be sent to both Route 53 and the prior registrar's NS. Route 53 immediately responds to DNS queries for the domain from resolvers that haven't cached the prior registrar's NS.

Check your DNSSEC configuration

If your domain uses Domain Name System Security Extensions (DNSSEC), then DNSSEC must be turned on at the domain registrar and DNS service provider levels.

The DNS resolver that performs DNSSEC validations returns a SERVFAIL error if both of the following are true:

• DNSSEC is turned on for the domain
• DNSSEC is turned off at the DNS service provider

If you use a DNS resolver that performs DNSSEC validation, then you can't access the domain.

The following command returns a SERVFAIL error if DNSSEC is turned on at the domain level, but not at the DNS service provider level:

dig @8.8.8.8 www.example.com

To bypass the DNSSEC validation, run the following command with the +cd flag:

Note: Replace example.com with your domain name.

dig @8.8.8.8 example.com +cd

If you resolve the domain as expected after you bypass the validation, then that indicates a DNSSEC misconfiguration at the NS.

Note: Route 53 supports DNSSEC for both domain registration and DNS service. For more information, see Configuring DNSSEC for a domain and Configuring DNSSEC signing in Amazon Route 53.

Check if the DNS resolution problem occurs when you use other DNS resolvers

Test the resolution for your domain through public resolvers (such as Google Resolver(8.8.8.8), Cloudflare(1.1.1.1), or OpenDNS). If the problem persists when you use a specific resolver, then the cause might be an issue with that particular resolver. Or, the resolver might have cached older DNS responses.

Run the following commands and perform a DNS query against a resolver:

Note: Replace example.com with your domain and ResolverIP with the IP of the resolver that you are using.

dig example.com @<ResolverIP>  
>> nslookup example.com <ResolverIP>

If the resolver received a negative response previously for the domain, then the resolver caches this response. In this case, a client might still receive the NXDOMAIN/NODATA response because of negative caching at the resolver, even if the record was corrected. For more information, see The start of authority (SOA) record.

Verify the EPP status code for your domain

Search for your website's domain name in your preferred WHOIS utility (domain registration lookup tool). Then, verify that the domain isn't assigned an Extensible Provisioning Protocol (EPP) status code. An EPP status code indicates an inactive domain in DNS. Status codes such as serverHold, clientHold, or inactive indicate that the domain isn't activated in the DNS and can't resolve. If Route 53 is the registrar for your domain, then see My domain is suspended (status is ClientHold). For a list of EPP status codes, see EPP status codes on the ICANN website.

Related information

My domain is unavailable on the internet

Registering and managing domains using Amazon Route 53

Using Amazon Route 53 as the DNS service for subdomains without migrating the parent domain

Best practices for Amazon Route 53 DNS