How to decouple Tailscale internal IP for Cluster communication from public A records in cluster-catalog?

[ycgz2008]

Hi ,

Thank you for developing this amazing DNS server! I am running into a configuration dilemma when setting up a Primary/Secondary cluster using Tailscale for internal node communication.

My Setup & Goal:
I have 1 Primary node and several Secondary nodes (ns1 to ns5).

All nodes are connected via Tailscale VPN (100.64.0.0/10 range).

My goal:

Cluster internal communication (API, Zone Transfers/AXFR, and Notify) should strictly use Tailscale internal IPs (100.x.x.x) for security.

Public DNS resolution should advertise the real public IPs of my VPS nodes as the A / AAAA records for ns1 - ns5 in cluster-catalog and my primary domain zone.

The Problem:
If I enter the Tailscale internal IPs (100.x.x.x) in Secondary Node IP Addresses when joining the cluster:

The cluster syncs over Tailscale perfectly.

However, the auto-generated A records for my nameservers in cluster-catalog and my zone get updated to 100.x.x.x (Tailscale IPs), causing public DNS queries from the internet to fail.

If I change Secondary Node IP Addresses to the Public IPs:

The public A records become correct (Public IPs).

However, cluster communication no longer routes through the private Tailscale tunnel.

My Question:
What is the recommended way to configure the cluster so that nodes communicate and sync exclusively via Tailscale internal IPs (100.x.x.x), while the DNS server automatically publishes real Public IPs for the nameserver A/AAAA records to the outside world?

Should I be configuring Advertised IP Addresses under Settings -> Cluster differently, or is there another way to decouple cluster transport IPs from the published name server records?

Thanks in advance!

[ShreyasZare]

Thanks for asking. There is no option to do that. Is there a specific reason why you do not want the cluster traffic to go through public IP? If the reason is security then that aspect is covered since clustering uses DANE-EE and is secure to use over the Internet.

If you still want it to work over Tailscale network, I would suggest that you use a different domain name for the cluster and manage your main domain name separately. That way clustering will work independently of your main zone. You can create secondary zone manually on all nodes or create a separate catalog zone if you have more than one zone that you want to manage separate of the clustering setup.

[ycgz2008]

Thanks for asking. There is no option to do that. Is there a specific reason why you do not want the cluster traffic to go through public IP? If the reason is security then that aspect is covered since clustering uses DANE-EE and is secure to use over the Internet.

If you still want it to work over Tailscale network, I would suggest that you use a different domain name for the cluster and manage your main domain name separately. That way clustering will work independently of your main zone. You can create secondary zone manually on all nodes or create a separate catalog zone if you have more than one zone that you want to manage separate of the clustering setup.

Hi Shreyas,

Thank you so much for the quick reply and the clear guidance! I followed your suggestion to use a separate catalog zone, and it perfectly solved my issue. The cluster now syncs over Tailscale, and my public domains correctly advertise the real public IPs.

However, I found that in practice, this workaround introduces significant operational complexity. It requires manually managing separate catalogs, being careful not to select the default cluster catalog, and configuring external glue records manually every time a new zone is added. For a growing setup, this manual overhead can easily lead to misconfigurations.

Would you consider adding a feature in a future release to natively decouple the "Cluster Transport IP" from the "Advertised Public IP"? (Perhaps by adding a specific "Advertised IP" field for nodes under Settings -> Cluster).

The Use Case:
Many users are adopting Zero-Trust networks like Tailscale or WireGuard for backend server-to-server communication. Our goal isn't just encryption (which DANE-EE handles beautifully), but firewall minimization. By routing cluster sync (API, AXFR, Notify) exclusively over a private VPN tunnel, we can completely close ports like 53443 on our public-facing firewalls, leaving only standard port 53 open to the public internet. This drastically reduces the public attack surface.

Having a native way to support this hybrid architecture—syncing via private IPs while answering with public IPs automatically—would make Technitium DNS even more incredibly powerful for enterprise and homelab users alike.

Thank you again for all your hard work on this amazing project!

[ShreyasZare]

Thanks for the feedback. Will plan some options to make the cluster design more flexible.