Yes. And I think anyone who thinks 10 IP6 addresses in a DNS response is useful for anything is making a huge mistake, let alone cramming 20+ on a long domain name to smash the response limit, but I am fully prepared to be convinced I was wrong if you had a compelling use-case.
Once upon a time, the DNS spec required requests come from port 53. This was terribly insecure, so many sysadmins patched their DNS server to not do this-- most servers at the time didn't care (including the incumbent), and the few that did were easy to convince of the error of their ways with a simple demonstration.
Then one day, a DNS server became quite popular that didn't do this by default, and perhaps because the DNS spec was written by a company that sold consulting for their (buggy) DNS server, they used this exact argument: that it was wrong because the spec said it was wrong. They patched their server to reject these messages and encouraged users to block this traffic.
That was wrong of them, and eventually, due to enough pressure they eventually caved. That's because the reality of good engineering doesn't give two fucks what the spec says.
Client side load balancing across a universe of 20+ disparate nodes sounds unnecessary. Why is 20+ better than just giving out 5 random members of the universe for your use-case?
Is this HTTP/S? SNMP? Something bespoke? Why doesn't the client already know where all the servers are? How far away are the servers from the client? Can you put code that lives in the client, or is this existing client software you're trying to trick into supporting client-side load balancing?
Also, and only slightly related: Do you have a different definition of "use-case" than me that involves being as vague as you possibly can?
