My understanding is that DNS was designed for name resolution, not load balancing.
For both, because (almost) all records can be sets, hence for a given question a client can get multiple answers and then is free to choose whatever item it prefers.
Which is why a frequent pattern is round-robin among replies, so that the client picks the "first" item, but it will be different each time.
Of course a client can implement a smarter algorithm, specially for the transition to IPv6 with
AAAA records, see RFC 8305 "Happy Eyeballs Version 2: Better Connectivity Using Concurrency" but this is not load balance anymore.
So it all depends on what amount of "intelligence" there is on the client side.
SRV records allow to encode both a priority (fail over) and weight (load balance) for potentially any protocol over TCP or UDP, and allows not to have to hard code port numbers anymore. Sadly, browsers never implemented it.
The newer iteration are
HTTPS records that allow kind of the same thing.
Note this in fact in the current draft:
SRV records specify a "weight" for unbalanced randomized load-balancing. SVCB only supports balanced randomized load-balancing, although weights could be added via a future SvcParam.
What if I want a more complex load balancing algorithm besides round robin?
Today, this means
SRV records and some intelligence in the application (client side). Or a smarter nameserver that changes its replies based on external dynamic factor (what CDNs do for example).
The basic problem faced with load balancing at the DNS level is tailored to TTLs, and because some resolvers will not obey too small values for it.
You need to remember also that the authoritative nameserver that has the data only sees the recursive nameserver the client uses most of the time, not the client itself. So its choices are constrained also by that.