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

[Bug] 0.23.0-beta1 wipes resolv.conf on clients regardless of dns_config #748

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

Originally created by @nickbp on GitHub (Jul 25, 2024).

Is this a support request?

  • This is not a support request

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

Possibly related to #2026, I'm noticing that with 0.23.0-beta1, the /etc/resolv.conf on all clients is getting wiped out:

0.23.0-alpha14:
on one client with networkmanager

$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 172.25.0.1

or on a different client with resolvconf

$ cat /etc/resolv.conf 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "resolvectl status" to see details about the actual nameservers.

nameserver 67.207.67.3
nameserver 67.207.67.2

0.23.0-beta1 on all clients:

$ cat /etc/resolv.conf 
# resolv.conf(5) file generated by tailscale
# For more info, see https://tailscale.com/s/resolvconf-overwrite
# DO NOT EDIT THIS FILE BY HAND -- CHANGES WILL BE OVERWRITTEN

search headscale.net

Originally seen with a headscale configuration where dns_config is completely omitted. With beta1 still installed, I tried specifying a dns_config with override_local_dns: false. I also tried adding nameservers: ["172.25.0.1"]. In all cases the issue persisted (/etc/resolv.conf continuing to be wiped)

I reverted back to 0.23.0-alpha14 and the clients immediately went back to their original resolv.conf configs

Expected Behavior

see above

Steps To Reproduce

Installing 0.23.0-beta1 immediately caused the issue (resolv.conf wiped). Reverting to 0.23.0-alpha14 immediately fixed the issue (resolv.conf restored).

Environment

- OS: Arch Linux and Debian Linux
- Headscale version: 0.23.0-beta1
- Tailscale version: 1.68.2

Runtime environment

  • Headscale is behind a (reverse) proxy
  • Headscale runs in a container

Anything else?

No response

Originally created by @nickbp on GitHub (Jul 25, 2024). ### Is this a support request? - [X] This is not a support request ### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior Possibly related to #2026, I'm noticing that with 0.23.0-beta1, the /etc/resolv.conf on all clients is getting wiped out: 0.23.0-alpha14: on one client with networkmanager ``` $ cat /etc/resolv.conf # Generated by NetworkManager nameserver 172.25.0.1 ``` or on a different client with resolvconf ``` $ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # 127.0.0.53 is the systemd-resolved stub resolver. # run "resolvectl status" to see details about the actual nameservers. nameserver 67.207.67.3 nameserver 67.207.67.2 ``` 0.23.0-beta1 on all clients: ``` $ cat /etc/resolv.conf # resolv.conf(5) file generated by tailscale # For more info, see https://tailscale.com/s/resolvconf-overwrite # DO NOT EDIT THIS FILE BY HAND -- CHANGES WILL BE OVERWRITTEN search headscale.net ``` Originally seen with a headscale configuration where `dns_config` is completely omitted. With beta1 still installed, I tried specifying a `dns_config` with `override_local_dns: false`. I also tried adding `nameservers: ["172.25.0.1"]`. In all cases the issue persisted (`/etc/resolv.conf` continuing to be wiped) I reverted back to 0.23.0-alpha14 and the clients immediately went back to their original `resolv.conf` configs ### Expected Behavior see above ### Steps To Reproduce Installing 0.23.0-beta1 immediately caused the issue (resolv.conf wiped). Reverting to 0.23.0-alpha14 immediately fixed the issue (resolv.conf restored). ### Environment ```markdown - OS: Arch Linux and Debian Linux - Headscale version: 0.23.0-beta1 - Tailscale version: 1.68.2 ``` ### Runtime environment - [X] Headscale is behind a (reverse) proxy - [X] Headscale runs in a container ### Anything else? _No response_
adam added the bug label 2025-12-29 02:23:24 +01:00
adam closed this issue 2025-12-29 02:23:24 +01:00
adam commented 2025-12-29 02:23:24 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jul 26, 2024):

I broke DNS in the beta release, but it is also a longstanding bug in Headscale that it didnt overwrite the resolvconf (on machines without a dns manager).

The way to disable overwriting that file is --accept-dns on the desired clients, https://tailscale.com/kb/1235/resolv-conf

So the current issue is that a broken resolvconf gets written. Working on a fix.

@kradalby commented on GitHub (Jul 26, 2024): I broke DNS in the beta release, but it is also a longstanding bug in Headscale that it didnt overwrite the resolvconf (on machines without a dns manager). The way to disable overwriting that file is `--accept-dns` on the desired clients, https://tailscale.com/kb/1235/resolv-conf So the current issue is that a broken resolvconf gets written. Working on a fix.
adam commented 2025-12-29 02:23:24 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jul 26, 2024):

I've started on #2034, with some background on this mess up, would be keen to hear thoughts.

@kradalby commented on GitHub (Jul 26, 2024): I've started on #2034, with some background on this mess up, would be keen to hear thoughts.
adam commented 2025-12-29 02:23:25 +01:00
Author
Owner
Copy Link

@nickbp commented on GitHub (Jul 26, 2024):

Thanks for looking into it!

FWIW from checking that doc I think I'd had dns_config: magic_dns: false in the headscale config and so wouldn't have expected the client resolv.conf files to get changed on that basis

@nickbp commented on GitHub (Jul 26, 2024): Thanks for looking into it! FWIW from checking that doc I think I'd had `dns_config: magic_dns: false` in the headscale config and so wouldn't have expected the client `resolv.conf` files to get changed on that basis
adam commented 2025-12-29 02:23:25 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Aug 1, 2024):

I think #2034 addresses this, would it be possible for you to help me test it? would be great to avoid another bad release like beta1.

Binary is available here: https://github.com/juanfont/headscale/actions/runs/10195837541?pr=2034

@kradalby commented on GitHub (Aug 1, 2024): I think #2034 addresses this, would it be possible for you to help me test it? would be great to avoid another bad release like beta1. Binary is available here: https://github.com/juanfont/headscale/actions/runs/10195837541?pr=2034
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 bug
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#748
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?