SVI/netbird
1
0
Fork 0
mirror of https://github.com/netbirdio/netbird.git synced 2026-05-17 05:32:27 -04:00
Code Issues 3.0k Packages Projects Releases 10 Wiki Activity

Linux client doesn't configure search domains with systemd-resolved #1771

New Issue
Open
opened 2025-11-20 06:06:23 -05:00 by saavagebueno · 5 comments
saavagebueno commented 2025-11-20 06:06:23 -05:00
Owner
Copy Link

Originally created by @JohnDowson on GitHub (Mar 31, 2025).

#> netbird status --details
...
  Networks: *.redacted.svc.cluster.local
...
Nameservers: 
  [100.73.190.112:53] for [corp.redacted.tld] is Available
  [100.73.190.112:53] for [.] is Available
...

#> systemd-resolve --status
...
Link 4 (wt0)
    Current Scopes: DNS
         Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
         Current DNS Server: 100.73.175.207
         DNS Servers: 100.73.175.207
         DNS Domain: netbird.selfhosted 73.100.in-addr.arpa
         Default Route: no

When issuing netbird up, resolver configuration does not get all needed search domains.

Manually doing sudo systemd-resolve --interface=wt0 --set-domain='~redacted.svc.cluster.local' --set-domain='netbird.selfhosted' --set-domain='73.100.in-addr.arpa' gets domain resolution working, but it'd be nice if netbird didn't not do this automatically.

netbird version: 0.39.2

Originally created by @JohnDowson on GitHub (Mar 31, 2025). ```log #> netbird status --details ... Networks: *.redacted.svc.cluster.local ... Nameservers: [100.73.190.112:53] for [corp.redacted.tld] is Available [100.73.190.112:53] for [.] is Available ... ``` ```log #> systemd-resolve --status ... Link 4 (wt0) Current Scopes: DNS Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 100.73.175.207 DNS Servers: 100.73.175.207 DNS Domain: netbird.selfhosted 73.100.in-addr.arpa Default Route: no ``` When issuing `netbird up`, resolver configuration does not get all needed search domains. Manually doing `sudo systemd-resolve --interface=wt0 --set-domain='~redacted.svc.cluster.local' --set-domain='netbird.selfhosted' --set-domain='73.100.in-addr.arpa'` gets domain resolution working, but it'd be nice if netbird didn't not do this automatically. `netbird version: 0.39.2`
saavagebueno added the triage-needed label 2025-11-20 06:06:23 -05:00
saavagebueno commented 2025-11-20 06:06:25 -05:00
Author
Owner
Copy Link

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

How did you configure the *.redacted.svc.cluster.local?

As far as I'm aware, there is no option to configure search domains for anything except Nameservers.

@nazarewk commented on GitHub (Apr 1, 2025): How did you configure the `*.redacted.svc.cluster.local`? As far as I'm aware, there is no option to configure search domains for anything except `Nameserver`s.
saavagebueno commented 2025-11-20 06:06:25 -05:00
Author
Owner
Copy Link

@JohnDowson commented on GitHub (Apr 3, 2025):

How did you configure the *.redacted.svc.cluster.local?

As far as I'm aware, there is no option to configure search domains for anything except Nameservers.

This page in the management console

Image

@JohnDowson commented on GitHub (Apr 3, 2025): > How did you configure the `*.redacted.svc.cluster.local`? > > As far as I'm aware, there is no option to configure search domains for anything except `Nameserver`s. This page in the management console ![Image](https://github.com/user-attachments/assets/a4dcecc6-5182-4f66-8765-4a9e5992409b)
saavagebueno commented 2025-11-20 06:06:25 -05:00
Author
Owner
Copy Link

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

This is as I suspected, you're using Network Resources, which do not support search domains at all.

As a workaround, you can create a Nameserver with match domains for each of your namespaces and "mark domains as search domains" turned on:

Image

The Nameserver has a lower priority than a Network Resource, so it will not interfere (you could put any valid public DNS server and it won't be used as long as there is a matching Resource entry), but it will still register "search domains" with your operating system.

@nazarewk commented on GitHub (Apr 3, 2025): This is as I suspected, you're using Network Resources, which do not support search domains at all. As a workaround, you can create a Nameserver with match domains for each of your namespaces and "mark domains as search domains" turned on: ![Image](https://github.com/user-attachments/assets/ba70163f-514f-4d6d-86b8-dc92a67fdf9b) The Nameserver has a lower priority than a Network Resource, so it will not interfere (you could put any *valid* public DNS server and it won't be used as long as there is a matching Resource entry), but it will still register "search domains" with your operating system.
saavagebueno commented 2025-11-20 06:06:25 -05:00
Author
Owner
Copy Link

@JohnDowson commented on GitHub (Apr 3, 2025):

As a workaround, you can create a Nameserver with match domains for each of your namespaces and "mark domains as search domains" turned on:
...
The Nameserver has a lower priority than a Network Resource, so it will not interfere (you could put any valid public DNS server and it won't be used as long as there is a matching Resource entry), but it will still register "search domains" with your operating system.

We've tried adding a domain for svc.cluster.local to nameserver config, but while that did result in client adding that domain to resolvd config, it also made those domains unresolvable. Not sure if mark domains as search domains was turned on, but that option's description doesn't really imply that it would help here in any way?

@JohnDowson commented on GitHub (Apr 3, 2025): > As a workaround, you can create a Nameserver with match domains for each of your namespaces and "mark domains as search domains" turned on: > ... > The Nameserver has a lower priority than a Network Resource, so it will not interfere (you could put any _valid_ public DNS server and it won't be used as long as there is a matching Resource entry), but it will still register "search domains" with your operating system. We've tried adding a domain for `svc.cluster.local` to nameserver config, but while that did result in client adding that domain to resolvd config, it also made those domains unresolvable. Not sure if `mark domains as search domains` was turned on, but that option's description doesn't really imply that it would help here in any way?
saavagebueno commented 2025-11-20 06:06:25 -05:00
Author
Owner
Copy Link

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

Not sure if mark domains as search domains was turned on, but that option's description doesn't really imply that it would help here in any way?

It is describing exactly what you are looking for (adding the domain to search domains on systemd-resolved) and the only way to achieve it.

We've tried adding a domain for svc.cluster.local to nameserver config, but while that did result in client adding that domain to resolvd config, it also made those domains unresolvable.

You should add each namespace separately (dev.svc.cluster.local), not the top-level svc.cluster.local and turn on the search domains at the same time.

@nazarewk commented on GitHub (Apr 7, 2025): > Not sure if `mark domains as search domains` was turned on, but that option's description doesn't really imply that it would help here in any way? It is describing _exactly_ what you are looking for (adding the domain to `search domains` on `systemd-resolved`) and the only way to achieve it. > We've tried adding a domain for svc.cluster.local to nameserver config, but while that did result in client adding that domain to resolvd config, it also made those domains unresolvable. You should add each namespace separately (`dev.svc.cluster.local`), not the top-level `svc.cluster.local` and turn on the search domains at the same time.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
2021 Q4
2022 Q1
2022 Q1
accessibility
acl
agent
agent
Android
Android
api
authentik
automation
azure
battery-usage
bug
cache
client
client-ui
cloud
cloud-only
cloudflare
community
compatibility
config-idp
config-issue
connection
contribution
coturn
cross-vpn
dashboard
data-usage
distribution
dns
docker
documentation
duplicate
enhancement
enhancement
event-stream
feature-request
freebsd
getting-started
go
good first issue
gui
help wanted
home-assistant
idp
inconsistency
integration
integrations
ios
ipv6
jwt
k8s
keycloak
linux
login
macos
management-service
missing-docs
mobile
moved-internal
needs-review
netbird-ui
networking
new-platform
nginx
notification
okta
openwrt
packaging
peer-management
peer-management
peer-management
performance
postgres
posture-checks
psk
pull-request
Mirrored from GitHub Pull Request
 question
refactor
relay
release
rfc
routes
security
security-related
self-hosting
server
signal
sleep-issue
ssh
ssl
status
store
synology
system-compatibility-issue
test-suite
third-party-integration
triage
triage-needed
troubleshooting
UX
waiting-feedback
windows
wontfix
zitadel
No Label triage-needed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/netbird#1771
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?