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.

7
  • Are CNAMEs out of the question?
    – MadHatter
    Nov 13, 2014 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, 2014 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, 2014 at 14:30
  • Well, those ought to be 301-redirected anyway, and many DNS providers will even do it for you. Nov 13, 2014 at 16:24
  • 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). Nov 13, 2014 at 22:09

1 Answer 1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .