1

I'm currently working on a web platform that will be used to power lots of small websites. All of the websites will be hosted on this platform, on either a dedicated or VPS set-up. I don't want to provide a full DNS hosting service, taking on responsibility for routing emails etc, I only want responsibility for the 'website' part of the domains.

The obvious solution to this is to point the 'www' A records of the domains to my server IP, which would have the desired effect. However, what if my server dies and I need to switch all sites to a back-up on a different server with a different IP? I'd need to contact all of the DNS providers for all of the different domains and get them to re-point their A records. This is not desirable.

So... question is, is there a sensible approach to handling something like this, or am I better off just biting the bullet and offering full DNS services via a dedicated service like Cloudfare or DYN?

Thanks for any advice/solutions.

MadHatter
  • 79,770
  • 20
  • 184
  • 232
Briquette
  • 175
  • 1
  • 1
  • 10
  • Are `CNAME`s out of the question? – MadHatter Nov 13 '14 at 14:23
  • Not necessarily. What are you thinking? How would that help in re-pointing the domains in case of a disaster on the primary host-server's IP address? – Briquette Nov 13 '14 at 14:25
  • 1
    For each client domain, the client publishes a record `www CNAME dans-webserver.com.`, and you need only repoint the single A record `dans-webserver.com` in the event of a disaster. It's far from high-availability, but it's better than you calling every single client to make a change. The downside is it won't work for hosting naked domains (eg, `example.com` instead of `www.example.com`). – MadHatter Nov 13 '14 at 14:30
  • Well, those ought to be 301-redirected anyway, and many DNS providers will even do it for you. – Michael Hampton Nov 13 '14 at 16:24
  • @Michael Hampton: I'm sorry, I'm not quite following you there. In Dan's scenario (if I understand correctly) he doesn't manage the DNS for his clients, nor does he wish to. It seems to me that his clients can CNAME the `www.` record in their zones, but not the `@` record. Are you suggesting that each of his clients should also run their own web server for `@`, which HTTP-301 redirects all requests to `www.`? If not, how are you suggesting this could all work without Dan having to have any direct control over all the client zones? – MadHatter Nov 13 '14 at 22:00
  • 1
    @MadHatter The registrar often runs a service which will do nothing but send the 301 redirect from the naked domain to www, when the A record for @ is pointed to it. Namecheap, GoDaddy, and several others have such a service, free with the purchase of a domain name, and it can even be done on Amazon (though you set it up yourself in an S3 bucket). – Michael Hampton Nov 13 '14 at 22:09
  • @Michael Hampton: that's fascinating to hear, and thank you for the clarification; it'll be interesting to find out if Dan thinks it'll work for him. It's not a service offered by all DNS providers (I'd not come across it before) so it'd restrict his clients' choice of providers somewhat - but definitely an option worth having on the table. – MadHatter Nov 13 '14 at 22:18

1 Answers1

0

I'm not sure I would describe this as robust. That would involve multiple backend servers, a failover pair of load-balancers on the front end, a backup site with a non-HA version of the same, and the use of IP addresses that you could switch between the sites if sufficiently large disaster struck.

But stipulating that you want to provide web hosting without all this, without controlling your clients' DNS, but retaining the ability to repoint operations to a second site if the need arises without contacting all your clients to have them update their DNS, one way to do it is with CNAMEs. For clarification, let's say that your server is on the IP address pointed to by the A record server.example.com. Let's say you have two clients, whose domain names are example.org and example.net.

Each client publishes a CNAME record for their www hostname, pointing to your server:

www.example.org.      IN     CNAME     server.example.com.
www.example.net       IN     CNAME     server.example.com.

If you need to change the IP address of your server, you change the A record for server.example.com, which is under your control, and after a suitable interval for DNS cacehing to expire, www.example.{org,net} will start to resolve to the new address.

The problem here is with naked domains. As is well-established around these parts, you can't CNAME the root of a domain. So as long as clients are happy to have their web server solely on www.example.org, you're OK. But as soon as one asks for web service on example.org, you have a problem.

However, Michael Hampton points out that some large DNS providers (he explicitly lists Namecheap and GoDaddy, though this should not be taken as en endorsement of either one) will also provide a web redirection service, where an A record on the naked domain points to the DNS provider's web server, whose sole function is to receive client browser requests for http://example.org/foo and to redirect them via HTTP 301-redirect to http://www.example.org/foo, at which point the mechanism already described takes over and the request is satisfied by your server. Clients who insist on service on their roots can be told that they must get their DNS from a provider that offers such a facility.

This will still not work for clients who also want HTTPS service on their roots (eg, https://example.org/bar); I don't know of any way to have that work without significantly more infrastructure. But you should be OK to service everyone else as described above.

Community
  • 1
MadHatter
  • 79,770
  • 20
  • 184
  • 232