Website high availability without load-balancer?

I'm considering options for changing a 'high availability' website that provides a service via an https api.

The current setup is:

• Two self-contained VMs, from different cloud providers (AWS and RackSpace)
• One DNS load-balancer: this is where the HA also comes in, the service monitors the two VMs and if one appears to be unavailable it directs all DNS queries to the other

If load-balancing was not a requirement, could we do without the load-balancer by simply co-locating the DNS servers on the two machines, each replying only with it's own address when queried by DNS. In this scenario, if one VM is down that will remove both the service and the DNS server that points at the service so no clients will be directed to the server that is down, is that correct?

edit for clarity:

we are happy with the less-than-perfect 'HA' we currently have, this question is specifically about whether the changes I'm thinking of will make things worse or not.

The direct answer to your question is Yes, it will make it worse.

This is because one of your name servers not responding will cause resolve delays all the time for clients who attempt to resolve via the failed name server, whereas the current technique will only fail +- half the clients until you detect the VM is down + TTL seconds.

Generally name servers are cached for 48 hours so during the lower of your downtime or name server updates + 48 hours, your users will have a randomly slow experience.

Your current implementation is better unless your VM down detection is slow. For the period between the VM going down and you detecting it + TTL the proposed solution will actually be better. But I am assuming that that is so small a period of time as to be ignorable.

If I understand you correctly, you propose to have both distributed servers be the listed nameservers for the domain in question, each with an authoritative zonefile that contains a single A record pointing to the local server for the hostname on which your HTTPS service runs.

If that's correct, then yes, I would expect this to work based on the round-robin / stochastic nature of requests to nameservers. If one server goes down, it won't be able to respond to queries with its own address, so clients should fairly quickly fail over to the other for the DNS lookup.

You say you understand and accept that DNS cacheing means that a downed server may break clients who have cached the lookup that points to that server, possibly for lengthy periods of time because of ISPs that don't honour short TTLs. If that's all so, then I don't see any obvious holes in your proposal.

I just wouldn't do it myself in a month of Sundays.

DNS load balancing used to be the "thing" to use, but with caching in common use today it's not as practical.

In Windows, you have the "Network Load Balancer" which can assist with what you want to do by using multicast over a private network. You can still do this across providers with a VPN between the two.

In Linux, you'd need to use something like haproxy or other package to accomplish load balancing. This produces challenges on their own, though.

Look at your options and decide which would be most cost effective for your needs. I can't speculate beyond the very popular options.