The response in this case will all but certainly be an increasing tendency to apply IP-level whitelists, and deny or at least limit traffic until it's demonstrated trustworthyness.
Much as port-based firewalling progressively closed off virtually all service access other than HTTP/HTTPS, and a few other exceptions, bad actors will likely limit the effectively-reachable scope of IP address space itself.
With IPv6 that's as impractical as blocking "rogue" FQDNs.
One way to do this is to have multiple hash tables: One for single IPv4 addresses, one for IPv4 /24 ranges, one for single IPv6 addresses, one for /64 IPv6 ranges, and one for /48 IPv6 ranges. Note that while the hashes have (generally speaking) a “big O” of 1, we need to perform one additional operation per range size. IPv4 /32 and /24 blocking requires two lookups, and IPv6 /128, /64, and /48 blocking requires three lookups.
As an open-source DNS implementer, I know this has already been done, since my DNS server (MaraDNS’s Deadwood recursive resolver) has the ability to refuse to resolve DNS names with bad IPs via ip_blacklist.
The reason I implemented this is to block NXDOMAIN redirects (when using an ISP’s DNS server and mistyping a domain name, instead of getting “nothing there”, it goes to an ad-filled “search” page provided by the ISP), but the implementation scales and it should work for blocking a large number of rogue CNAME redirects like this one.
I’m sure others have implemented something similar out there (I will let someone who knows the pihole ad-blocking DNS server, not to mention NextDNS, better than me tell us how they do this), and I’m sure Firefox, if they do not do so already, will allow ad/privacy blockers to know the IP of a given name to allow blocking at the browser level.