For the most part, once a client goes through the process of selecting another DNS server it will stick with that choice until the process is triggered again. This will cause It's Always DNS memes when you've configured multiple servers which have differing views of DNS.
Oh you're right. I didn't think about the time it'd take to switch back to the "more desirable" name server or how often it checks it (or if it even does) when it's already selected another. I wonder what the differences are on OS/forwarder implementations for that.
If you want to give yourself a migraine, Microsoft has a comprehensive document[0]. DNS/AD has been the focus of my job for the last 5 years and I'm still not absolutely certain the circumstances that a given Windows client will return to the 1st candidate DNS server when there are > 2.
On Unix-y things, resolv.conf is specified to be used in the listed order[1]. Local caching resolvers will default to remembering the last successful server and treating the list as circular, so after the first DNS server has a failure it won't be tried again until each subsequent server has failed. Every time a distro has switched to having a local caching resolver by default you'll find big threads of people confused over the altered behavior[2].
And default behaviors are meant to be over-ridden, so in places where I have dnsmasq providing DNS for a network (PiHole, EdgeRouters) I set all-servers[3] so that every upstream is queried simultaneously and the fastest response wins -- an exceptionally bad configuration option when having upstreams with differing views of DNS, but for the general use case it makes the Which public DNS is fastest debate moot.
