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

[Feature] Wildcard support for split DNS configuration #905

New Issue
Closed
opened 2025-12-29 02:25:45 +01:00 by adam · 4 comments
adam commented 2025-12-29 02:25:45 +01:00
Owner
Copy Link

Originally created by @lgrn on GitHub (Jan 10, 2025).

Use case

There is a split attribute in config-example.yaml that allows you to configure "a map of domains and which DNS server to use for each". In cases of a split VPN scenario, where Headscale is only used to access "internal" resources but not the rest of the Internet, it seems likely that one would want to configure entire domains or subdomains rather than explicit domain names to be passed to a separate DNS.

Description

Functionality today:

  nameservers:
    global:
      - 1.1.1.1
      - 1.0.0.1

    split:
      foo.internal.domain:
        - 10.10.10.10
      bar.internal.domain:
        - 10.10.10.10

Feature request:

  nameservers:
    global:
      - 1.1.1.1
      - 1.0.0.1

    split:
      *.internal.domain:
        - 10.10.10.10

If starting an attribute with * causes yaml or other syntax issues, perhaps the syntax .internal.domain or similar could be considered instead.

Contribution

  • I can write the design doc for this feature
  • I can contribute this feature

How can it be implemented?

No response

Originally created by @lgrn on GitHub (Jan 10, 2025). ### Use case There is a [split attribute](https://github.com/juanfont/headscale/blob/10a72e8d542af68c0c280f2a6ccc84849719b24c/config-example.yaml#L287) in `config-example.yaml` that allows you to configure "_a map of domains and which DNS server to use for each_". In cases of a split VPN scenario, where Headscale is only used to access "internal" resources but not the rest of the Internet, it seems likely that one would want to configure entire domains or subdomains rather than explicit domain names to be passed to a separate DNS. ### Description Functionality today: ```yaml nameservers: global: - 1.1.1.1 - 1.0.0.1 split: foo.internal.domain: - 10.10.10.10 bar.internal.domain: - 10.10.10.10 ``` Feature request: ```yaml nameservers: global: - 1.1.1.1 - 1.0.0.1 split: *.internal.domain: - 10.10.10.10 ``` If starting an attribute with `*` causes yaml or other syntax issues, perhaps the syntax `.internal.domain` or similar could be considered instead. ### Contribution - [ ] I can write the design doc for this feature - [ ] I can contribute this feature ### How can it be implemented? _No response_
adam added the enhancement label 2025-12-29 02:25:45 +01:00
adam closed this issue 2025-12-29 02:25:45 +01:00
adam commented 2025-12-29 02:25:46 +01:00
Author
Owner
Copy Link

@Nathanael-Mtd commented on GitHub (Jan 10, 2025):

You can just set internal.domain to your specified DNS server, every request to that domain or subdomain will be handeled by the specified server.

For example:

  nameservers:
    global:
      - 1.1.1.1
      - 1.0.0.1

    split:
      internal.domain:
        - 10.10.10.10
@Nathanael-Mtd commented on GitHub (Jan 10, 2025): You can just set ``internal.domain`` to your specified DNS server, every request to that domain or subdomain will be handeled by the specified server. For example: ``` nameservers: global: - 1.1.1.1 - 1.0.0.1 split: internal.domain: - 10.10.10.10 ```
adam commented 2025-12-29 02:25:46 +01:00
Author
Owner
Copy Link

@lgrn commented on GitHub (Jan 10, 2025):

That's great, if that already works then I'll just suggest that it's maybe clarified in the comments in config-example.yamland/or the docs (most of the attribute documentation seems to be in the config example itself).

If I understand the behavior correctly then adding foo.bar.com would also mean that sub.foo.bar.com triggers the same DNS rule which may be unexpected, so maybe that should be documented as well.

@lgrn commented on GitHub (Jan 10, 2025): That's great, if that already works then I'll just suggest that it's maybe clarified in the comments in `config-example.yaml`and/or [the docs](https://headscale.net/stable/ref/configuration/) (most of the attribute documentation seems to be in the config example itself). If I understand the behavior correctly then adding `foo.bar.com` would also mean that `sub.foo.bar.com` triggers the same DNS rule which may be unexpected, so maybe that should be documented as well.
adam commented 2025-12-29 02:25:46 +01:00
Author
Owner
Copy Link

@Nathanael-Mtd commented on GitHub (Jan 10, 2025):

Yeah, DNS docs seems outdated.

It's not really unexpected, that's how DNS servers works.

Every requests you send with a specified suffix (zone is the right word) will be sent to the specified DNS server.
If the specified DNS server got the entry in his zone, it will return the answer, if not (depends of the DNS server config) it will check recursively the authoritative DNS server for the zone and get DNS entry and return that to you.

@Nathanael-Mtd commented on GitHub (Jan 10, 2025): Yeah, DNS docs seems outdated. It's not really unexpected, that's how DNS servers works. Every requests you send with a specified suffix (zone is the right word) will be sent to the specified DNS server. If the specified DNS server got the entry in his zone, it will return the answer, if not (depends of the DNS server config) it will check recursively the authoritative DNS server for the zone and get DNS entry and return that to you.
adam commented 2025-12-29 02:25:46 +01:00
Author
Owner
Copy Link

@lgrn commented on GitHub (Jan 10, 2025):

Yeah, I guess the comment does kind of already explain it since it says that it's a "map of domains" and not a map of hostnames. Anyway, thanks for the quick feedback.

@lgrn commented on GitHub (Jan 10, 2025): Yeah, I guess the comment does kind of already explain it since it says that it's a "_map of domains_" and not a map of hostnames. Anyway, thanks for the quick feedback.
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#905
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?