I have a client that wants to maintain control of his domain (fair enough) - he also wants to maintain control of his MX records (fair enough). He is with CrazyDomains and the current records kind of look like this:
Before CrazyDomains:
After CrazyDomains:
DO:
Essentially I can maintain the A Name records (via DO) and he can maintain the MX records (via CrazyDomain)
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Sign up for Infrastructure as a Newsletter.
Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
@cjke7777
NGINX can work as a load balancer and/or a proxy, which is the beauty of it all :-).
For the purpose of this example, let’s say we have 3 clients we need to manage (i.e. host their sites).
Also for the purpose of this example, I’ll be setting up 3x 1GB Droplets. Once live, I’ll SSH in to each and run:
Once finished, NGINX is installed on all three Droplets.
Now, for the purpose of identifying the servers, when I reference
Droplet #
, you’ll know which one I’m talking about by looking at the below.On Droplet 01
Inside this directory you’ll find a file called
default
. We’ll delete that and start fresh.Now, we’ll create files for each of our client domains:
Now we’ll modify each one, for each client.
Inside
clientdomain01.com.conf
, paste:Inside of
clientdomain02.com.conf
, paste:Inside of
clientdomain03.com.conf
, paste:What the above does is send requests for:
… to Droplet 01 – it’ll send requests for
clientdomain02.com
to Droplet 02.Droplet 02 and Droplet 03
The configuration on both of these Droplets will be minimal to start as this is just an example, but you will configure these two as you would any standard NGINX web server.
To get started here, we’ll delete the
default
file again and start fresh on both, but we’ll need to add in specifics to our server blocks to handle the proxied requests from Droplet 01.So since Droplet 02 is going to handle two domains, we’ll start there.
We’ll start with
clientdomain01.com.conf
Paste in:
Now for
clientdomain03.com.conf
Paste in:
Now we can move on to Droplet 03 and do the same:
Paste in:
Restart NGINX
Now, on all 3 servers, restart NGINX:
With the above configuration, requests for clientdomain01.com and clientdomain03.com will hit Droplet 02 while requests for clientdomain02.com will hit Droplet 03.
Where to Point A Entries
All A entries for the three domains would point to the IP of the load balancer (Droplet 01). Now the only IP that clients are aware of is the one associated with the load balancer.
So for example, if you move clientdomain01.com from Droplet 02 to Droplet 03, you’d simply modify your configuration on the load balancer to point them to the other server and:
and it’s live again. They don’t need to know about the IP’s for Droplet 02 or Droplet 03.
This is an Example
Obviously, PHP, MySQL, etc isn’t installed here. You’d need to install those on Droplet 02 and Droplet 03 just as we did NGINX.
This can get even more complex, though for the purpose of showing what you can do, I hope this helps a bit. If you have any questions, feel free to ask.
@cjke7777
I saw the details on the wwwizer site but didn’t mention it because it’d introduce a point of failure in to the mix – one that you have less control over than in other areas.
Ideally, what I would recommend – coming from someone who’s setup numerous linux clusters over the past 15 years – is setup a load balanced cluster and use Floating IP’s. No, it won’t allow you to do what you’re looking to do in terms of routing customer.com -> customer.company.com, but it’s going to be far less to manage and less of a headache.
NGINX works as a load balancer, or a proxy, or a web server, or a caching web server – so you can use NGINX across the board. No need to swap around unless you have a specific need to use something else (i.e. HAProxy).
In doing so, you’d create two A entries or one A entry and one CNAME (I tend to create A entries for both domain.com and www.domain.com – no need to CNAME www -> domain.com), point it to the load balancer and let the load balancer filter the request to the correct server.
That’s my recommendation / two cents :-). Again, I know it’s not what you want to do, but it does put everything in your control.
You can rely on CNAME’ing www and managing redirects, and that may work if you’re just worried about a single client, but handling a handful or more clients and I can’t say I’d be thrilled to have to set that up for every one of them.
@cjke7777
To get around the need for assigning an physical IP, the provider that handles the DNS would need to support zone apex – most don’t.
The reason for this is because of RFC1033 specifies that the zone apex must be an A entry. That’s an issue in cases like this, but there’s a few options – neither of them allow the client to continue to use CrazyDomain’s DNS though.
1). Use CloudFlare (free) 2). Use Amazon Route 51 (cost is based on queries)
Using such services would allow you to setup, a clients domain (we’ll use customer.com) and point it to
customer.company.com
which resolves on your server. Your web server would then handle the rest.From what I’m seeing, CrazyDomains doesn’t support it and I know DigitalOcean doesn’t (I just tested it), so the above would be the best options if this is absolutely what you need.
The other option would be to let them run with an IP and use a Floating IP, though you’d need to weigh you options there too as moving a client from one server to another would still require an IP change (even if it’s to another floating IP) unless you setup a load balanced solution that can accept a request on the floating IP and push it to the correct server.