starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-11 20:00:28 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

Add support for host aliases when using MagicDNS? #313

New Issue
Closed
opened 2025-12-29 01:26:37 +01:00 by adam · 3 comments
adam commented 2025-12-29 01:26:37 +01:00
Owner
Copy Link

Originally created by @VolatileDream on GitHub (Aug 24, 2022).

Feature request

Expose a way to map multiple hostnames to an existing device, assuming they all belong to the same namespace. I'm only asking for the ability to map hostnames that would be inside the tailnet, to other names that are inside the tailnet.

This is effectively DNS CNAME records, but I would like to configure them in Headscale. I would consider it more usable if I didn't have to rely on another DNS resolver providing the CNAME resolution for things inside my tailnet.

For example:

webhost-1.machines.<tailnet> -> server.machines.<tailnet>
webhost-2.machines.<tailnet> -> server.machines.<tailnet>
webhost-3.machines.<tailnet> -> server.machines.<tailnet>

But I would not want to support:

google.com.             -> server.machines.<tailnet>
test.machines.<tailnet> -> duckduckgo.com.

I'm not asking cross namespace support (eg: some.machine.<tailnet> -> other.namespace.<tailnet>) but I can see uses for it, so others may chime in to request it.

Tailscale is building support for tailcfg.DNSConfig.ExtraRecords: a way to pass around extra DNS records for use with MagicDNS. It appears that it currently supports A and AAAA records, but based on filed issues, it may grow to support CNAME (in some limited capacity).

I would like to request that once possible CNAME records are added to the Headscale configuration. But perhaps in the meantime, this could be implemented via A and AAAA records?

I currently have a system with multiple web services configured using a reverse proxy to route traffic. I'd like to expose it as a single tailscale node, rather than splitting each service out and creating more tailscale nodes, and mapping multiple hostnames keeps the reverse proxy functioning.

Collection of related Tailscale issues:

Originally created by @VolatileDream on GitHub (Aug 24, 2022). <!-- Headscale is a multinational community across the globe. Our common language is English. Please consider raising the feature request in this language. --> **Feature request** Expose a way to map multiple hostnames to an existing device, assuming they all belong to the same namespace. I'm only asking for the ability to map hostnames that would be inside the tailnet, to other names that are inside the tailnet. This is effectively DNS `CNAME` records, but I would like to configure them in Headscale. I would consider it more usable if I didn't have to rely on another DNS resolver providing the CNAME resolution for things inside my tailnet. For example: ``` webhost-1.machines.<tailnet> -> server.machines.<tailnet> webhost-2.machines.<tailnet> -> server.machines.<tailnet> webhost-3.machines.<tailnet> -> server.machines.<tailnet> ``` But I would not want to support: ``` google.com. -> server.machines.<tailnet> test.machines.<tailnet> -> duckduckgo.com. ``` I'm not asking cross namespace support (eg: `some.machine.<tailnet> -> other.namespace.<tailnet>`) but I can see uses for it, so others may chime in to request it. --- <!-- A clear and precise description of what new or changed feature you want. --> Tailscale is building support for [`tailcfg.DNSConfig.ExtraRecords`](https://github.com/tailscale/tailscale/blob/v1.28.0/tailcfg/tailcfg.go#L1069-L1071): a way to pass around extra DNS records for use with MagicDNS. It appears that it currently supports `A` and `AAAA` records, but based on filed issues, it may grow to support `CNAME` (in some limited capacity). I would like to request that once possible `CNAME` records are added to the Headscale configuration. But perhaps in the meantime, this could be implemented via `A` and `AAAA` records? --- <!-- Please include the reason, why you would need the feature. E.g. what problem does it solve? Or which workflow is currently frustrating and will be improved by this? --> I currently have a system with multiple web services configured using a reverse proxy to route traffic. I'd like to expose it as a single tailscale node, rather than splitting each service out and creating more tailscale nodes, and mapping multiple hostnames keeps the reverse proxy functioning. --- Collection of related Tailscale issues: * https://github.com/tailscale/tailscale/issues/1152 * https://github.com/tailscale/tailscale/issues/1543 * https://github.com/tailscale/tailscale/issues/4457 * https://github.com/tailscale/tailscale/issues/5033
adam added the enhancement label 2025-12-29 01:26:37 +01:00
adam closed this issue 2025-12-29 01:26:37 +01:00
adam commented 2025-12-29 01:26:40 +01:00
Author
Owner
Copy Link

@madjam002 commented on GitHub (Aug 25, 2022):

I have a patch that allows setting DNS extra_records in the headscale config that I've been using since December, it works pretty well for my use case.

b9f05fca8d

You can then add to your headscale config.yaml

dns_config:
  extra_records:
    - { name: "xxx.yyy.zzz", type: "A", value: "100.x.x.x" }

I haven't opened a PR with this because I think there's a better way of doing it for more complex setups. E.g a lambda function could be passed in config that takes the Tailscale node as an argument and could then return a specialised set of extra_records depending on the node that it's being sent to.

@madjam002 commented on GitHub (Aug 25, 2022): I have a patch that allows setting DNS extra_records in the headscale config that I've been using since December, it works pretty well for my use case. https://github.com/madjam002/headscale/commit/b9f05fca8d7fcc246b44a0495587b9de1582049c You can then add to your headscale config.yaml ``` dns_config: extra_records: - { name: "xxx.yyy.zzz", type: "A", value: "100.x.x.x" } ``` I haven't opened a PR with this because I think there's a better way of doing it for more complex setups. E.g a lambda function could be passed in config that takes the Tailscale node as an argument and could then return a specialised set of extra_records depending on the node that it's being sent to.
adam commented 2025-12-29 01:26:40 +01:00
Author
Owner
Copy Link

@VolatileDream commented on GitHub (Aug 26, 2022):

Thanks! That would work perfectly for what I have in mind.

I haven't opened a PR with this because I think there's a better way of doing it for more complex setups.

That makes sense. I hadn't thought of more complicated cases. I was trying to restrict my request to something that wouldn't be controversial to implement, and probably not have behaviour interesting enough to have security implications.

@VolatileDream commented on GitHub (Aug 26, 2022): Thanks! That would work perfectly for what I have in mind. > I haven't opened a PR with this because I think there's a better way of doing it for more complex setups. That makes sense. I hadn't thought of more complicated cases. I was trying to restrict my request to something that wouldn't be controversial to implement, and probably not have behaviour interesting enough to have security implications.
adam commented 2025-12-29 01:26:42 +01:00
Author
Owner
Copy Link

@juanfont commented on GitHub (Jan 2, 2023):

This is now merged.

@juanfont commented on GitHub (Jan 2, 2023): This is now merged.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#313
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?