Let's say a website with the domain www.example.com is hosted on a LAMP server of a webhoster, which is not Amazon. The domain is managed by Route53.
Is it possible to somehow keep all settings on the LAMP webserver and still use www.example.com as the domain for Cloudfront? Like:
Client -> www.example.com -> Cloudfront Edge Server -> Custom origin available over www.example.com on LAMP webserver of third party webhoster
Basically, I want to use www.example.com for both the Cloudfront Edge Server and the LAMP server.
Best regards
You cannot do anything like /etc/hosts on CloudFront -- it always uses public DNS to resolve the origin.
However, you can still do what you are trying to do -- but you just need to understand why this solution is indeed what you want, because it will seem like it is not (as you indicated in comments).
In Route 53, create a new A record for a new hostname for the origin server, such as origin.example.com. You do not configure this value anywhere on your origin server at all. Your origin server still believes it is www.example.com.
In Route 53, create an alias A record www.example.com pointing to origin.example.com.
At this point, your site works exactly as you expect and require. The hostname "origin.example.com" is in the resolution path, but this information is invisible and unknown to the origin.
In CloudFront, create a distribution, setting the origin domain name to origin.example.com and the Alternate Domain Name for the distribution to www.example.com.
In the settings for each Cache Behavior, ensure that the Host header is whitelisted for forwarding to the origin.
Change Route 53's alias for www.example.com to point to your CloudFront distribution.
When requests arrive at CloudFront, the request retains the Host: www.example.com header. CloudFront uses DNS to find the IP address for origin.example.com however, it only uses this information to make the connection to the origin. The incoming request is still addressed to www.example.com. If the origin has an SSL certificate for www.example.com, CloudFront will accept it as valid, because you configured the Host header for whitelisting, and it matches the cert.
In this configuration, accessing the CloudFront distribution with the assigned dzczcexample.cloudfront.net hostname in the browser's address bar will not work, because CloudFront will send that hostname to the origin, but once you point the Route 53 alias for www.example.com to the assigned cloudfront.net domain name, requests will be processed correctly.
Related
In the first place i should say that it might seem a bit weird but its a challenge to distinguish between the level of these configurations,for example ,say i want my localhost be accessible through abc.com, i know i should go through two steps:
1.use iis manager bindings
2.add abc.com to dns host file
127.0.0.1 abc.com
But is not clear for me level of these configs and what is each part's responsibility ?
In a complete url request, steps as follows
User request abc.com.
DNS is request for abc.com.(That is why add abc.com to dns host file)
IP address for abc.com is returned.
Browser send request to the IP address.
IIS in server return site’s page.(That is why use iis manager bindings)
Complete request
Why to use host file
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.
My company changed names recently, so along with that came a new domain. Both the old site and the new site are HTTPS and are on the same server using separate DNS entries.
I setup a 301 redirect which works great if people go to oldsite.com, but if they go to https://oldsite.com they get an SSL error.
Is there any way around this? Hopefully through DNS, server config, or htaccess file.
With TLS/SSL, only one certificate can be presented by the server per IP address. So if oldsite.com is using the same IP as newsite.com, the certificate for https://newsite.com will be the one sent to the client, which will (by definition) raise an SSL error for https://oldsite.com.
To have both oldsite.com and newsite.com both active, you'll have to have separate IPs for each. These can reside on the same server, with some (possibly complicated) routing configuration depending on your server's OS, to ensure requests to each IP are replied to from the same IP. However, even with DNS entries for both, you cannot share an IP address with multiple HTTPS domains.
Edit: You could also use virtual domains (exact config dependent on which web server you're running) to present the certificate for oldsite.com, then send the redirect after the TLS session is in place. I'd have to know which web server you're using (Apache, Nginx, Lighttpd, etc) to give a config example, though.
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.
How do I configure a DNS service provider in such a way that requests to both www.example.com and example.com would show a website hosted on GitHub Pages? My browser's address bar should contain example.com when the website is opened.
My DNS service provider is gandi.net. It doesn't support the ALIAS DNS record type.
Short answer
Step 1: Add a new file CNAME to your GitHub Pages repository containing only one line: your top-level domain name.
E.g.:
example.com
Step 2: [Optional] but highly recommended
2.1: Remove all other top-level records (prefixed with #) of type A from your DNS configuration.
2.2: Remove a CNAME record for the second-level domain www if it is present.
Step 3: Add these 5 entries to the very top of your DNS configuration:
# A 185.199.108.153
# A 185.199.109.153
# A 185.199.110.153
# A 185.199.111.153
www CNAME your_github_username.github.io.
Replace your_github_username with your actual GitHub username.
Step 4: Wait for your DNS changes to propagate.
DNS changes aren't effective immediately. They can take up to a full day to propagate.
Long answer
This issue has two sides. One is the DNS configuration itself. Another one is the way GitHub Pages forwards HTTP requests.
We need to know a few things to understand what GitHub is trying to say in their documentation.
DNS Entry Types
There are two types of DNS records which interest us: CNAME and A.
A is also known as Apex or sometimes as root entry. It forwards requests to a specified fixed IP address. CNAME entry forwards requests to a specified URL (actual valid plain text URL, not an IP address).
DNS Load balancing
GitHub has one central URL address which accepts all DNS requests for GitHub Pages: http://username.github.io. That URL is resolved to different IP addresses based on your geographical location. Website hosted on GitHub Pages is a simple collection of HTML, CSS and JS files. GitHub distributes these files to different servers across the globe. So that when your browser sends a request from Europe it receives data from a server in Europe. The same is valid for the requests from Asia and the USA.
What GitHub is trying to say
Since A records in DNS must contain IP addresses, and they must be either 185.199.108.153 or 185.199.109.153 or 185.199.110.153 or 185.199.111.153, there is no way to forward requests to a server located somewhere in Europe or Asia. Your website hosted at GitHub Pages will be downloaded from a central GitHub Pages server. There is a minor risk that if GitHub Pages DNS servers (x.x.x.153) are down for some reason, all custom domains which use fixed GitHub Pages IP addresses will not be accessible (their DNS requests will not be resolvable).
That is why GitHub strongly suggests to either use a second-level domain for your GitHub Pages (e.g. blog.example.com) or use a DNS service provider that supports a record type ALIAS that acts as A record but forwards request to a URL address (e.g. username.github.io) instead of a fixed IP address.
How GitHub Pages treats HTTP requests
After a DNS request for your_github_username.github.io. is resolved into an IP address, e.g. 185.199.108.153 your browser sends an HTTP request to that server with an HTTP header Host. Below are curl examples that load the same website (these examples might not work if you are behind a proxy server):
$> curl --header "Host: your_github_username.github.io" http://185.199.108.153/
$> curl --header "Host: www.example.com" http://185.199.108.153/
$> curl --header "Host: example.com" http://185.199.108.153/
This way GitHub Pages servers know which user website to serve.
GitHub Pages server will automatically redirect HTTP request to the top-level domain if your CNAME file contains example.com but www.example.com is requested.
The same is valid if your CNAME file contains www.example.com but the header Host in the HTTP request contains example.com.
Why can't I add a CNAME record entry that accepts a top-level request (#) to my DNS configuration?
Quote from the GitHub Pages documentation:
Warning: Do not create a CNAME record for your custom apex domain! Doing so may cause issues with other services, such as email, on that domain.
References:
Setting up a custom domain with GitHub Pages
My custom domain isn't working
Cannot access my GitHub Pages website by IP Address