Your router offers two DNS boxes. You put the local resolver in the first and a public resolver in the second. It feels like a sensible safety net: if the local box stops, the Internet still works.
For a homelab with private names, it can also be a recipe for intermittent failure. The two servers do not necessarily know the same things, and a client’s resolver policy is not a universal primary/standby contract. The better question is not “do I have two DNS addresses?” It is “can every resolver a client might use answer the names that client needs?”
A resolver list is not a recovery procedure
DNS server selection depends on the operating system, resolver library, network configuration and application. Do not assume every client exhausts the first server before trying the next. Even on one operating system, a browser using encrypted DNS may follow a different path from a terminal lookup.
The systemd-resolved documentation gives a concrete example: it normally keeps using a selected server within a lookup scope until an error causes a switch, and expects servers in that scope to serve equivalent zones. That is not a claim about every DNS client. It is a useful demonstration that the words “first” and “second” do not define one portable failover policy.
There is another easily confused setting: systemd’s FallbackDNS= is used when no other DNS server information is known. It is not simply an emergency server that activates whenever a configured resolver goes down. Read the semantics of the particular setting you are changing.
The private-name trap
Imagine a service called notes.home.arpa. A local DNS server knows its private address. A public resolver does not have that private record. If a client asks the public server, the answer may be negative rather than a timeout. That response is not an invitation for the client to ask a different server until it gets an answer it likes.
Negative caching can keep the symptom around after you fix the configuration. Equally, a positive cached record can make a broken resolver look fine for a while. This is why opening an already-used bookmark is a weak DNS resilience test.
RFC 8375 reserves home.arpa for residential home-network naming. It is a good generic choice for this example, not a requirement to rename a working network. Publicly trusted TLS certificates and access from outside the home bring separate naming and validation decisions; do not change your namespace casually just to follow a tutorial.
Put equivalent resolvers in front of the client
A simple design is two local resolvers that both know the local records and apply the intended policy. They can forward external queries upstream. This keeps the distinction clear: the client-facing pair answers the same namespace; upstream servers help resolve external names.
Equivalent does not mean identical hardware. It means equivalent answers and deliberate behaviour: local zones, forwarding rules, filtering policy, and any split-DNS routing should agree. If one server blocks a domain and the other allows it, you have policy variation, not reliable redundancy.
Configuration synchronisation is useful but adds another dependency. Decide which system is the source of truth, how changes reach the other resolver, and what happens when synchronisation fails. Keep a recoverable configuration copy outside the DNS service itself. Never put upstream account credentials or exported secret material in a public diagram or runbook.
Count failure domains, not boxes
Two DNS containers on one host can survive an application-process failure. They cannot both survive that host losing power. Two virtual machines on one hypervisor have a similar shared dependency. The design may still be entirely appropriate for a small lab, but describe the protection accurately.
Physical separation has costs: another device to patch, a second configuration to audit, and more ways for answers to drift. Start with the outage you actually want to tolerate. A second low-power machine may be worthwhile for host maintenance; a second container may be enough for a disposable experiment.
Also write down how you reach the resolver when DNS is unavailable. An offline note with its management address and recovery instructions is more useful than a dashboard whose hostname requires the failed service. Store that note privately; publishing real management addresses helps nobody.
Test the client path, not only the server
Testing each resolver directly tells you whether those servers answer. Testing through the normal application path tells you what the client is actually using. You need both observations. A direct DNS query does not exercise every layer of the operating system’s name-service configuration.
Containers add another layer. Docker documents that containers on custom networks use its embedded DNS server, which forwards external lookups to the host’s configured DNS servers. Default-bridge behaviour differs. A successful lookup on the host therefore does not prove the application container follows the same resolution path.
A fifteen-minute, read-only experiment
This is an unperformed exercise, not a report of a tested deployment. On one non-critical client, inspect its effective resolver settings without changing them. Choose one existing private name and one external name. Compare their answers through the client’s usual lookup path and by querying each configured DNS server explicitly with your installed DNS diagnostic tool.
Record which server answered, the returned data and TTL, and whether the application uses its own DNS configuration. Do not flush shared caches or invent random private hostnames: neither is needed for this first comparison. Treat cached results as observations, not proof of failover.
If the servers disagree, fix the design on paper before touching the network. A later outage rehearsal should be explicitly scoped to an isolated test client, with a way back; do not stop household DNS to see what happens.
The useful outcome is a known resolution path. Two equivalent resolvers can improve resilience. Two unrelated addresses in a router form can merely hide uncertainty behind a reassuring number.