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

[Question] Node names in netmap do not have a dot appended to their FQDN #985

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

Originally created by @thirdeyenick on GitHub (Mar 25, 2025).

Use case

We are working on some software which makes use of the netmap distributed to tailscale clients.

Description

When experimenting with a self deployed headscale control server and also tailscale.com upstream services, we found that when doing a tailscale debug netmap on a connected tailscale client, there is a difference when using the upstream tailscale.com services vs. using a headscale control server:

The node names in the "Peers" section of the netmap do have a dot (".") appended to their FQDN when using tailscale.com services. When using headscale, the dot at the end is missing. According to the comments on the corresponding struct field a dot should be appended. We were asking ourselves if there is a specific reason why the dot is missing in the headscale case?

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 @thirdeyenick on GitHub (Mar 25, 2025). ### Use case We are working on some software which makes use of the netmap distributed to tailscale clients. ### Description When experimenting with a self deployed headscale control server and also tailscale.com upstream services, we found that when doing a `tailscale debug netmap` on a connected tailscale client, there is a difference when using the upstream tailscale.com services vs. using a headscale control server: The node names in the "Peers" section of the netmap do have a dot (".") appended to their FQDN when using tailscale.com services. When using headscale, the dot at the end is missing. According to the comments on the [corresponding struct field](https://github.com/tailscale/tailscale/blob/e78055eb0106a612896c22f566468b0e6a1071d2/tailcfg/tailcfg.go#L321) a dot should be appended. We were asking ourselves if there is a specific reason why the dot is missing in the headscale case? ### 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:27:04 +01:00
adam closed this issue 2025-12-29 02:27:04 +01:00
adam commented 2025-12-29 02:27:04 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Mar 26, 2025):

Probably an oversight, feel free to make a PR.

@kradalby commented on GitHub (Mar 26, 2025): Probably an oversight, feel free to make a PR.
adam commented 2025-12-29 02:27:05 +01:00
Author
Owner
Copy Link

@thirdeyenick commented on GitHub (Mar 26, 2025):

Thx for the fast response. Will look into a PR...

@thirdeyenick commented on GitHub (Mar 26, 2025): Thx for the fast response. Will look into a PR...
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#985
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?