2 ms·

> "Records don't change that often so "bad things" would happen far less often if the failure mode was the client was behind on replication." That's... an enti

> "Records don't change that often so "bad things" would happen far less often if the failure mode was the client was behind on replication." That's... an entirely environment specific situation whether that's true or not. If you're doing modern CI/CD practices with k8s, etc - those records might be valid for minutes at a time. In many situations it's better to specifically get a DNS Resolution failure than to get out of date records. That at least should be noticeable and obvious to the application and anything/anyone monitoring/using it. > They want a DNS system where the server pushes record updates to the clients. This is what Zone transfers between DNS servers are. Running a DNS Server on each client in your network seems like an overly complicated situation but hey, if you want to do that - you can. I suspect it'll cause more problems than it solves by just having a set of well monitored/configured DNS servers.

Spivak 7y ago
> Better to get resolution failure. But this is just as env specific! The point is that the “copy hosts” people are basically saying in their env that serving potentially stale records is the preferred failure mode. > Zone xfer! Yes! I just with the software support was better/more mature for “caching servers” (i.e clients) to act as slaves for zones rather than catching requests in-flight. > Running a DNS server on each client... This is what Ubuntu has done for ages with dnsmasq and now systemd-resolved. Every Linux server these days is running a DNS server. This isn’t a “solving problems“ thing. This is a “what sounds happen in the event of a failure of those well configured and monitored DNS servers.” You can’t just be like “just never fail” as a solution.