Comment on How do people handle authoritative DNS redundancy for their self-hosted workloads?
Prozak@corteximplant.com 3 weeks ago
@dave rudimentary split dns. All my FQDN are using a compliant example.com my network serves those app.example.com, my AdGuard does rewrites for them and in the public space i A DNS to them using Tailscale IP.
May not be approved by enterprise architects but works with no public port openings
Trying to understand your setup: this seems like a split-horizon DNS, where
app.example.comis only visible from your internal network (or Tailnet), right?If so - I explained my similar setup in this comment; in short, my internal DNS works perfectly because the internal DNS server has a static “service IP” (handled by kube-proxy); if my currently-running pod breaks, k8s will simply spawn a new one and the DNS server IP won’t even have to change - meaning, the internal DNS zone continues to be served no matter which node breaks (it’ll even survive multiple node failures).
But the external DNS is different and I can’t simply plug in a “fake loadbalancer IP” there… (there are valid workarounds but they either are incredibly finicky or I have to spend an obscene amount of money to implement them)
@dave I see. I am not experienced in Kubernetes so cannot help there, but what you could do, is having a public reverse proxy and your public dns entries resolve to that ip, then caddy will serve the public side https://prozak.org/007-setting-up-vps-webproxy-to-homelab-servers-using-tailscale something like this I think can help