Openmedia Vault PiHole Raspberry Pi 3b Ubiquiti Dream Machine

The general idea of a secondary DNS server was that in case the primary DNS server doesn't reply (e.g. it is offline, unreachable, restarting, etc.), the system can fall back to a secondary one, so it won't be unable to resolve DNS names during that time. Doesn't reply means "no reply at all", it will not ask the secondary when the primary one said that a name is unknown. Answering that a name is unknown is a reply.

The problem here is that DNS uses UDP and UDP is connectionless. So if a DNS server is offline, the system won't notice that other by not receiving a reply from it. As an UDP packet may as well get lost and the round-trip time (RTT) is unknown, it will have to resend the request a couple of times, every time waiting for several seconds, before it finally gets to the conclusion that this server is dead. This means it can take up to an entire minute and above to resolve a DNS name if the first DNS server dies.

As that seems unacceptable, different operating system developed different strategies to handle this in a better way. As both DNS servers are supposed to deliver the same result for the same domain (if not, your setup is actually flawed as the secondary should be a 1-to-1 replacement for the primary one), it shouldn't matter which one is being used. Some systems may send a request to the primary one but if no reply comes back within a few seconds, they don't resend to it but first try the secondary one (then they resend to the primary one and so on). Some may also query both at once, make the faster one win and then keep using that one for a while (until they start another race to see if it is still the faster one). Some may also prefer the primary one but do some kind of load balancing and switch to the secondary one if more than a certain amount of queries are currently pending on the primary one. Some will just alternate between them as a poor man's load balancing. All of this is actually allowed.