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 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: At a minimum, 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 are querying, then a NXDOMAIN error code is returned.

Verify that the resource records sets are publicly accessible

For instructions, see How do I verify that resource record sets in an Amazon Route 53 public hosted zone are accessible from the Internet?

Check the domain name registrar's NS records

Check if the name servers (NS) configured at 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. Search for your website's domain name using your preferred WHOIS utility (domain registration lookup tool).
3. Verify if the NS for your domain in the WHOIS output matches the same NS records in your Route 53 public hosted zone.
4. If the NS records don't match and your domain registrar is Route 53, then update the name servers for your domain at the registrar 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.

If DNSSEC is turned on for the domain but is turned off at the DNS service provider, then DNS resolvers that perform DNSSEC validation return a SERVFAIL error to clients. In this case, clients can't access the domain if they are using a DNS resolver that performs DNSSEC validation.

For example: 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 this command using the +cd flag:
Note: Replace example.com with your domain name.

>> dig @8.8.8.8 example.com +cd

If you can resolve the domain as expected after bypassing the validation, that then usually 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 using other DNS resolvers

Test the resolution for your domain using public resolvers (such as Google Resolver(8.8.8.8), Cloudflare(1.1.1.1), or OpenDNS) to resolve your domain. If the problem persists when using 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 to 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><br>>> 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, which 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, 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 domain names 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