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

Mykoliux
December 7, 2024
161 views
0 votes
2 Answers

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.

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.

Answers

- FediBounouh
- December 7, 2024 at 12:57 am
- 0 votes
0
As mentioned in the screen shot DNS propagation can take up to 48 hours.

To make sure if it’s propagated or not, you can Periodically check your domain using dig or DNS propagation tools:
```
dig NS yourdomain.com
```
but, before the end of the 48 hours, you cannot really know for sure wether there’s an issue or the propagation still need some time.
Login or Signup to reply.

- grawity_u1686
- December 7, 2024 at 10:26 am
- 0 votes
0
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.

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).
Login or Signup to reply.