[Feature] Round robin for extra_dns
Use case
I have 3 endpoints for master internal kubenetes control plane, and now I can only setup one ip for extra_dns per endpoint.
Description
round_robin_dns – This allows DNS queries to be distributed across multiple IP addresses (e.g., 100.64.0.3 and 100.64.0.4), providing load balancing (Round Robin DNS).
0.3 and 100.64.0.4), providing load balancing (Round Robin DNS).
extra_records – This section allows you to add custom DNS records. In this case, an A record is added for grafana.myvpn.example.com, which points to two different IP addresses (100.64.0.3 and 100.64.0.4), which will operate in round robin mode.
Contribution
- [x] I can write the design doc for this feature
- [ ] I can contribute this feature
How can it be implemented?
extra_records:
- name: "grafana.myvpn.example.com"
type: "A"
value: ["100.64.0.3", "100.64.0.4"]
This is unsupported in the client, so we can't add that sadly; https://github.com/tailscale/tailscale/blob/main/tailcfg/tailcfg.go#L1713
Extra records are passed directly as is so what you see in the config is what you get.
I used to have the same question, and, sadly, found the same answer as kradalby mentioned. I end up adding those records to a public DNS provider (i.e. Cloudflare) which supports round robin , and is considered harmless, according to the tailscale docs.
This is unsupported in the client, so we can't add that sadly; https://github.com/tailscale/tailscale/blob/main/tailcfg/tailcfg.go#L1713
Extra records are passed directly as is so what you see in the config is what you get.
In code are comment
// TODO(bradfitz): if we ever add support for record types // with non-UTF8 binary data, add ValueBytes []byte that
So I have to write to @bradfitz
I don’t think that indicates that they will support multiple, it is talking about other formats.
Please don’t add workload for the tailscale prosject.
Perhaps I'm missing something obvious, but it seems to me like the tailscale client supports multiple ip addresses for the same FQDN, as shown here. The link is from the headscale documentation, so I assume @kradalby is aware of this and I must be missing something.
What is preventing us from using this configuration in headscale?
[
{
"name": "test.example.com",
"type": "A",
"value": "100.x.y.1"
},
{
"name": "test.example.com",
"type": "A",
"value": "100.x.y.2"
}
]
I've tried but the client only seems to get the first IP out of the two. Is this a headscale limitation or is this inherent to tailscale?
This issue is stale because it has been open for 90 days with no activity.
This issue was closed because it has been inactive for 14 days since being marked as stale.