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

[Feature] enhance documentation OR rethink MagicDNS #927

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

Originally created by @noseshimself on GitHub (Jan 27, 2025).

Use case

The changes in 0.24 regarding node names is causing collisions which are creating unpleasant situations.

Description

Users can pick their own host name when adding a new system to the mesh

Removing the account name as as FQDN component is permitting this to end in two different users picking the same name. This now has led to frequent physical violence over names and the rights to use them in at least one name space.

Please reconsider finding a way to deliver separate FQDN name spaces per user as the current implementation drives up medical cost for wound care, jellybeans and other sweets.

More seriously: You do not need teenagers to see possible attacks by stupid or malicious users if all are sharing the same name space. It's just not a good idea. As headscale has no control over the client implementations you either have to add a warning to the docs or become incompatible and add the configurable option of generating random host names the client can't modify with the risk of the CEO having to work under the name farting-hippo.mesh.company.com (depending on the generator used for creation of host names).

Contribution

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

How can it be implemented?

I don't think the feature needs design docs; it already existed in earlier versions.

Originally created by @noseshimself on GitHub (Jan 27, 2025). ### Use case The changes in 0.24 regarding node names is causing collisions which are creating unpleasant situations. ### Description Users can pick their own host name when adding a new system to the mesh Removing the account name as as FQDN component is permitting this to end in two different users picking the same name. This now has led to frequent physical violence over names and the rights to use them in at least one name space. Please reconsider finding a way to deliver separate FQDN name spaces per user as the current implementation drives up medical cost for wound care, jellybeans and other sweets. More seriously: You do not need teenagers to see possible attacks by stupid or malicious users if all are sharing the same name space. It's just not a good idea. As headscale has no control over the client implementations you either have to add a warning to the docs or become incompatible and add the configurable option of generating random host names the client can't modify with the risk of the CEO having to work under the name farting-hippo.mesh.company.com (depending on the generator used for creation of host names). ### Contribution - [ ] I can write the design doc for this feature - [ ] I can contribute this feature ### How can it be implemented? I don't think the feature needs design docs; it already existed in earlier versions.
adam added the enhancementstale labels 2025-12-29 02:26:15 +01:00
adam closed this issue 2025-12-29 02:26:15 +01:00
adam commented 2025-12-29 02:26:16 +01:00
Author
Owner
Copy Link

@tgrushka commented on GitHub (Mar 27, 2025):

Good grief, I want the opposite: re-use same machine name when it re-joins the mesh. How to do it? Docs totally unclear.

And if you're hosting your own headspace, what is all this about physical violence over naming? Just assign users to different namespaces? Maybe the users are the problem here, not the system?

@tgrushka commented on GitHub (Mar 27, 2025): Good grief, I want the opposite: re-use same machine name when it re-joins the mesh. How to do it? Docs totally unclear. And if you're hosting your own headspace, what is all this about physical violence over naming? Just assign users to different namespaces? Maybe the users are the problem here, not the system?
adam commented 2025-12-29 02:26:16 +01:00
Author
Owner
Copy Link

@peskyAdmin commented on GitHub (Apr 9, 2025):

i want a combination of both. machine needs to come back with same dns thats like half the magic. users should be allowed to choose hostname. first come first serve, if there is a collision append a number and increment until there is no collision. i really do want the usernames back though. apple-tv.dad.domain.net and appe-tv.sister.domain.net would be useful because i can get where i need to go just by thinking about it. now i do dad-apple-tv.domain.net, and sister-apple-tv.domain.net and that seems to be fine.

@peskyAdmin commented on GitHub (Apr 9, 2025): i want a combination of both. machine needs to come back with same dns thats like half the magic. users should be allowed to choose hostname. first come first serve, if there is a collision append a number and increment until there is no collision. i really do want the usernames back though. apple-tv.dad.domain.net and appe-tv.sister.domain.net would be useful because i can get where i need to go just by thinking about it. now i do dad-apple-tv.domain.net, and sister-apple-tv.domain.net and that seems to be fine.
adam commented 2025-12-29 02:26:16 +01:00
Author
Owner
Copy Link

@noseshimself commented on GitHub (Apr 9, 2025):

users should be allowed to choose hostname. first come first serve, if there is a collision append a number and increment until there is no collision

There would be no collision if the account name would be used as part of the domain name... Users could do whatever they want without intruding each others' name space.

@noseshimself commented on GitHub (Apr 9, 2025): > users should be allowed to choose hostname. first come first serve, if there is a collision append a number and increment until there is no collision There would be no collision if the account name would be used as part of the domain name... Users could do whatever they want without intruding each others' name space.
adam commented 2025-12-29 02:26:17 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 9, 2025):

This issue is stale because it has been open for 90 days with no activity.

@github-actions[bot] commented on GitHub (Jul 9, 2025): This issue is stale because it has been open for 90 days with no activity.
adam commented 2025-12-29 02:26:17 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 16, 2025):

This issue was closed because it has been inactive for 14 days since being marked as stale.

@github-actions[bot] commented on GitHub (Jul 16, 2025): This issue was closed because it has been inactive for 14 days since being marked as stale.
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 stale
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#927
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?