I have a React website which I would like to host on AWS Cloudfront with custom domain.
I created s3 bucket with option for static content hosting and I created Cloudfront distribution.
I can open the Cloud distribution using the distribution domain name d1srvdzuzxvion.cloudfront.net
I created a hosted zone and I added DNS records
But again when I open the domain into my browser it's not working. Can you advise what might be wrong?
The NS records you show above, do not actually match what a DNS lookup is returning:
NS-1337.AWSDNS-39.ORG
NS-1871.AWSDNS-41.CO.UK
NS-245.AWSDNS-30.COM
NS-842.AWSDNS-41.NET
https://whois.domaintools.com/hireya.org
You are going to need to figure out that one first.
Looks like you enabled DNSSEC but did not configure it properly. Whois returns DNSSEC: unsigned
This tool reports no DS records found https://dnssec-analyzer.verisignlabs.com/hireya.org. You either need to configure these records or disable DNSSEC.
More info https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-configure-dnssec.html
Related
I have a domain that I got from NameCheap: www.app.flerr.io.
I configured the domain in AWS with Route53, CloudFront and S3.
I uploaded the static website to the relevant S3 bucket.
When I try to reach my website, I get the following error: ERR_NAME_NOT_RESOLVED.
Although, when I reach the website through S3 static website hosting it's working:
Any ideas?
EDIT:
Route53:
I have one A record that traffics to <id>.cloudfront.net:
I have one NS record that traffics to 4 NS URLs.
I have one SOA record.
I have one CNAME record.
ERR_NAME_NOT_RESOLVED usually refers to a DNS problem.
You already verified that S3 URL is working correctly.
Now, verify that Cloudfront is working correctly by pasting the Cloudfront URL in your browser (<id>.cloudfront.com or something similar).
If both of them are working, means that your problem is indeed DNS (and therefore Route53) related.
Use any DNS Lookup page to see if your domain (flerr.io) is correctly set up.
https://mxtoolbox.com/SuperTool.aspx?action=a%3awww.app.flerr.io&run=toolpage
With the information given that's the best we can do, if you share your Route53 Hosted Zones we could see if anything is wrong
If you bought flerr.io. - you dont need to create a new zone for app.flerr.io. (you can, but its not required - this is called DNS delegation). You just need to create a record named www.app inside flerr.io. as an A or CNAME to your destination.
When i use dig to test the DNS i get the following results:
dig flerr.io. shows A records
dig app.flerr.io. shows A records - and appears to be its own DNS delegation zone (was that deliberate)?
dig www.app.flerr.io. does not return any records - this is why you cant resolve your site.
I think the solution for you is to create the www.app records in the flerr.io. zone and ignore the app.flerr.io. zone you created. If your trying to use the zone app.flerr.io. (and its been setup properly in flerr.io.) you would just create the www record.
I am having trouble setting up DNS with Namecheap pointing to a static html website hosted in AWS S3.
Bucket config:
Currently, I get "chrisrich.io redirected you too many times."
This is the direct bucket url:
https://s3-ap-southeast-2.amazonaws.com/chrisrich.io/index.html
AWS S3 bucket name:
DNS settings in Namecheap:
What am I doing wrong?
There are two things:
The DNS record in Namecheap is for www.chrisrich.io and it's resolving to S3.
dig www.chrisrich.io +short
chrisrich.io.s3-ap-southeast-2.amazonaws.com.
s3-r-w.ap-southeast-2.amazonaws.com.
52.95.134.34
To make it work with www.chrisrich.io, you need to have the bucket name exact same name as www.chrisrich.io.
You can create a bucket with name www.chrisrich.io and put the files there , it should allow you to access your website using www.chrisrich.io.
You cannot have CNAME record for Apex domain chrisrich.io , it means you need to see if (URL forwarding) option available in Namecheap and chrisrich.io to www.chrisrich.io.
Also, Website endpoint doesn't support HTTPS, if you're planning to make your website work on https, you'll need cloudfront.
Also, to make S3 website endpoint work using www.chrisrich.io, you need to change your DNS record, currently you're using the REST API name for the CNAME record, chrisrich.io.s3.ap-southeast-2.amazonaws.com --> this should be the name of S3 website endpoint otherwise, index page won't load automatically and you will need to access it using www.chrisrich.io/index.html
You need to change your bucket name from chrisrich.io to www.chrisrich.io
Then, it will work.
Thanks
I am trying to direct a URL request to an AWS S3 bucket.
So far I have done the following:
Create a bucket with the name app-name.app (domain is .app)
Make the bucket public and set property as a static website.
Website works fine when directly accessed through the S3 ARN.
Now I need to direct my (Godaddy) hosted domain name to this S3 bucket.
These are the steps I've taken:
Create a hosted zone in Route 53
Create record sets for A, NS and SOA types.
This is how it looks like:
After that I set the same NS server names in to Godaddy domain. I then also received an email from Godaddy stating that the nameservers have been changed.
However, I am not able to access the site through the domain name. It times out.
Appreciate some help figuring out what step I am missing.
Thank you.
1-Make sure your DNS changed correctly, by ping and trace.
2-Use DNS tools like mxtoolbox to check the records.
3-Add CNAME record with your S3 website public URL(It's different as S3 general URL), for example, add www.
I have recently set up a static website using an AWS S3 bucket (scottreganchimneysweeping.co.uk). I have provisioned an SSL certificate through AWS, changed nameservers with my registrar to AWS route 53, created a hosted zone with route53 and also a CDN using cloudfront.
However, when I type the URL into Chrome, it loads for ages and then brings up a 403 error, IP address not found.
In route 53, I have created an A record with the alias for the cloudfront CDN, as well as the CNAME record for the SSL certificate and the default NS and SOA records. I'm not sure what exactly is causing the issue here but I am a total beginner with hosting and DNS etc so I desperately need help to get this website live.
Could anybody suggest where I have gone wrong here or possible diagnose using the domain name above?
Thanks in advance!
403 means that the requester does not have permissions to take the action requested. You may need to either set the ACL of the bucket to public read, or the ACL of the items you want to be public read.
When a bucket is not set to be publicly readable, even if it is set up as a static site already, all missing pages will show up as a 403 response, so another possibility is that the default path is not set to the correct file, e.g. default pointing to index.html whereas you have main.html in your bucket at the root.
I have tried setting up a static hosting solution for our web platform by using AWS S3 and CloudFront. It is required to use https, and it needs to be accessed via a custom subdomain.
This is my S3 bucket:
These are the settings for the CloudFront:
The certificate settings look ok to me:
And finally my DNS record is like this:
CNAME: "static" -> "d1fd407fp9coo4.cloudfront.net."
edit: using my default domain provider for DNS, not Route 53.
The aim is to have the resource available at static.dmaglobal.com/logo-frontpage.png via https. It loads fine without (http://static.dmaglobal.com/logo-frontpage.png), but the https-version (https://static.dmaglobal.com/logo-frontpage.png) gives an SSL-error stating the current certificate is for *.s3.eu-west-2.amazonaws.com instead of *.dmaglobal.com. I do not understand where this mismatch comes from, as it seems like the current certificate is correctly set up for our custom domain.
Anyone able to give some pointers on how to proceed from here with this issue?
As you have noticed your DNS record resolves to S3 still.
Instead of CNAME you should create an ALIAS record to Cloudfront distribution. In static record pick A type record, check Yes for Alias and pick the Cloudfront distribution on the dropdown.
The reason for this: ALIAS records are free of charge and they resolve faster.
To answer my own question: In the end, it was the proper CNAME value that had not propagated properly yet (as it was initially pointing to S3 before I was aware that CloudFront was required for SSL). As soon as it was, the settings in the OP worked perfectly.