domain name system - Robust and flexible hosting of DNS A records

itemprop="text">

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.

itemprop="text">

class="normal">Answer

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.
href="https://serverfault.com/questions/613829/why-cant-a-cname-record-be-used-at-the-apex-of-a-domain">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.