Is it possible to point a top level domain like http://example.com to a amazon cloudfront distribution?
I know it's possible with CNAMEs, but as far as I know, I need to set an A-name record for the top level domain in the DNS settings.
As explained by #dgeske, this can be done.
In my case, I had not purchased the domain from Route 53, and hence had to do extra configuration.
Scenario: You have the following
Cloud front distribution
A second-level domain (example.com) not purchased from Amazon Route 53. It was Google domains in my case, but the idea will work for other providers also.
You want to point the second-level domain (example.com) to the cloud front distribution (as opposed to a subdomain like www.example.com)
Your nomenclature is slightly inaccurate. example.com is not a TLD (top-level domain), it is what is called a second-level domain. See the following image.
Steps to do this.
Create a hosted zone in Route 53.
Route 53 will now give you a list of name servers that you have to set in the domain settings panel of the provider from which you purchased the domain (Google domains in my case).
Go back to Route 53 dashboard, and create an A - Alias record for this hosted zone (use create record set option). Remember to select 'Yes' radio button. Make sure you leave the subdomain part empty (since we are only interested in creating record for second-level domain).
Now you should be able to access your cloudfront distribution at http://example.com.
Depending on your DNS server, it may take a while to get records updated.
You may configure your system to use a public DNS server such as 8.8.8.8 to verify if you are able to access the cloudfront distribution using the URL. I used firefox's DNS over https feature for this. This makes firefox use cloudflare's (not cloudfront) DNS servers. You can also use dig command line utility dig #8.8.8.8 example.com (My domain was fightcoronapune.com, hence, dig #8.8.8.8 fightcoronapune.com) (telling dig to use 8.8.8.8 DNS server to resolve names)
You may additionally get Access Denied error, in which case you will have to configure the default root object for your cloudfront distribution. So that when you visit http://example.com the file http://example.com/index.html is served to you (assuming you specified index.html as default root object). This error has nothing to do with the steps we did above, and you will still get this error even if you directly use your cloudfront distribution's URL given by Amazon (eg. when you go to http://abcd.cloudfront.net directly, instead of going to http://example.com).
Q. Can I point my zone apex (example.com versus www.example.com) at my Amazon CloudFront distribution?
Yes. Amazon Route 53 offers a special type of record called an ‘Alias’ record that lets you map your zone apex (example.com) DNS name to your Amazon CloudFront distribution (for example, d123.cloudfront.net). IP addresses associated with Amazon CloudFront endpoints vary based on your end user’s location (in order to direct the end user to the nearest CloudFront edge location) and can change at any time due to scaling up, scaling down, or software updates. Route 53 responds to each request for an Alias record with the IP address(es) for the distribution. Route 53 doesn't charge for queries to Alias records that are mapped to a CloudFront distribution. These queries are listed as “Intra-AWS-DNS-Queries” on the Amazon Route 53 usage report.
Source: Amazon Route 53 FAQs
My understanding is that you cannot create an A record for Cloudfront.
Amazon provides you with a domain name like YourName.cloudfront.net. They need to manage the DNS resolution for that domain name behind the scenes in order to route each request to the nearest edge server.
you can if you add alias in cloudfront
then select A or AAAA(ipv6 if enabled on cloudfront)
Related
How can I configure a Cloudfront distribution to use multiple s3 origins with same hierarchy but using different domain names?
Currently I have a Cloudfront distribution with a distribution domain name for example xyz.cloudfront.net.
The distribution has been configured to use an alternate domain e.g. assets.example.com and to serve content using that domain I've added cname record in my DNS management console that maps assets.example.com to xyz.cloudfront.net.
Now this set up works fine when serving content from a single s3 origin as i can call something like assets.example.com/images/my-image.png
However I want to configure 3 s3 origins as follows which have identical hierarchies i.e. they all have an images folder:
dev-bucket.s3.eu-west-2.amazonaws.com
test-bucket.s3.eu-west-2.amazonaws.com
live-bucket.s3.eu-west-2.amazonaws.com
If I've configured assets.example.com to map to the distribution xyz.cloudfront.net, how is cloudfront going to know which origin to serve from?
basically if im running the dev website i want cloudfront to serve content from the dev origin and if im running the test site then i want it to serve using the test origin.
The only way i can see how can i achieve this is creating 3 different cloud front distribution for each environment and map different domains to the distribution e.g. assets-dev.example.com, assets-test.example.com and assets.example.com for the live site.
Any advise appreciated.
I'm trying to use Heroku's Automatic Certificate Management to set up SSL for my site. My app is on heroku at myapp.herokuapp.com, and I currently have Subdomain Forwarding set up so that http://www.myapp.com properly shows my app.
What I want is to have my site hosted at https://myapp.com.
I ran heroku certs:auto:enable, but it shows:
=== Automatic Certificate Management is enabled on myapp
Domain Status
───────────────── ───────────
www.myapp.com Failing
Running heroku domains shows:
=== myapp Heroku Domain
myapp.herokuapp.com
=== myapp Custom Domains
Domain Name DNS Target
───────────────── ───────────────────────────────
www.myapp.com www.myapp.com.herokudns.com
Right now, in Google Domains, I have a Subdomain Forward from #.myapp.com to http://www.myapp.com. I also have a Custom Resource Record with the name www, type CNAME, and data myapp.herokuapp.com..
What do I need to change in my setup so that I can host my site at https://myapp.com?
Unfortunately, Google Domains does not support the ANAME or ALIAS record. You must use one of these for your apex domain. Here's the full list supported by Google Domains.
https://support.google.com/domains/answer/3290350
Heroku has a list of DNS providers that support the ALIAS or ANAME records here: https://devcenter.heroku.com/articles/custom-domains#add-a-custom-root-domain Personally, I use DNSimple and have had great success with them.
The CNAME target needs to be www.myapp.com.herokudns.com. In your question above you only have the apex record in your DNS in myapp.com.herokudns.com. If this is not the case can you share the domain so I can dig the record for more information?
I've had the same problem with Heroku and other PaaS providers over and over: depending who provides and manages the DNS for your domain you may or may not able to use a CNAME or ALIAS record on the naked domain. That's why we've created a simple service to solve this by applying a simple SSL redirection from the naked domain to the "www" under SSL, without changing your DNS management provider: NakedSSL will give you an IP and will create and host an SSL certificate for your naked domain (https://yourdomain.com), redirecting it to the HTTPS URL that you want (most likely "https://www.yourdomain.com").
Disclaimer: I'm obviously part of the team that created NakedSSL. I hope you don't take this as self-promotion (anyway we offer it for free for 1 domain, which totally fits the needs of 95% of developers/hobbyist out there), but as a way to deal with this annoying situation in an easy way.
AWS Route 53 / S3 static website
I have a domain / Route 53 hosted zone with several A records. One A record in particular has started producing the error "Failure: DNS resolution failed: Rcode NXDomain(3)" when it attempts to resolve.
user.samtec-atg.com
This is a static website hosted on S3. The S3 link works, but configuring a recordset for this link using either an Alias or CNAME produces the error "Failure: DNS resolution failed: Rcode NXDomain(3)"
Again, I have several S3 websites with the same root domain, but only this link is producing the error.
How can I get this resolved?
As this is the very first item in Google's Search result upon googling the #subj and it has no clear answer, I decided to excavate it.
https://docs.aws.amazon.com/cli/latest/reference/route53/get-health-check.html says:
If you want to check the health of weighted, latency, or failover resource record sets and you choose to specify the endpoint only by FullyQualifiedDomainName, we recommend that you create a separate health check for each endpoint.
So, if you're routing traffic to resources that you can't create alias records for, such as EC2 instances, you create a record and a health check for each resource. Then you associate each health check with the applicable record. Health checks regularly check the health of the corresponding resources, and Route 53 routes traffic only to the resources that health checks report as healthy.
I've ran into this when I tried to perform a health check on on domain name in my private zone in route 53 (instead separate health check for each record/ec2-instance).
It was recognized that your DNS was hosting in two parents so it was reject
I'm having an issue with setting up my Google Apps account.
I believe that my S3 bucket is causing the problem.
I configure the MX records like Google asked me to and today mij DNS providers acknowledged that the records where propagated.
Now when I try to continue the setup of my Google Apps account it's stuck and doesn't provide any info. I have hosted a a static website on a Amazon S3 Bucket.
Trying to see if the MX records are available I used this tool MX Toolbox
to see if my MX records where available but they weren't. Anybody with the same problem or some professional advice?
BTW: the domain name is xntriek.be
What I suspect you will have to do is as follows:
1.) change the settings at your DNS registrar to use a different name server. For my registrar, namecheap, I go to manage -> transfer Name Server to 3rd party (or some variant) -> (leave this screen up - there should be a set of 5+ blank records)
2.) Set up Amazon Route 53.
3.) "Create Hosted Zone" for your domain name in the Route 53 console
4.) This hosted zone should be associated with a "Delegation Set" (right side of R53 console) - 4 records which you will paste into the screen you found in (1) above.
5.) Save that, and configure Route 53 as you would have configured records with your DNS provider. (CNAME aliasing and mx forwarding)
The reason this must be done in R53 and not at the Registrar is that setting the cname record alias to, say, www.yourdomain.com.aws.us-east.amazon blah blah blah tells mx traffic to go to amazon for instructions about what to do. Of course, there are no further instructions for that traffic if you have not set up Route 53.
I hope this helps!
Is there a way to use another bucket name when hosting a site (or indeed any content) than just www.example.com.s3-region.amazonaws.com? I want to use multiple buckets so that when I update the site I can rollback a version if problems arrise and so that updates are an atomic switch between site versions. I only want one bucket used for a domain at a time.
I.e. something like
Bucket Names:
www.example.com.bucket1
www.example.com.bucket2
Procedure:
www.example.com currently points to -> www.example.com.bucket1.s3-region.amazonaws.com
New site version is uploaded to www.example.com.bucket2.
Once verified DNS is changed so that www.example.com points to -> www.example.com.bucket2.s3-region.amazonaws.com
This should not work because S3 looks at the hostname of the request (www.example.com) to find out what bucket you're trying to access so the bucket has to have the same name.
But it is possible to achieve what you want with Amazon CloudFront. There are two options:
You can create a single distribution and only update the origin of it (the S3 bucket).
You can create two different distributions and update the DNS settings to point to the desired distribution. You would also need to update the CNAME properties in both of the distributions (remove www.example.com from the old distribution and add it to the new one).