You have identified the problem of creating redundant backend servers to a load balancer (or reverse proxy), only to find that the load balancer itself becomes a single point of failure.
This is usually solved by having two or more load balancer units share a common ip address, aka floating ip address, thereby creating a load balancing cluster.
The DNS entry will specify this floating ip address only, and let the load balancing cluster figure out which load balancing unit recieves which incoming request. Therefore DNS servers commonly do not require knowledge of primary and fallback members within the load balancer group.
Different implementations exist making possible both active/passive designs where only one cluster node is reachable through the floating ip address at any one time, and active/active designs where all cluster units are reachable through the floating ip address at the same time.
A multitude of cluster protocols and applications exist, see for example vrrp, hsrp, glbp. Knowing the terminology, finding more alternatives is a trivial task.
haproxy can be deployed in a number of ways to achieve a clustered functionality and solutions are easily searched for, see for instance here, and here.
There are other approaches. See for instance DNS Load Balancing with Round Robin and DNS Geolocation routing.
Yes, it is true that the DNS service may be hosted externally to the organisation hosting the load balancer. This usually only affects lead times for changes, but not the load balancer cluster functionality itself (caveat: specialized solutions).