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

[Feature] Predictable IPs #1154

New Issue
Closed
opened 2025-12-29 02:28:35 +01:00 by adam · 2 comments
adam commented 2025-12-29 02:28:35 +01:00
Owner
Copy Link

Originally created by @Mikilio on GitHub (Nov 19, 2025).

Use case

I wanted to deploy some infrastructure using authkeys and am hitting a chicken-and-egg problem:

  • I need a private DNS server to have name-resolution for my private services
  • For that, I need a private network.
  • For that, I need headscale.
  • For that, I need a config.yaml.
  • For that, I need a private DNS server.

Please note that I have my own workarounds and a working setup.
While dealing with this, I merely realized how much easier this would have been if there was a way to have predictable IP addresses for a given preauthkey. I wonder if that would be hard to implement?

Description

I would like a flag that will also trigger the reservation of node ip's when creating a preauthkey and will get printed together with the headscale preauthkey create command.

Contribution

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

How can it be implemented?

I am not a go programmer but still a software engineer.
My first approach would be to add a boolean field reserved_ip to the pre_auth_keys table.
When headscale preauthkey create -u <id> --reserve-ip is called it will also add a record to the nodes table. With most fields missing and only (id, ipv4, ipv6, auth_key_id) being set.
Headscale now needs to learn to ignore these kind of records except for the command headscale nodes register Where it will use the reserved IPs instead of sourcing fresh ones if the preauthkey matches.

Possible considerations:

  • How should this behave on reusable authkeys. Should the IPs stay reserved even if the node expires?
Originally created by @Mikilio on GitHub (Nov 19, 2025). ### Use case I wanted to deploy some infrastructure using authkeys and am hitting a chicken-and-egg problem: - I need a private DNS server to have name-resolution for my private services - For that, I need a private network. - For that, I need headscale. - For that, I need a config.yaml. - For that, I need a private DNS server. Please note that I have my own workarounds and a working setup. While dealing with this, I merely realized how much easier this would have been if there was a way to have predictable IP addresses for a given preauthkey. I wonder if that would be hard to implement? ### Description I would like a flag that will also trigger the reservation of node ip's when creating a preauthkey and will get printed together with the headscale preauthkey create command. ### Contribution - [x] I can write the design doc for this feature - [x] I can contribute this feature ### How can it be implemented? I am not a go programmer but still a software engineer. My first approach would be to add a boolean field `reserved_ip` to the pre_auth_keys table. When `headscale preauthkey create -u <id> --reserve-ip` is called it will also add a record to the nodes table. With most fields missing and only (id, ipv4, ipv6, auth_key_id) being set. Headscale now needs to learn to ignore these kind of records except for the command `headscale nodes register` Where it will use the reserved IPs instead of sourcing fresh ones if the preauthkey matches. Possible considerations: - How should this behave on reusable authkeys. Should the IPs stay reserved even if the node expires?
adam added the enhancement label 2025-12-29 02:28:35 +01:00
adam closed this issue 2025-12-29 02:28:35 +01:00
adam commented 2025-12-29 02:28:36 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Nov 21, 2025):

Hi,

This would introduce a lot of complexity for something that goes against our "do not get attached to IPs" approach.
Instead you should use the API to learn what IP address the machines ends up with.

@kradalby commented on GitHub (Nov 21, 2025): Hi, This would introduce a lot of complexity for something that goes against our "do not get attached to IPs" approach. Instead you should use the API to learn what IP address the machines ends up with.
adam commented 2025-12-29 02:28:36 +01:00
Author
Owner
Copy Link

@Mikilio commented on GitHub (Nov 21, 2025):

If we should not get attached to IPs then is it possible to instead allow machine names to be used in the nameservers.splitconfiguration? The control server would know which nameserver IP's to advertise based on that information only, and it is a pretty neat feature.

@Mikilio commented on GitHub (Nov 21, 2025): If we should not get attached to IPs then is it possible to instead allow machine names to be used in the `nameservers.split`configuration? The control server would know which nameserver IP's to advertise based on that information only, and it is a pretty neat feature.
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#1154
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?