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

Windows: Cannot resolve public DNS record that's CNAME'd to netbird.cloud entry. #518

New Issue
Open
opened 2025-11-20 05:12:55 -05:00 by saavagebueno · 10 comments
saavagebueno commented 2025-11-20 05:12:55 -05:00
Owner
Copy Link

Originally created by @rhullah on GitHub (Nov 27, 2023).

Describe the problem
I have a public DNS record that's CNAME'd to a *.netbird.cloud entry. In MacOS and Linux, this works and is resolved properly. In Windows, I get an error that it cannot be resolved.

To Reproduce
Steps to reproduce the behavior:

  1. Create public DNS entry: server.domain.com CNAME'd to server.netbird.cloud
  2. On Mac/Linux: ping server.domain.com
  • It should return replies from the IP address
  1. On Windows: ping server.domain.com
  • It returns Ping request could not find host server.domain.com. Please check the name and try again

Expected behavior
Windows should be able to resolve the CNAME DNS record just as Mac/Linus does.

Additional context
I was testing this on Windows 11 Home 22H2

Originally created by @rhullah on GitHub (Nov 27, 2023). **Describe the problem** I have a public DNS record that's CNAME'd to a `*.netbird.cloud` entry. In MacOS and Linux, this works and is resolved properly. In Windows, I get an error that it cannot be resolved. **To Reproduce** Steps to reproduce the behavior: 1. Create public DNS entry: `server.domain.com` CNAME'd to `server.netbird.cloud` 2. On Mac/Linux: `ping server.domain.com` - It should return replies from the IP address 3. On Windows: `ping server.domain.com` - It returns `Ping request could not find host server.domain.com. Please check the name and try again` **Expected behavior** Windows should be able to resolve the CNAME DNS record just as Mac/Linus does. **Additional context** I was testing this on Windows 11 Home 22H2
saavagebueno added the bugmanagement-servicewindows labels 2025-11-20 05:12:55 -05:00
saavagebueno commented 2025-11-20 05:12:56 -05:00
Author
Owner
Copy Link

@GustavooLucio commented on GitHub (Mar 18, 2024):

Any news on this issue ? on windows clients, I can resolve A records, but not CNAME, and they work fine on MacOs and Linux.
Windows 11 22H2
Netbird 0.26.3

@GustavooLucio commented on GitHub (Mar 18, 2024): Any news on this issue ? on windows clients, I can resolve A records, but not CNAME, and they work fine on MacOs and Linux. Windows 11 22H2 Netbird 0.26.3
saavagebueno commented 2025-11-20 05:12:56 -05:00
Author
Owner
Copy Link

@rhullah commented on GitHub (Mar 19, 2024):

I have no update to the issue as I think it's still there. But as a workaround to get it working, I changed it to an A record pointing to the Netbird IP which should be static. Not ideal, but it did work for me.

@rhullah commented on GitHub (Mar 19, 2024): I have no update to the issue as I think it's still there. But as a workaround to get it working, I changed it to an `A` record pointing to the Netbird IP which should be static. Not ideal, but it did work for me.
saavagebueno commented 2025-11-20 05:12:56 -05:00
Author
Owner
Copy Link

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

@rhullah do you still observe the issue?

We have recently implemented CNAME support. The issue might already be solved, so it would be great to close this issue if that is the case.

@nazarewk commented on GitHub (Apr 18, 2025): @rhullah do you still observe the issue? We have recently [implemented CNAME support](https://github.com/netbirdio/netbird/pull/3646). The issue might already be solved, so it would be great to close this issue if that is the case.
saavagebueno commented 2025-11-20 05:12:56 -05:00
Author
Owner
Copy Link

@rhullah commented on GitHub (Apr 22, 2025):

Let me do some testing and see. Thanks for the udpate.

@rhullah commented on GitHub (Apr 22, 2025): Let me do some testing and see. Thanks for the udpate.
saavagebueno commented 2025-11-20 05:12:56 -05:00
Author
Owner
Copy Link

@rhullah commented on GitHub (May 14, 2025):

I just did updated the Windows client to the latest version, 0.43.3, and tested it and I was not able to get it to work under windows. I have a CNAME record setup for host.domain.com pointed to host.netbird.cloud, and it does not resolve on Windows but does resolve on Mac.

@rhullah commented on GitHub (May 14, 2025): I just did updated the Windows client to the latest version, 0.43.3, and tested it and I was not able to get it to work under windows. I have a CNAME record setup for host.domain.com pointed to host.netbird.cloud, and it does not resolve on Windows but does resolve on Mac.
saavagebueno commented 2025-11-20 05:12:57 -05:00
Author
Owner
Copy Link

@nazarewk commented on GitHub (May 15, 2025):

Could you give me some details on how you are configuring the CNAME record to be resolved (if at all) and what commands do you use for testing the resolving process?

@nazarewk commented on GitHub (May 15, 2025): Could you give me some details on how you are configuring the CNAME record to be resolved (if at all) and what commands do you use for testing the resolving process?
saavagebueno commented 2025-11-20 05:12:57 -05:00
Author
Owner
Copy Link

@rhullah commented on GitHub (May 15, 2025):

I'm not doing much. I have Cloudflare, so I setup a standard CNAME record like this:

Image

Then in windows I've mostly been testing to just ping name.domain.com, but I've also tried nslookup name.domain.com. Neither work.

For the ping: I get "Ping request could not find the host name.domain.com. Please check the name and try again."

For nslookup: I notice that it uses my local DNS server (my router since I'm on a home network) and it doesn't give any answer to the query.

@rhullah commented on GitHub (May 15, 2025): I'm not doing much. I have Cloudflare, so I setup a standard CNAME record like this: <img width="1177" alt="Image" src="https://github.com/user-attachments/assets/f56f97da-3ada-4b50-bb5f-b2931ae51de7" /> Then in windows I've mostly been testing to just `ping name.domain.com`, but I've also tried `nslookup name.domain.com`. Neither work. For the `ping`: I get "Ping request could not find the host name.domain.com. Please check the name and try again." For `nslookup`: I notice that it uses my local DNS server (my router since I'm on a home network) and it doesn't give any answer to the query.
saavagebueno commented 2025-11-20 05:12:57 -05:00
Author
Owner
Copy Link

@rhullah commented on GitHub (May 15, 2025):

As far as Netbird configuration, I didn't do any additional configuration.

@rhullah commented on GitHub (May 15, 2025): As far as Netbird configuration, I didn't do any additional configuration.
saavagebueno commented 2025-11-20 05:12:57 -05:00
Author
Owner
Copy Link

@lukababu commented on GitHub (Sep 17, 2025):

I have the same issue; CNAME resolution seems fine on MacOS and Ubuntu, but Debian is another story.

I had to revert the CNAME records to A, but I'm concerned that Netbird might change these static IP addresses, wreaking havoc on my name resolution...

@lukababu commented on GitHub (Sep 17, 2025): I have the same issue; CNAME resolution seems fine on MacOS and Ubuntu, but Debian is another story. I had to revert the CNAME records to A, but I'm concerned that Netbird might change these static IP addresses, wreaking havoc on my name resolution...
saavagebueno commented 2025-11-20 05:12:57 -05:00
Author
Owner
Copy Link

@nazarewk commented on GitHub (Sep 18, 2025):

I have a feeling to make it work correctly you'd need the DNS resolver to also run a NetBird client (it needs to know how to resolve your .netbird.cloud), which is not achievable for public nameservers/resolvers. I am surprised it is working anywhere at all to begin with

The netbird.cloud is a real domain is registered and owned by us (NetBird GmbH) to prevent MITM-ing HTTPS certificates (some random guy buying a domain and issuing valid certificates with letsencrypt). We are not advertising any functioning records on it, so the public nameservers/resolvers have no way of knowing it might be a split-horizon (aka split-brain) DNS setup.

I don't have enough free time on hand to verify this is true, but the general flow is expected to look like following:

  1. Client → Resolver: "What's the A record for name.domain.com?"
  2. Resolver → Auth Server: "What's the A record for name.domain.com?"
  3. Auth Server → Resolver: "name.domain.com CNAME webapp.netbird.cloud"
  4. Resolver → Auth Server: "What's the A record for webapp.netbird.cloud?"
  5. Auth Server → Resolver: "webapp.netbird.cloud A 100.99.123.45"
  6. Resolver → Client: "name.domain.com resolves to 100.99.123.45"

In short: your Client requests an A record and is completely oblivious of the fact that it has CNAME in the middle. The "heavy lifting" part is done on a Resolver, which does all the CNAME handling.

It is possible that both the MacOS and Linux system resolvers are "eagerly"/magically resolving the queries themselves instead of letting upstream handle the CNAME resolution.

I think some form of mitigation to the issue would be adding a domain.com to NetBird's Nameservers (even with a public resolver), but that might still push the local NetBird resolver to ask upstream for an A record and be oblivious to the existence of the CNAME in the middle.

It would definitely help if:

  1. the public nameserver (eg Cloudflare) was pointing name.domain.com as NS record to your own VPS
  2. the VPS would be running an authoritative nameserver for the name.domain.com and NetBird client at the same time
  3. then the Auth Server and Resolver in above flow description would also be both your VPS doing all the resolving of CNAMEs

So:

  1. Client would ask Cloudflare for A record
  2. Cloudflare would ask your VPS for A record
  3. VPS would know that it's a CNAME to netbird.cloud
  4. VPS would resolve CNAME to the specific xxx.netbird.cloud A address
  5. Cloudflare would receive an IP address answer
  6. Client would receive an IP address

I would really appreciate if somebody could run such experiments on their own and share us the results.

@nazarewk commented on GitHub (Sep 18, 2025): I have a feeling to make it work correctly you'd need the DNS resolver to also run a NetBird client (it needs to know how to resolve your `.netbird.cloud`), which is not achievable for public nameservers/resolvers. I am surprised it is working anywhere at all to begin with --- The `netbird.cloud` is a real domain is registered and owned by us (NetBird GmbH) to prevent MITM-ing HTTPS certificates (some random guy buying a domain and issuing valid certificates with letsencrypt). We are not advertising any functioning records on it, so the public nameservers/resolvers have no way of knowing it might be a split-horizon (aka split-brain) DNS setup. --- I don't have enough free time on hand to verify this is true, but the general flow is expected to look like following: 1. Client → Resolver: "What's the `A` record for `name.domain.com`?" 2. Resolver → Auth Server: "What's the `A` record for `name.domain.com`?" 3. Auth Server → Resolver: "name.domain.com `CNAME` `webapp.netbird.cloud`" 4. Resolver → Auth Server: "What's the `A` record for `webapp.netbird.cloud`?" 5. Auth Server → Resolver: "`webapp.netbird.cloud` `A` `100.99.123.45`" 6. Resolver → Client: "name.domain.com resolves to `100.99.123.45`" In short: your Client requests an `A` record and is completely oblivious of the fact that it has `CNAME` in the middle. The "heavy lifting" part is done on a Resolver, which does all the `CNAME` handling. It is possible that both the MacOS and Linux system resolvers are "eagerly"/magically resolving the queries themselves instead of letting upstream handle the `CNAME` resolution. --- I think some form of mitigation to the issue would be adding a `domain.com` to NetBird's Nameservers (even with a public resolver), but that might still push the local NetBird resolver to ask upstream for an `A` record and be oblivious to the existence of the `CNAME` in the middle. --- It would definitely help if: 1. the public nameserver (eg Cloudflare) was pointing `name.domain.com` as `NS` record to your own VPS 2. the VPS would be running an authoritative nameserver for the `name.domain.com` and NetBird client at the same time 3. then the `Auth Server` and `Resolver` in above flow description would also be both your VPS doing all the resolving of CNAMEs So: 1. Client would ask Cloudflare for `A` record 2. Cloudflare would ask your VPS for `A` record 3. VPS would know that it's a `CNAME` to `netbird.cloud` 4. VPS would resolve `CNAME` to the specific `xxx.netbird.cloud` `A` address 5. Cloudflare would receive an IP address answer 6. Client would receive an IP address --- I would really appreciate if somebody could run such experiments on their own and share us the results.
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 bug management-service windows
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#518
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?