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)
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'm replacing a legacy website with a new one, in stages. From a user perspective, all existing URLs must remain the same, but certain paths should serve new pages.
I have two origin servers: the legacy one (www.mysite.com) and the new, EC2 one (www.ec2-loadbalancer.com) – obviously mock URLs for privacy reasons.
I've created an AWS CloudFront distribution with a CNAME setting of www.mysite.com. Within this distribution I've created two origins domains:
www.mysite.com
www.ec2-loadbalancer.com
Within CloudFront I've configured some behaviours so that paths like /foo are sent to my EC2 load balancer origin, and all other paths (eg. default) are sent to www.mysite.com.
From a DNS perspective, I've added a CNAME record of www.mysite.com which points to my Cloudfront host domain (eg. foo.cloudfront.net.). The A record for this domain points to the IP of the legacy server.
I launched all of this today and it seems to have worked, but I'm seeing intermittent 403 errors on the site, and two hours after making the change (there was no "www" CNAME before, so TTL shouldn't make a difference), some browsers are still serving the site from the original IP (rather than the CloudFront one).
Have I configured this properly? I couldn't work out how to do this via the A record – that points to the IP of the legacy server, and CloudFront doesn't allow me to enter an IP address as an origin. Should I have pointed the www CNAME at the IP address, made the A record point at CloudFront instead? I'm a bit lost here.
On the other hand, it could all be a propagation thing, but I'm wary having seen 40x errors hours after making the change.
i think you should create an A record (for the named domain name) with an alias pointing to the cloudfront distribution. It should solve the problem.
i.e. Use Alias name instead of IP address and point your domain to cloudfront:
It's a shame you can't share the domains with us to help debugging, but at the very least, dig is your friend. For instance:
$ dig membership.theguardian.com
...
;; ANSWER SECTION:
membership.theguardian.com. 367 IN CNAME i.global-ssl.fastly.net.
i.global-ssl.fastly.net. 12 IN A 151.101.128.67
i.global-ssl.fastly.net. 12 IN A 151.101.64.67
i.global-ssl.fastly.net. 12 IN A 151.101.0.67
i.global-ssl.fastly.net. 12 IN A 151.101.192.67
...tells you that membership.theguardian.com is pointing to Fastly by CNAME. You can check with alternate DNS servers, like Google's DNS on 8.8.8.8, by doing this:
$ dig #8.8.8.8 membership.theguardian.com
...so you can see how other people are resolving your domains.
From a DNS perspective, I've added a CNAME record of www.mysite.com
which points to my Cloudfront host domain (eg. foo.cloudfront.net.).
The A record for this domain points to the IP of the legacy server.
I'm not a DNS expert, so it's possible I'm not understanding you here, but this sound like it introduces ambiguity? To me this sounds like you have two different records for the same www.mysite.com domain, one of which points to CloudFront, and the other to the IP of your legacy server. Depending on how that gets resolved a browser could be sent to one or the other?!
www.mysite.com should point only to CloudFront. I would personally just use a CNAME for this.
You should have unambiguous addresses for both your legacy server and your EC2 Elastic Load Balancer - I would personally give them their own clear domain names, to avoid confusion (eg. legacy.mysite.com & beta.mysite.com) - and in CloudFront refer to only to those clear names when you're directing traffic (eg. passing traffic on to www.mysite.com as a way of going to the legacy server would be confusing).
Good luck!
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.
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 used the AWS certificate manager to create an ACM certificate.
I followed this guide: https://medium.com/#arcdigital/enabling-ssl-via-aws-certificate-manager-on-elastic-beanstalk-b953571ef4f8#.kjh1mqdzq to configure the load balancer using the aws cli.
When I look at my load balancers, I now see 443(HTTPS, ACM Certification:[arn]) forwarding to 80 (HTTP) under Port Configuration
However, if I type in https in my browser I get the "your connection is not private" message from chrome.
Is there another step that I'm missing?
You haven't given this info, but I'm assuming you have a CNAME for www.yourdomain.com that is resolving to loadbalancer.amazonaws.com.
You are getting the ERR_INSECURE_RESPONSE error because you are using a CNAME which is resolving to loadbalancer.amazonaws.com. Since your certificate is for www.yourdomain.com, it is giving a valid error. CNAME and Alias operate slightly differently. With a CNAME the traffic is not a valid alias of your domain so if you're trying to secure it, you will receive errors. However, when you create an A record for www and alias that to loadbalancer.amazonaws.com now any traffic from loadbalancer.amazonaws.com on www.yourdomain.com is valid traffic for your domain and you will no longer have those errors.
In order to terminate secure traffic for www.yourdomain.com at loadbalancer.amazonaws.com you need to have an A record that will alias there. Unfortunately, ELB's only provide a DNS entry, no IP address, but many DNS providers (ie GoDaddy) will not allow you to have a DNS A record that is aliased to a DNS address; they require you to alias to an IP address. Which makes life a bit more complex.
There are a couple ways to accomplish this (URL forwarding and masking is not supported by SSL), but the easiest solution is to use Route 53. Use of Route 53 doesn't require you to register or transfer your name to AWS and a hosted zone is just $0.50/month per domain.
To use Route 53 follow these steps:
Create a Hosted Zone for yourdomain.com. When you create a Hosted Zone in Route 53 it will complete a few default records (like an A, NS, and SOA records). Note the NS records as you'll need them later.
Next copy your existing zone file entries (like MX records) from your current DNS provider to your new hosted zone.
When it comes to a record that you want to direct traffic for to your ELB you'll enter the name, say www, and then just below the type option field you'll see a radio option that says "Alias: yes no". - - When you select yes, the value field will disappear and you'll see an option that says "Alias Target: Enter Target Name". When you click that field you'll receive a drop down list of resources in your account that you can alias to. Simply select your load balancer.
Click create, and you're done with Route 53.
Now that all your dns records are copied over, and you'll go to your registrar and change the nameservers to the ones that Route 53 provided you.
Now Route 53 is handling your DNS for you. And loadbalancer.amazonaws.com is a valid alias of www.mydomain.com. Since loadbalancer.amazonaws.com is now a valid alias of www.yourdomain.com when you visit www.yourdomain.com your ELB at loadbalancer.amazonaws.com will terminate the traffic as www.yourdomain.com and your error will be resolved.