amazon-web-servicesdnsaws-route53

Route 53 Domain name is not working after creating zone and changing Name Servers for Domain and does not route traffic to CloudFront distribution

I have a question related to Route 53 service and DNS.

I have bought a domain and created a Hosted Zone using Terraform recently. I want to route traffic to my S3 bucket static website through CloudFront. The S3 Bucket provided static website URL seems to be working and opens up my webpage and also after adding it as an origin for the CloudFront distribution the distribution domain name also opens up the website. But when I try to use my domain name it does not work.

I have changed my Domain Name Servers to the ones in my hosted zone NS record after creating new hosted zone. I have also validated certificate and added it to the distribution. I also added two alias records (domain.com and www.domain.com) to my hosted zone. Nothing seems to work, the domain just does not work. Running CLI command nslookup domainname.com returns meesage ";; no servers could be reached".

Route 53 docs tell that after changing the domain Name Servers there might be a need to wait for 48 hours. enter image description here

I was just curious, has anyone had the similar problem that got resolved by just waiting a little longer after changing Name Servers ? Or is there something else that I should do or view ?

Around 11 hours have passed since I changed Name Servers, but nothing has changed.

Solution

  • Route 53 docs tell that after changing the domain Name Servers there might be a need to wait for 48 hours.

    Specifically, the nameservers for the .com TLD publish all domains' NS records with a TTL of exactly 172800 seconds, meaning that resolvers are allowed to cache that information for up to 48 hours.

    Meaning that if you tried to look up your domain before making the change, then your own resolver will still have the old NS records cached for anywhere up to the 48h that they had specified. (Whereas visitors who didn't have the old records cached will see the changes immediately.)

    So the first thing you could check is whether the correct delegation NS records have been published at the nameservers of the TLD:

    1. Find the nameservers of the TLD itself:

      $ dig +short com. NS
i.gtld-servers.net.
f.gtld-servers.net.
[...]

    2. Query one of those servers directly to check what they currently have (bypassing all of your local caches, unless your ISP is doing something funny):

      $ dig example.com. @a.gtld-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.

$ dig +ttlunits example.com. @a.gtld-servers.net.
example.com.            2d      IN      NS      a.iana-servers.net.

      If they have the correct data, then all you should need to do is wait for any locally cached data to expire. (And if they don't have the correct NS records after 11+ hours have passed, then that's a problem that needs to be fixed through your registrar...)


    Note that I wrote this according to .com because that's what you specified in your post, but really this may differ from TLD to TLD; for example, my country's gTLD uses a TTL of just 2 hours – and there may or may not be a delay before the records get published at all (e.g. some nameservers only reload their data every 15 minutes, others do it instantly).