The problem: you want nas.lab.example.net to resolve to 192.168.10.20 inside the house, while everything else still resolves normally, and you do not want the whole network to lose the internet because one container on one old tower is down. I have a setup I trust, but I would like to compare notes, because the second half of that sentence is where most home setups quietly fail.
The first half is easy. Run a resolver that holds your internal records and forwards everything else upstream. In Unbound it looks like this:
server:
local-zone: "lab.example.net." transparent
local-data: "nas.lab.example.net. IN A 192.168.10.20"
local-data: "pbx.lab.example.net. IN A 192.168.10.30"
Two notes. I use a subdomain of a name I own, or home.arpa if the names will never leave the house. I stay away from invented endings like .local or .lan. And "transparent" means a name you did not define falls through to the upstream resolver, so a typo leaks out to the internet. "static" returns NXDOMAIN instead, which is stricter. Pick on purpose.
The second half is about failure. The tempting fix is to hand out two DNS servers by DHCP: the container first, a public resolver second. I do not like it. Clients do not all treat the list the same way. Some stick to the first server, some move to the second after a timeout, and some wander between them. When the second one answers, internal names either fail or, worse, return a public address. You get a network that works on Tuesday and not on Wednesday, and the capture looks fine each time.
My preference is plumbing logic: one pipe that is boring, and a second pipe that is the same pipe. Put the internal records on the firewall's resolver, since it is the box most likely to be running in five years, and hand out only that. Or run two internal resolvers carrying identical records, and hand out both. Either way, a failed server and its backup give the same answers.
Two other things I have been bitten by or watched others get bitten by:
- The Proxmox host itself. If its own resolv.conf points at a container that lives on that host, you have a circular dependency at boot. Point the host at the firewall.
- Keeping two sets of records in sync. Written by hand, they drift. I keep the list in the binder and update both on the same day, which is not clever but works.
To test it, query each server directly rather than trusting the client:
dig @192.168.10.2 nas.lab.example.net +short
dig @192.168.10.2 example.org +short
Then stop the container and see what a client actually does. Do not guess.
So, two questions. Where do you keep the authoritative internal records: the firewall, a dedicated container, or something else? And if you hand out two resolvers, how do you keep them from drifting apart?
Dwayne