Cloudfront setup for main domain without using route53 - dns

We are planning to use cloudfront distribution for our main domain and the setup will be as follows.
Cloudfront Origin - route.domain.com -> Remote Server IP address(xx.xx.xx.xx)
www.domain.com, domain.com -> d123.cloudfront.com
As we know, we can setup CNAME for www.domain.com to point to cloudfront distribution(d123.cloudfront.net). However, for domain.com we should point A record to IP address and its not possible to setup CNAME record.
In route53, there is an option called Alias which can be used to point the domain to Cloudfront. But, our domain.com nameserver uses different provider and we would like to stick with current nameserver.
Any help would be appreciated.

Since this is a limitation in DNS itself, there is no way to accomplish this without a DNS hosting provider that supports an alias-like feature, sometimes called an "ANAME" or "flattened CNAME". Route 53 is of course the canonical example. CloudFlare and DNS Made Easy are others.
Or use a service like this one¹ to redirect your naked domain name to the www address, which would be your "real" site. They give you a single IP address for your A record. Note that your current DNS provider may have a "redirection" option that does this. It is not properly a part of DNS, but some providers allow you to configure domain redirections in their DNS portal.
Or migrate your DNS hosting to Route 53, keeping your DNS registration with your current vendor. In my mind, there is really no compelling reason not to use Route 53. See Making Route 53 the DNS Service for a Domain That's in Use for migrating to Route 53 without disruption, noting that the final step -- Transfer Domain Registration to Amazon Route 53 -- is entirely optional, as mentioned in the docs.
¹ this one is not a service I am affiliated with or have ever used in production, because I built my own service for that purpose using EC2, which is another option but outside the scope of this answer. This is intended as an example, not an endorsement.

Related

How to point DNS at a dynamic IP address?

Bluehost is my DNS provider and my app is hosted on heroku. I'm trying to point the DNS at my heroku app but there's an issue. Heroku's documentation states the following:
Some DNS providers will only offer A records for root domains. Unfortunately, A records will not suffice for pointing your root domains to Heroku because they require a static IP. These records have serious availability implications when used in environments such as on-premise data-centers, cloud infrastructure services, and platforms like Heroku. Since Heroku uses dynamic IP addresses, it’s necessary to use a CNAME-like record (often referred to as ALIAS or ANAME records) so that you can point your root domain to another domain. See examples below.
They go on to recommend creating a CNAME record with the values # and your root domain alias, e.g. hidden-sierra-7936.herokudns.com.
But Bluehost won't allow this because they want an IPv4 IP Address only and won't accept something like hidden-sierra-7936.herokudns.com as a valid CNAME record. I've already done the www record and things aren't working, so I'm guessing I need the ANAME record as well.
Is there any way around this other than switching to a new DNS provider?
Bluehost does not support this. Google and Cloudflare do, perhaps others. Cloudflare worked for me.

Amazon Route 53 DNSSEC support

We are trying to decide which DNS hosting solution to use. Today we use Power DNS and we want to move to a hosted DNS solution. The best solution for us would be using Amazon's Route 53 for this.
We are mandated to use DNSSEC for our DNS solution and I have been trying to understand what Amazon's DNS supports and what it doesn't.
Amazon's site says:
Amazon Route 53 supports DNSSEC for domain registration but does not support DNSSEC for DNS service. If you want to configure DNSSEC for a domain that is registered with Amazon Route 53, you must use another DNS service provider.
http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-configure-dnssec.html
Can anyone explain what this means? In particular what is supported and what isn't as well as what does using another DNS service provider for a domain that is registered with Route 53 mean.
Route 53 offers two¹ different services:
a DNS hosting provider, providing authoritative DNS hosting in hosted zones
a domain registrar, allowing you to register new domains for use on the Internet (or transfer the registration of existing domains so that your annual registration fees are consolidated into your AWS account bill)
Those two services have no necessary connection to each other. You can register a domain with any accredited registrar (for example, let's say GoDaddy), and still host the DNS with Route 53... or you can register a domain with Route 53 and still host the DNS elsewhere (for example, let's say Dyn)... or you can use Route 53 for both services, since they are independent.
Amazon Route 53 supports DNSSEC for domain registration
So, if you register a domain with the Route 53 Registrar, it can be configured to use DNSSEC...
but does not support DNSSEC for DNS service.
...but not if you use Route 53 hosted zones for authoritative DNS hosting, which does not support DNSSEC, regardless of who the registrar is.
Therefore...
If you want to configure DNSSEC for a domain that is registered with Amazon Route 53, you must use another DNS service provider
...to host your authoritative DNS records. You can't use a Route 53 hosted zone with DNSSEC.
¹ two different services that are relevant here. The emphasis is intended to be on different, because many other service providers blur the distinction between domain registration and authoritative DNS hosting to the point that many users seem unaware that they can almost always be decoupled, in at least one direction, regardless of the providers in question. Also under the "Route 53" banner are other services like Route 53 Resolver (which deals primarily with recursive querying in VPC and/or on-premise) and Route 53 Health Checks (which can be used as a basis for DNS failover as well as for other health-checking and latency-measuring purposes that can be but aren't necessarily even DNS related).
DNSSEC is now supported by AWS Route 53 for both DNSSEC signing (Hosting service) and domain registration (Registrar service).
Please follow the official guide to configure DNSSEC signing of the hosted zone here
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec.html

Setting up a private domain for Swisscom Cloudfoundry

most domain providers don’t allow setting a CNAME record for a main domain. It’s usually only possible to set CNAME records for subdomains.
So now I’m wondering if it would be possible to set an A record instead, pointing to scapp.io’s IP address. I tried it yesterday and it seems to work great but I’m worried that IP address might not be stable.
Any ideas whether setting an A record to 194.209.246.110 is a valid option for configuring a "naked" domain?
We don't recommend A record to IP address. The IP addresses may change without prior announcement.
See docs.developer.swisscom.com -> DNS for Domains for other options than CNAME.
Configuring DNS for Your Registered Root Domain
To use your root domain (for example, example.com) for apps on App
Cloud you can either use custom DNS record types like ALIAS and ANAME,
if your DNS provider offers them, or subdomain redirection.
Note: Root domains are also called zone apex domains.
If your DNS provider supports using an ALIAS or ANAME record,
configure your root domain with your DNS provider to point at a shared
domain in App Cloud.
What domain provider do you use?

SSL domain does not match ec2 DNS name

My website is hosted with Firebase Hosting, and I want to make a http post to a NodeJS process running on AWS EC2 instance.
First fail: EC2 was http, I had an error of mixed content (https and http).
Next, I put in a load-balancer in-front of the EC2 instance, and installed my domain certificate (www.mydomain.com)
Second fail: I get an ERR_INSECURE_RESPONSE error, as loadbalancer.amazonaws.com does not match www.mydomain.com
I am at wit's end in resolving what I think is a straight-forward use-case. Please help.
Two options.
You need to register your domain with Amazon, so you can create a Hosted Zone in AWS Route53. There, you can create a record to point "mydomain.com" to your load balancer.
The other option is with your current register (GoDaddy or someone else), to Forward your domain to your load balancer. You will probably need to enable "Forwarding with Masking" so it still looks like your domain, but is served by the AWS load balancer.
Let me know what works (or doesn't) and I'll update this answer.
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.
Side note: If your instances are in us-east-1 you can get an unlimited number of free standard, SAN, and wildcard SSL certificates for your ELB and domain using Certificate Manager.

How to map domain to hosting server

My client have a dedicated server on liquedweb cloud service and we my web app is hosted on that server. We want our users to map their domain to our server. So they can enjoy our web app by using their domain name. What information I need to provide to my user so he can map domain and what information I need from them?
I don't know much(in fact anything) about domain mapping
thanks
It depends if the server has a dedicated IP address or is natted.
If the server has a dedicated IP address you can ask your clients to point their entire domain to you server by adding the following A records:
Host TTL Protocol Type IP Address
# 300 IN A 1.1.1.1
www 300 IN A 1.1.1.1
Not all domain hosts ask for TTL,if not dont worry about it.
If you want just their subdomain to point to your server (subdomain.website.com)
subdomain IN A 0.0.0.1
TTL is optional in some systems, in this case the default will be used.
Generally it is recommended that you use an IP for the Apex record and not a domain name. EG: example.com is the apex, www.example.com is the www subdomain.
A typical configuration would be below:
Host TTL Protocol Type Result
# 300 IN A 1.1.1.1
www 300 IN CNAME example.com
This is the same config as the top example but using CNAME example.com. It is the same as using A 1.1.1.1, it just means you only need to change one record.
If your server details are a hostname and not an IP address, most systems will not let you use the hostname for the apex so you will need to find out the IP address. (A simple method is to use the nslookup command or dig command).
TTL is how long in seconds a record last before it expires. If you are unsure what you are doing I recommend lowering this so you can correct mistakes more quickly.
Different methods for the different servers. For most of the servers, you have to change the nameservers of your domain.
This mostly needs when your domain registrar and hosting provider both are different.
First Login into your hosting account, navigate to the account details,
then copy the nameservers from there...which would be like :- dns1.hostingprovider.com
dns2.hostingprovider.com
After that, Go to control panel of your domain. Navigate to the nameservers
You will see the link:- dns1.domainregistrar.com
dns2.domainregistrar.com
Paste the above links at the place of below links.
They need the IP address (and possibly instructions on how to configure their DNS servers (which means a variety of different sets of instructions for different servers and control panels)).
You need the domain name.

Resources