I am looking for an easy way to fail over to a different DC quickly, does CloudFlare offer anything special in this regards with things like health checks or is it just like a standard DNS service?
Update: CloudFlare started a closed beta for the Traffic Manager feature which allows to do exactly this kind of failover:
https://www.cloudflare.com/traffic-manager/
AWS Failover:
The following solution seems to work well when you are hosting your backend system on AWS:
I setup a AWS Route 53 zone with a separate domain (e.g. failover-example.com). Route 53 allows you to setup health checks on the backend server (e.g. the load balancer) with DNS failover. AWS will remove the unhealthy backend system from the DNS record list.
In cloudflare I setup a CNAME for example.com record to failover-example.com and activate the cloudflare proxy on example.com.
The result is that the browser resolves the IP address of example.com to a cloudflare IP address. Cloudflare queries the AWS DNS server to lockup failover-example.com. Cloudflare fetches the content from the resolved IP address and returns the content back to the browser.
In my tests the switch to the other backend system occurs after ca. 20 seconds.
The separate domain is required because cloudflare does not route the traffic through the proxy when the CNAME is a subdomain of example.com.
I have tried to visualize the failover. In theory the failover works with any DNS failover capable service and not only with Route53:
The browser connects always with CloudFlare and hence a DNS failover of the backend system does never effect the browser of the user.
We don't have automatic failover at this time (something we're looking at). We can support the additional DNS entries in your zone file, of course, but you would currently have to manually make the change in that circumstance.
To add -- in the mean time, I'd recommend looking at https://runbook.io
Several other DIY options:
http://blog.booru.org/?p=12
https://vpsboard.com/topic/3341-running-your-own-failover-dns-setup/
https://github.com/marccerrato/python-dns-failover
You'd want to decide if these are the right options for you, of course.
Related
Halo, i’m a dev recently diving into cloudflare security layers and got few questions on a website security which is deployed to cloudflare. I’m using Pages and my domain is directly hosted by cloudflare Registrar. I’m also using the security layers provided with cloudflare infrastructure, including [ Bots, DDos, Settings, Page Shield ], which can be found in security tab of my domain in cloudflare dashboard. Below list is my questions:
security layers in use: [ Bots, DDos, Settings, Page Shield ]
I’m using firebase hosting to link my firebase functions with the domain which is hosted by cloudflare. In this case, do the above listed security layers of cloudflare automatically protect the firebase hosting resources or traffics?
I’m using cloudflare workers to manage Durable Objects. The Workers’ functions are also linked to the same root domain with different subdomain. In this case, do the above listed security layers of cloudflare automatically protect the Worker traffics?
the proxy status of firebase hosting connection is “DNS only” mode(not “Proxied” mode), since in the case of Proxied, the dns connection does not work(i didn't figure out the reason yet..). In this case, it makes me feel like the firebase hosting resources are not being protected since the orange switch in DNS dash is turned off
please consider the cloudflare plan is Pro
Thank you in advance [:
For the products you are listing, Cloudflare is implemented as a reverse proxy.
This means that from an end user perspective, when they try to connect to your services, their traffic reaches Cloudflare first (since a proxied record resolves to a Cloudflare anycast IP). Cloudflare carries out the features and security services that are configured, then forwards the HTTP requests to your origin infrastructure as specified in your Cloudflare DNS tab. This is true when the traffic is directed to proxied records.
For records in DNS-only mode, Cloudflare only performs DNS resolution (answering to the DNS query for that DNS record). Once this is done, the client will connect directly to the specified resource and the traffic will not be flowing through the Cloudflare network, meaning Cloudflare cannot provide proxy services in this scenario.
For a full explanation, I recommend the following documentation page
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.
A client of ours has the domain client.com
Our application is at superapp.mycompany.com
We want the client to be able to access our application via their own subdomain, like: superapp.client.com.
Normally we'd just tell the client to add a cname for superapp and point it to superapp.mycompany.com. Then on our server (IIS) we'd bind their domain to our app and everything would work as intended.
However, we can't replicate this functionality when our mycompany.com domain is managed via cloudflare.
When we navigate to superapp.client.com we get the following error page:
Error 1001
What happened?
You've requested a page on a website (superapp.client.com) that is on the Cloudflare network. Cloudflare is currently unable to resolve your requested domain (superapp.client.com).
Is there any way that Cloudflare can be used in this fashion?, this seems like a pretty standard set up for a multi tenant application that supports custom domains.
We don't need all the protection that Cloudfront offers for these client domains, but we want to use the Cloudfront nameservers for out application (mainly for fast switching of DNS records in the event we migrate servers, etc).
Any help is appreciated.
I hope it's not too late. But just found a way to do so.
You just need to add your client's domain (Add site in Cloudflare) to your account.
You don't need to change client domain's NS. So in your Cloudflare panel this domain will showing as "Pending Nameserver Update".
Next step is add the CName record to this domain.
Although the NS of client domain is not changed to CF, but CF has a lookup record as CName for it.
Hope it helps.
Just in case someone arrived here with same issue as me. Here is the answer. For short, no that won't work.
Since Cloudflare is a reverse proxy for the domain that is on Cloudflare, the CNAME redirect for the domain (not on Cloudflare) wouldn't know where to send the traffic to.
Ref: https://support.cloudflare.com/hc/en-us/articles/360017421192-Cloudflare-DNS-FAQ#CloudflareDNSFAQ-CanICNAMEadomainnotonCloudflaretoadomainthatisonCloudflare
If you don't need the CDN benefits, you can still use Cloudflare nameservers to manage your DNS zone and keep your current configuration. Just make sure the CDN is deactivated for the target subdomain in your zone (superapp.mycompany.com in your case).
You can tell if the CDN is activated or deactivated for a subdomain by looking at the cloud icon on the right of each DNS entry: if the cloud is orange the CDN is active, if it is gray, it isn't.
Cloudflare also supports external CNAME resolution in their CDN infrastructure, but it's only available for its Enterprise customers:
https://support.cloudflare.com/hc/en-us/articles/217371987-Managed-CNAME
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.
I want to mount a system with 2 dedicated servers with different providers. My main interest is to have some high availability. The use case is the following:
We have a domain pointing out to a public IP. When the server on that IP shutdown we want to change the IP to another server that has the same resources. We know that we can change the dns configuration (in the administration panel of our domain provider), but it must be a manual configuration where somebody must connect to the administration panel and change it, furthermore wait to the dns propagation.
Is there any possible solution to have an automatic failover IP doing that automatically?
Thank you
Have a look at the Amazon Route 53 DNS health checks and failover functionality. I guess it suits your needs, but you have to switch your domains nameservers or at least a subdomains nameserver to Amazon:
http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html