[GH-ISSUE #2087] Edit domainnames #4022

Open
opened 2026-08-05 00:55:29 -04:00 by saavagebueno · 7 comments
Owner

Originally created by @twl9 on GitHub (Jun 3, 2024).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/2087

I re-installed a machine and now the hostname is not anymore identical to the domainname.

The first domainname for hostname production-example was production-example.netbird.cloud. After reinstalling this is now production-example-1.netbird.cloud.

I would like to:

  • Change this.
  • Clean up the list of domainnames.

Using the cloud version.

Originally created by @twl9 on GitHub (Jun 3, 2024). Original GitHub issue: https://github.com/netbirdio/netbird/issues/2087 I re-installed a machine and now the hostname is not anymore identical to the domainname. The first domainname for hostname production-example was production-example.netbird.cloud. After reinstalling this is now production-example-1.netbird.cloud. I would like to: - Change this. - Clean up the list of domainnames. Using the cloud version.
saavagebueno added the bug label 2026-08-05 00:55:29 -04:00
Author
Owner

@mlsmaycon commented on GitHub (Jun 3, 2024):

Hello @twl9, this happened because the original production-example peer was in the system, and on domain name collision, we add a -N where N is incremental.

You can update the domain name in the Dashboard by deleting or renaming the original node and then renaming the new peer.

The name edit is available in the individual peer view:

image

<!-- gh-comment-id:2145015076 --> @mlsmaycon commented on GitHub (Jun 3, 2024): Hello @twl9, this happened because the original `production-example` peer was in the system, and on domain name collision, we add a `-N` where N is incremental. You can update the domain name in the Dashboard by deleting or renaming the original node and then renaming the new peer. The name edit is available in the individual peer view: ![image](https://github.com/netbirdio/netbird/assets/7747744/869b7d96-6e8b-42ab-a900-45a8843c95fd)
Author
Owner

@twl9 commented on GitHub (Jun 3, 2024):

@mlsmaycon Clear! This is then a bug, and not a feature request.

Why? The peer was already deleted (before the new peer was added). And the domainname was still not equal to the hostname.

I solved it by changing the hostname fully, and then later back to the orginal name. Its not yet resolving, but I assume a matter of a few minuted.

<!-- gh-comment-id:2145916091 --> @twl9 commented on GitHub (Jun 3, 2024): @mlsmaycon Clear! This is then a bug, and not a feature request. Why? The peer was already deleted (before the new peer was added). And the domainname was still not equal to the hostname. I solved it by changing the hostname fully, and then later back to the orginal name. Its not yet resolving, but I assume a matter of a few minuted.
Author
Owner

@nazarewk commented on GitHub (Apr 23, 2025):

@twl9 are you still having this issue or was it resolved with one of the NetBird updates?

<!-- gh-comment-id:2824662168 --> @nazarewk commented on GitHub (Apr 23, 2025): @twl9 are you still having this issue or was it resolved with one of the NetBird updates?
Author
Owner

@luisepbueno commented on GitHub (Jan 19, 2026):

I can confirm this issue still exists in 0.63.0.

On the client machine that is already registered I ran:

netbird down
systemctl stop netbird
rm -rf /var/lib/netbird

On the controller I manually deleted the peer.

Then, on the client, I registered the peer again but it didn't keep the original domain and added the -N suffix. The hostname is correct, but domain name has the -N suffix.

<!-- gh-comment-id:3769759158 --> @luisepbueno commented on GitHub (Jan 19, 2026): I can confirm this issue still exists in 0.63.0. On the client machine that is already registered I ran: ``` netbird down systemctl stop netbird rm -rf /var/lib/netbird ``` On the controller I manually deleted the peer. Then, on the client, I registered the peer again but it didn't keep the original domain and added the -N suffix. The hostname is correct, but domain name has the -N suffix.
Author
Owner

@1upbyte commented on GitHub (Feb 5, 2026):

+1, this is happening to me too. The host 'macmini' is getting a suffix appended despite being no other hosts called that currently.

Image
<!-- gh-comment-id:3853849585 --> @1upbyte commented on GitHub (Feb 5, 2026): +1, this is happening to me too. The host 'macmini' is getting a suffix appended despite being no other hosts called that currently. <img width="1214" height="1014" alt="Image" src="https://github.com/user-attachments/assets/1854ef70-acc9-4203-83cb-ac5d7dadc694" />
Author
Owner

@hensou commented on GitHub (Apr 25, 2026):

This is happening for me as well, even after removing all peers.

<!-- gh-comment-id:4320229966 --> @hensou commented on GitHub (Apr 25, 2026): This is happening for me as well, even after removing all peers.
Author
Owner

@mmakaay commented on GitHub (May 12, 2026):

I had the same kind of issue when renaming mypeer to mypeer.mydomain.nl.

Current behavior

  • I start with the old name mypeer and Netbird fqdn mypeer.netbird.selfhosted
  • I rename mypeer to mypeer.mydomain.nl
  • I end up with new name mypeer and Netbird fqdn becomes something like mypeer-12-34.netbird.selfhosted
  • The old fqdn mypeer.netbird.selfhosted no longer exists

The code that changes the peer name will use mypeer (by stripping the .mydomain.nl domain part) for the new Netbird hostname. It uses this name to check if the name is already in use. It decides that the name is already in use: the peer itself used mypeer.netbird.selfhosted before the name change. The conclusion from this is to add a suffix, in order to make the name unique.

Expected behavior

I'd say there is no conflict scenario when the target hostname is already held by the peer that is being renamed.

  • I start with the old name mypeer and Netbird fqdn mypeer.netbird.selfhosted
  • I rename mypeer to mypeer.mydomain.nl
  • I end up with new name mypeer and Netbird fqdn still is mypeer.netbird.selfhosted

Work-around

Because I don't always want to fully delete and re-register a peer (e.g. because of the IP address changing), I follow the following route:

  • Rename mypeer to mypeer-temp
  • Rename mypeer-temp to mypeer.mydomain.nl

When following this route, there is no naming "conflict" in the second step, and the in-netbird-network hostname remains mypeer.netbird.selfhosted.

Solution direction

For a solution, I'd suggest that the renaming code should not only inspect if the new hostname already exists in the Netbird inventory, but that it also checks if the ID of the peer being renamed differs from the ID of the peer that was found to hold the target hostname already.

I don't know the code base that well. It might be hard to change this behavior, depending on the code structure around this. If I had to implement it, I think I'd go for an optimistic rename with a fallback in case the optimistic rename fails. In pseudo-code:

PEER_ID=1234
NEW_NAME="mypeer.mydomain.nl"
NEW_HOSTNAME=get_host_from(NEW_NAME)

try
    set_hostname(PEER_ID, NEW_HOSTNAME)
catch HostnameAlreadyExists
    try
        NEW_HOSTNAME_WITH_SUFFIX=NEW_HOSTNAME + make_suffix()
        set_hostname(PEER_ID, NEW_HOSTNAME_WITH_SUFFIX)
    catch HostnameAlreadyExists
        error out
<!-- gh-comment-id:4430195484 --> @mmakaay commented on GitHub (May 12, 2026): I had the same kind of issue when renaming `mypeer` to `mypeer.mydomain.nl`. **Current behavior** - I start with the old name `mypeer` and Netbird fqdn `mypeer.netbird.selfhosted` - I rename `mypeer` to `mypeer.mydomain.nl` - I end up with new name `mypeer` and Netbird fqdn becomes something like `mypeer-12-34.netbird.selfhosted` - The old fqdn `mypeer.netbird.selfhosted` no longer exists The code that changes the peer name will use `mypeer` (by stripping the `.mydomain.nl` domain part) for the new Netbird hostname. It uses this name to check if the name is already in use. It decides that the name is already in use: the peer itself used `mypeer.netbird.selfhosted` before the name change. The conclusion from this is to add a suffix, in order to make the name unique. **Expected behavior** I'd say there is no conflict scenario when the target hostname is already held by the peer that is being renamed. - I start with the old name `mypeer` and Netbird fqdn `mypeer.netbird.selfhosted` - I rename `mypeer` to `mypeer.mydomain.nl` - I end up with new name `mypeer` and Netbird fqdn still is `mypeer.netbird.selfhosted` **Work-around** Because I don't always want to fully delete and re-register a peer (e.g. because of the IP address changing), I follow the following route: - Rename `mypeer` to `mypeer-temp` - Rename `mypeer-temp` to `mypeer.mydomain.nl` When following this route, there is no naming "conflict" in the second step, and the in-netbird-network hostname remains `mypeer.netbird.selfhosted`. **Solution direction** For a solution, I'd suggest that the renaming code should not only inspect if the new hostname already exists in the Netbird inventory, but that it also checks if the ID of the peer being renamed differs from the ID of the peer that was found to hold the target hostname already. I don't know the code base that well. It might be hard to change this behavior, depending on the code structure around this. If I had to implement it, I think I'd go for an optimistic rename with a fallback in case the optimistic rename fails. In pseudo-code: ``` PEER_ID=1234 NEW_NAME="mypeer.mydomain.nl" NEW_HOSTNAME=get_host_from(NEW_NAME) try set_hostname(PEER_ID, NEW_HOSTNAME) catch HostnameAlreadyExists try NEW_HOSTNAME_WITH_SUFFIX=NEW_HOSTNAME + make_suffix() set_hostname(PEER_ID, NEW_HOSTNAME_WITH_SUFFIX) catch HostnameAlreadyExists error out ```
Sign in to join this conversation.
No Label bug
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#4022