I want to have instead of example.ddns.net example.com as my domain.
I've registered my domain at Amazon AWS
My question: How can I setup that it does this.
I tried to make an CNAME record and entered as Value my ddns.net domain.
But it shows following error.
RRSet of type CNAME with DNS name example.com. is not permitted at apex in zone example.com.
You can never use a CNAME at the apex of a zone, e.g. for example.com. You can only use it for hosts in the zone, such as www.example.com.
Options:
(Simple)
Use www.example.com. Create the CNAME. This will work as expected. You can then use an empty S3 bucket named example.com (the bucket name must be exactly the same as your domain name) along with an Alias record, to create a redirect to www.example.com, described here.
(Really simple)
Use www.example.com as the CNAME, as above, and then create an A record with the IP address shown at the top of this page. This of course is a third party dependency, so, do your due diligence. (I am not affiliated with this company.)
(More complex, but guaranteed to impress your friends)
Create a CloudFront web distribution. Use example.com as the Alternate Domain Name¹ and use the ddns hostname as the Origin Host. Then, in Route 53, create example.com as an A record, set Alias to Yes, and select or type the dxxxexample.cloudfront.net hostname that was assigned to your domain when you created it. Wait until the distribution status in the CloudFront console shows "Deployed." Surf to your site at example.com.
You'll be paying for CloudFront in this scenario, of course, so be sure to familiarize yourself with that.
¹ Alternate Domain Name. The CloudFront documentation also refers to this field as a CNAME. Disregard that. It is apparently a case of an unfortunate dumbing-down of the documentation, presumably because the term CNAME is so often casually used in name-based virtual hosting, so they called it what people expect it to be called. Sometimes this value will correspond to a CNAME record, but obviously not this time.
Related
My setup: On AWS lightsail Wordpress Instance and lightsail DNS zone
I'm not using Route53. Lightsail DNS zone does not support Alias or ANAM record.
I have set up A record for example.com and CNAME for www.example.com pointing to example.com. I have force redirect http to https
I'm still trying to figure out how the distribution work. How can I best set up the distribution for custom domain name without Alias or ANAM record?
Referring to the screenshot from AWS, If I were to set up A record for example.com to point to default domain werhjk3yfhdsfljdsf.cloudfront.net, will there be any downtime if I were to reset cache, disable distribution or change distribution origin?
If I were to set up an A record or CNAME record for www.example.com to point to werhjk3yfhdsfljdsf.cloudfront.net, do I have to disable force redirect for distribution and google analytics to work?
If your DNS provider does not support Alias/ANAME records then you cannot use CloudFront for your root/ape record (example.com).
You can however use it for any subdomain (e.g. www.example.com), this is done by creating the record itself as a CNAME.
A key difference between A records and CNAME records is that an A record accepts an IPv4 address as the value for its record, whereas CNAME (or canonical name) accepts a domain as its value.
If you disable the distribution, yes there would be downtime as you're disabling it. Other changes are gracefully rolled out to the edge locations so you might experience different behaviour where you are in the world.
I use Netlify to host my static site example.com. Since I don't want to append www, I have to use Netlify's DNS nameservers.
example.com uses API backend api.example.com, which is a CNAME record that resolves to an ELB address *.elb.amazonaws.com.
So 2 DNS lookup is required: first to example.com then to *.elb.amazonaws.com.
Alternative:
Setup Route 53 with another custom domain example.org with an ALIAS record api.example.org that points to *.elb.amazonaws.com, and use api.example.org instead of api.example.com for example.com's API endpoints, then it'd have to look up example.com and api.example.org.
Is there any performance advantage advantage choosing the alternative? Would they be similar since the only difference is it has to lookup api.example.org instead of *.elb.amazonaws.com?
Alias records are better than CNAME records, because they return an IP address directly upon resolution.
Example 1:
api.example.com as CNAME for *.elb.amazonaws.com
Your browser will resolve example.com first, download the HTML code, then upon execution of the page, it will need to resolve api.example.com. When it does this, it will:
receive the CNAME result, then
need to resolve *.elb.amazonaws.com
So in the above, there are a total of 3 resolutions required.
Example 2:
api.example.org as ALIAS for *.elb.amazonaws.com
Your browser will resolve example.com first, download the HTML code, then upon execution of the page, it will need to resolve api.example.org. When it does this, it will:
receive the A result (IP address) directly
So in the above, there are a total of 2 resolutions required.
I have a static site hosted in a S3 bucket and a domain registered at Namecheap (e.g mydomain.com)
I would like people to access my site using the bare domain, (i.e without subdomain)
I added a DNS record like so..
Type = CName
Host = #
Value = [URL to S3 bucket]
This works but now emails to mailboxes on that domain (e.g hello#mydomain.com) don't work. I've read that this is because if a CNAME is used to specify the bare canonical name for a host you are not allowed to have any other resource records (e.g MX) for that host.
How can I get around this? I don't want to resort to adding a subdomain like www.
It isn't a valid configurarion to have a CNAME at the apex of a zone like this. The DNS provider should not even allow you to create it. Yes, it breaks your MX if you try it.
That's why Route 53 introduced A-record aliases. See the link mentioned in comments for an explanation. Alias records appear to behave like what people commonly assume a CNAME does, but they aren't CNAMEs and are not invalid at the apex.
To do this right, you need to use Route 53 as your authoritative DNS hosting provider.
One workaround is to create a bucket with www. at the beginning instead of the one you have now, create a www CNAME pointing to it, and then set your # A record to the value provided by a service like http://wwwizer.com, which redirects example.com → www.example.com.
I am not affiliated with that service but I have seen it used for this purpose.
I'm using all infrastructure on AWS and I need:
mydomain.com A ALIAS {S3-bucket- > } s3-website-eu-west-1.amazonaws.com.
www.mydomain.com CNAME mydomain.com
-> website on Amazon S3
*.mydomain.com CNAME {beanstalk} -> myserver-app.elasticbeanstalk.com
-> all other subdomains redirect to the Amazon Beanstalk app
*.mydomain.com MX ->
10 XXYY.in1.mandrillapp.com.
20 XXYY.in2.mandrillapp.com.
-> all emails goes to mandrillapp.
How is possible to do it?
As it's written it doesn't work because of CNAME vs. MX wildcards.
I can't use all names because subdomains will be generated dynamically.
Thank you a lot!!
David
As you have found, you can't have a CNAME and any other type of record at the same level of the DNS hierarchy. Route 53 Alias records, which you're using for your bare domain and for www were created to work around this limitation in the design of DNS, and don't have the same incompatibility issue... but the target of an Alias record can only be one of four things, at the moment: a CloudFront distribution, an Elastic Load Balancer, an S3 bucket of the same name as the hostname in the A record, or another record of the same type in the same hosted zone.
The last two won't help you, but either of the first two could.
If your beanstalk application already has an ELB, you can find that name under Load Balancers in the EC2 console, and you should be able to just use that as your Alias target for the * wildcard A-record Alias for your domain. Or, you could add a load balancer to your beanstalk app, for this purpose.
Alternately, you can create a CloudFront distribution, and configure myapp.elasticbeanstalk.com as the "custom origin" server for the distribition. Configure what CloudFront calls an "alternate domain name (CNAME)" in the distribution for *.example.com -- and, incidentally, disregard the fact that the CloudFront console calls it a "CNAME." They can also be used as Alias targets. Configure the distribution to forward the incoming Host: header to the origin, as well as any other headers you want to forward. Then, you should be able to create your wildcard Alias A record, pointing to the CloudFront distribution, which will forward requests to the beanstalk app.
The problem you're having is an issue with the rules of DNS, which forbid a CNAME record where another record exists.
If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different. This rule also insures that a cached CNAME can be
used without checking with an authoritative server for other RR types.
Is there are particular reason that you want to have a wildcard MX record? I can't see any situation where it provides a benefit, yet many where it would be a very bad idea! (particularly it makes any host on the network a viable target to send spam from, as any host on that can resolve to the domain has permission to send.
If you explicitly name your MX records you can have a CNAME wildcard (actually I might need to check that! but I do believe so)
I’m trying to add a route 53 record set that points to my cloudfront distribution. However, when I select ‘create record set’ in route 53 and click the alias target in the subsequent panel, the cloud front distribution is not listed. All I get is ‘No targets available’. My Distribution has been created and is enabled (and is working). I have added a CName to my distribution with the same domain name that I’m setting up in Route53, but it still doesn’t show.
How do I get my distribution to show in the Alias Target field so that I can point a Route53 ‘a’ record to it?
Thanks
Combining several correct but incomplete answers:
Only A records and AAAA are supported. Not CNAME records.
The Route53 "Alias Target" box matches against CloudFront distributions' "Alternate Domain Names" field. If you're creating a new record set for something.example.com, you should have already set the alternate domain name for one of your distributions to something.example.com.
The Route53 Management Console can be slow, and it might not find your distribution right away — wait until the distribution status is Deployed.
Make sure you have set one or more Alternate Domain Names for you distribution, otherwise it won't be listed on the target combo for Route53 Alias.
As far as I understand, that's the same as configuring ServerAlias on your Apache's VirtualHost (or the correspondent for Nginx and so on). Without it, your requests wouldn't be identified as destined to that distribution when it gets there.
From AWS's documentation:
If you're using CloudFront to distribute your content, you can use Amazon Route 53 to route queries to your CloudFront distribution. The name of your Amazon Route 53 hosted zone (such as example.com) must match an alternate domain name in the CloudFront distribution. You cannot route queries to the CloudFront domain name for your distribution (such as d111111abcdef8.cloudfront.net). The following procedure assumes that you have already registered the applicable domain names.
Make sure it's an A record rather than a CNAME record (weird, I know). I found that buried in the documentation here:
http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-values-alias.html
If your distribution does not show as an alias target, you can always manually copy and paste the d123.cloudfront.net (replace d123.cloudfront.net with the actual DNS name of your distribution) in to the target. This will allow you to create the alias record.
Make sure your CloudFront distribution includes the name of your site (example.com )!
I was having the same issue and spent well over an hour trying to solve the problem...
TL/DR
Set your Origin ID in the origin in your Cloudfront Distribution to be the same as the domain name you are trying to create an alias for
More Detail
I struggled with this for some time.
In the end I compared a working CloudFront distribution which did show up in Route 53 with one that did not.
What I noticed was that the Origin Id specified in the origin for the distribution was not the domain name for my site.
This option is found in: CloudFront Distributions > [Id of distribution] > Origins and Origin Groups > Origins.
I only had one origin listed where the path was the name of a public s3 bucket. This entry also had an Origin ID field. When I updated this to be my domain name (without the www prefix) e.g. testdomain.com then I was able to see this cloud front distribution in the route 53 alias drop down.
You have to fill the Alternate Domain Names (CNAMEs) field e.g. use
www.my_site.com
*.my_site.com
For SSL Certificate field select
Custom SSL Certificate (example.com)
for this you will have to create and verify your domain with ACM, ACM has to be created in Virginia.
After that you will be able to see the Cloudfront in R53.
The trick was to enter the www before the domain because CloudFront matches against that alternate domain name with www or whatever subdomain you use. Type www or your subdomain and it will find the distribution.
It was taking forever for my cloudfront distribution status property to read deployed.
However inputting the cloudfront domain url into my address bar brought me to my website, aka the cloudfront domain url was live.
Feeling impatient, I copied this domain address and pasted it into the alias target field.
It worked!