[GH-ISSUE #5647] Upstream nameserver NXDOMAIN overrides DNS-based network route resolution #11833

Open
opened 2026-08-05 01:31:13 -04:00 by saavagebueno · 3 comments
Owner

Originally created by @benosman on GitHub (Mar 21, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5647

Describe the problem

When routing peers advertise DNS-based network routes (e.g., myservice.mynamespace.svc.cluster.local), the NetBird DNS resolver (100.68.255.254) fails to resolve these hostnames if the configured upstream nameserver group returns NXDOMAIN for them.

Public DNS resolvers like Google (8.8.8.8) and Cloudflare (1.1.1.1) return NXDOMAIN for .local domains (reserved by RFC 6762) and any other non-existent domain. This NXDOMAIN response overrides the internal routing peer network route DNS resolution, making DNS-based network routes unusable with public upstream nameservers.

This also breaks custom DNS zone CNAME records pointing to routing peer network hostnames — the CNAME is resolved from the zone, but the CNAME target fails because the upstream returns NXDOMAIN, resulting in SERVFAIL.

The issue does NOT occur when the upstream nameserver returns NOERROR with an empty answer (as some home routers do for .local queries).

To Reproduce

  1. Set up a routing peer that advertises DNS-based network routes (e.g., myservice.mynamespace.svc.cluster.local)

  2. Verify the peer shows the network in netbird status -d output

  3. Configure a nameserver group with Google DNS (8.8.8.8) as a catch-all (no domains filter)

  4. Run: nslookup myservice.mynamespace.svc.cluster.local 100.68.255.254

  5. Result: NXDOMAIN — upstream response overrides routing peer network resolution

  6. Switch the nameserver group to a DNS server that returns NOERROR (empty) for unknown domains

  7. Run the same lookup

  8. Result: Resolves correctly to the expected IP via the routing peer

Additional reproduction with custom DNS zones:

  1. Create a custom DNS zone with a CNAME record: myapp.example.com → CNAME → myservice.mynamespace.svc.cluster.local
  2. With public DNS as upstream: nslookup myapp.example.com 100.68.255.254SERVFAIL
  3. With a benign upstream: same lookup → Resolves correctly (CNAME chased, target resolved via routing peer)

Expected behavior

DNS-based network routes advertised by routing peers should resolve internally regardless of upstream nameserver responses. Routing peer network resolution should take priority over upstream NXDOMAIN for hostnames matching an advertised network route.

Are you using NetBird Cloud?

Yes

NetBird version

0.66.4 (client, daemon, and routing peers)

Is any other VPN software installed?

No

Debug output

❯ netbird status -dA                                                          
Peers detail:
 router-6b6496d587-lgnb5-107-8.netbird.anon-WtoSq.domain:
  NetBird IP: 100.68.107.8
  Public key: 81gLd0V9ZsEZHHrCNMfebgJG6X04IUcB3qTlFqpivjI=
  Status: Connected
  -- detail --
  Connection type: Relayed
  ICE candidate (Local/Remote): -/-
  ICE candidate endpoints (Local/Remote): -/-
  Relay server address: rels://streamline-uk-lon1-1.relay.netbird.io:443
  Last connection update: 3 minutes, 55 seconds ago
  Last WireGuard handshake: 1 minute, 33 seconds ago
  Transfer status (received/sent) 360 B/792 B
  Quantum resistance: false
  Networks: 10.2.1.0/24, internal.kgateway-system.ldn-2.svc.cluster.anon-WtoSq.domain, k8s-gateway.k8s-gateway.ldn-2.svc.cluster.anon-WtoSq.domain, test-dragonfly.databases-test.ldn-2.svc.cluster.anon-WtoSq.domain, test-mariadb.databases-test.ldn-2.svc.cluster.anon-WtoSq.domain, test-postgres.databases-test.ldn-2.svc.cluster.anon-WtoSq.domain, victorialogs-netbird.monitoring.ldn-2.svc.cluster.anon-WtoSq.domain, victoriametrics-netbird.monitoring.ldn-2.svc.cluster.anon-WtoSq.domain
  Latency: 0s

 router-b9754c847-xnj22-125-245.netbird.anon-WtoSq.domain:
  NetBird IP: 100.68.125.245
  Public key: YCFU0GzWj6r1frGm1cv2a4jjO8aapw8uIaoZ9GxGi1s=
  Status: Connected
  -- detail --
  Connection type: Relayed
  ICE candidate (Local/Remote): -/-
  ICE candidate endpoints (Local/Remote): -/-
  Relay server address: rels://streamline-uk-lon1-1.relay.netbird.io:443
  Last connection update: 3 minutes, 52 seconds ago
  Last WireGuard handshake: 1 minute, 47 seconds ago
  Transfer status (received/sent) 216 B/648 B
  Quantum resistance: false
  Networks: -
  Latency: 0s

 netbird-sidecar-test-7f85b7775d-24dt2-170-163.netbird.anon-WtoSq.domain:
  NetBird IP: 100.68.170.163
  Public key: G3nfUePGksrQOCCecGVj7Xk3MeF1n2D1JHRx0aUja0Y=
  Status: Connected
  -- detail --
  Connection type: Relayed
  ICE candidate (Local/Remote): -/-
  ICE candidate endpoints (Local/Remote): -/-
  Relay server address: rels://streamline-uk-lon1-1.relay.netbird.io:443
  Last connection update: 3 minutes, 52 seconds ago
  Last WireGuard handshake: 1 minute, 47 seconds ago
  Transfer status (received/sent) 216 B/648 B
  Quantum resistance: false
  Networks: -
  Latency: 0s

 router-b9754c847-qk4tl-188-11.netbird.anon-WtoSq.domain:
  NetBird IP: 100.68.188.11
  Public key: PDkCopKOepfzgifTu7qC8LsVRfF5BqesSCsFuwKTl1A=
  Status: Connected
  -- detail --
  Connection type: Relayed
  ICE candidate (Local/Remote): -/-
  ICE candidate endpoints (Local/Remote): -/-
  Relay server address: rels://streamline-uk-lon1-1.relay.netbird.io:443
  Last connection update: 3 minutes, 55 seconds ago
  Last WireGuard handshake: 1 minute, 36 seconds ago
  Transfer status (received/sent) 472 B/904 B
  Quantum resistance: false
  Networks: 10.3.1.0/24, internal.kgateway-system.italia.svc.anon-K2hnC.domain, k8s-gateway.k8s-gateway.italia.svc.anon-K2hnC.domain
  Latency: 0s

 router-6b6496d587-sm5fw-194-145.netbird.anon-WtoSq.domain:
  NetBird IP: 100.68.194.145
  Public key: DyvPZq11p7yyDoMRda4DTGiH4OXxe8R3cgyCW+MJsAo=
  Status: Connected
  -- detail --
  Connection type: Relayed
  ICE candidate (Local/Remote): -/-
  ICE candidate endpoints (Local/Remote): -/-
  Relay server address: rels://streamline-uk-lon1-1.relay.netbird.io:443
  Last connection update: 3 minutes, 52 seconds ago
  Last WireGuard handshake: 1 minute, 48 seconds ago
  Transfer status (received/sent) 216 B/648 B
  Quantum resistance: false
  Networks: -
  Latency: 0s

Events:
  [INFO] SYSTEM (78c70e88-77c2-4ada-84b8-5320347661c9)
    Message: Network map updated
    Time: 11 minutes, 2 seconds ago
  [INFO] SYSTEM (7410720a-bc95-4dc6-821f-8a7e17b6dd3b)
    Message: Network map updated
    Time: 11 minutes ago
  [INFO] SYSTEM (c9634a0c-d242-438b-bac6-355ef84cd0e3)
    Message: Network map updated
    Time: 10 minutes, 58 seconds ago
  [INFO] SYSTEM (30d36af6-9575-4e6a-8d3e-b9b19e5c44f2)
    Message: Network map updated
    Time: 10 minutes, 56 seconds ago
  [INFO] SYSTEM (92e180af-63d4-4d5f-92d8-44be0088ad9d)
    Message: Network map updated
    Time: 10 minutes, 53 seconds ago
  [INFO] SYSTEM (7e9c2de1-f376-471a-97c3-21185423847a)
    Message: Network map updated
    Time: 4 minutes, 48 seconds ago
  [INFO] SYSTEM (bcd971dc-c6aa-4729-9c02-db99097d1328)
    Message: Network map updated
    Time: 4 minutes, 14 seconds ago
  [INFO] SYSTEM (1d94d8e3-d570-4d19-83fd-30a1c757fb8f)
    Message: Network map updated
    Time: 4 minutes, 12 seconds ago
  [INFO] SYSTEM (d03f8fb2-4a84-4e01-82c2-56bd791e8426)
    Message: Network map updated
    Time: 4 minutes, 2 seconds ago
  [INFO] SYSTEM (dc5310d1-f406-4b4b-920b-8ebe83969a48)
    Message: Network map updated
    Time: 3 minutes, 55 seconds ago
OS: darwin/arm64
Daemon version: 0.66.4
CLI version: 0.66.4
Profile: default
Management: Connected to https://api.netbird.io:443
Signal: Connected to https://signal.netbird.io:443
Relays: 
  [stun:stun.netbird.io:443] is Available
  [stun:stun.netbird.io:5555] is Available
  [turns:turn.netbird.io:443?transport=tcp] is Available
  [rels://streamline-uk-lon1-1.relay.netbird.io:443] is Available
Nameservers: 
  [8.8.8.8:53, 8.8.4.4:53] for [.] is Available
FQDN: mbp.netbird.anon-WtoSq.domain
NetBird IP: 100.68.55.174/16
Interface type: Userspace
Quantum resistance: false
Lazy connection: false
SSH Server: Disabled
Networks: -
Peers count: 5/5 Connected
> netbird debug for 1m -AS -U
Upload file key:
f79e391890ab27fb37c88b3b4be7011e22aa2e5ca6f38ffa9c4481884941f726/9f169ed3-2eab-4b36-a41b-3dc644a0824d

Screenshots

Working (upstream returns NOERROR):

❯ nslookup myservice.mynamespace.svc.cluster.local 100.68.255.254
Server:     100.68.255.254
Address:    100.68.255.254#53

Name:   myservice.mynamespace.svc.cluster.local
Address: 10.x.x.x

Broken (upstream returns NXDOMAIN):

❯ nslookup myservice.mynamespace.svc.cluster.local 100.68.255.254
Server:     100.68.255.254
Address:    100.68.255.254#53

** server can't find myservice.mynamespace.svc.cluster.local: NXDOMAIN

CNAME chasing fails:

❯ nslookup myapp.example.com 100.68.255.254
Server:     100.68.255.254
Address:    100.68.255.254#53

** server can't find myapp.example.com: SERVFAIL

Additional context

  • The behavior difference is entirely determined by the upstream nameserver response code (NOERROR vs NXDOMAIN)
  • Tested with Google DNS, Cloudflare DNS, and OCI VCN DNS (169.254.169.254) — all return NXDOMAIN, all prevent routing peer DNS resolution
  • A home router that returns NOERROR for .local queries allows routing peer DNS resolution to work
  • Setting domains on the only nameserver group removes the catch-all, breaking general DNS
  • Using the NetBird resolver IP (100.68.255.254) as a domains-matched nameserver causes an infinite loop (SERVFAIL)
  • There is no practical workaround — no public DNS returns NOERROR for non-existent domains
  • This affects Kubernetes integration where routing peers advertise .svc.cluster.local service hostnames

Have you tried these troubleshooting steps?

  • Reviewed client troubleshooting (if applicable)
  • Checked for newer NetBird versions
  • Searched for similar issues on GitHub (including closed ones)
  • Restarted the NetBird client
  • Disabled other VPN software
  • Checked firewall settings
Originally created by @benosman on GitHub (Mar 21, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5647 **Describe the problem** When routing peers advertise DNS-based network routes (e.g., `myservice.mynamespace.svc.cluster.local`), the NetBird DNS resolver (100.68.255.254) fails to resolve these hostnames if the configured upstream nameserver group returns `NXDOMAIN` for them. Public DNS resolvers like Google (8.8.8.8) and Cloudflare (1.1.1.1) return `NXDOMAIN` for `.local` domains (reserved by RFC 6762) and any other non-existent domain. This NXDOMAIN response overrides the internal routing peer network route DNS resolution, making DNS-based network routes unusable with public upstream nameservers. This also breaks custom DNS zone CNAME records pointing to routing peer network hostnames — the CNAME is resolved from the zone, but the CNAME target fails because the upstream returns NXDOMAIN, resulting in SERVFAIL. The issue does NOT occur when the upstream nameserver returns `NOERROR` with an empty answer (as some home routers do for `.local` queries). **To Reproduce** 1. Set up a routing peer that advertises DNS-based network routes (e.g., `myservice.mynamespace.svc.cluster.local`) 2. Verify the peer shows the network in `netbird status -d` output 3. Configure a nameserver group with Google DNS (8.8.8.8) as a catch-all (no `domains` filter) 4. Run: `nslookup myservice.mynamespace.svc.cluster.local 100.68.255.254` 5. Result: **NXDOMAIN** — upstream response overrides routing peer network resolution 6. Switch the nameserver group to a DNS server that returns `NOERROR` (empty) for unknown domains 7. Run the same lookup 8. Result: **Resolves correctly** to the expected IP via the routing peer Additional reproduction with custom DNS zones: 1. Create a custom DNS zone with a CNAME record: `myapp.example.com → CNAME → myservice.mynamespace.svc.cluster.local` 2. With public DNS as upstream: `nslookup myapp.example.com 100.68.255.254` → **SERVFAIL** 3. With a benign upstream: same lookup → **Resolves correctly** (CNAME chased, target resolved via routing peer) **Expected behavior** DNS-based network routes advertised by routing peers should resolve internally regardless of upstream nameserver responses. Routing peer network resolution should take priority over upstream NXDOMAIN for hostnames matching an advertised network route. **Are you using NetBird Cloud?** Yes **NetBird version** 0.66.4 (client, daemon, and routing peers) **Is any other VPN software installed?** No **Debug output** ``` ❯ netbird status -dA Peers detail: router-6b6496d587-lgnb5-107-8.netbird.anon-WtoSq.domain: NetBird IP: 100.68.107.8 Public key: 81gLd0V9ZsEZHHrCNMfebgJG6X04IUcB3qTlFqpivjI= Status: Connected -- detail -- Connection type: Relayed ICE candidate (Local/Remote): -/- ICE candidate endpoints (Local/Remote): -/- Relay server address: rels://streamline-uk-lon1-1.relay.netbird.io:443 Last connection update: 3 minutes, 55 seconds ago Last WireGuard handshake: 1 minute, 33 seconds ago Transfer status (received/sent) 360 B/792 B Quantum resistance: false Networks: 10.2.1.0/24, internal.kgateway-system.ldn-2.svc.cluster.anon-WtoSq.domain, k8s-gateway.k8s-gateway.ldn-2.svc.cluster.anon-WtoSq.domain, test-dragonfly.databases-test.ldn-2.svc.cluster.anon-WtoSq.domain, test-mariadb.databases-test.ldn-2.svc.cluster.anon-WtoSq.domain, test-postgres.databases-test.ldn-2.svc.cluster.anon-WtoSq.domain, victorialogs-netbird.monitoring.ldn-2.svc.cluster.anon-WtoSq.domain, victoriametrics-netbird.monitoring.ldn-2.svc.cluster.anon-WtoSq.domain Latency: 0s router-b9754c847-xnj22-125-245.netbird.anon-WtoSq.domain: NetBird IP: 100.68.125.245 Public key: YCFU0GzWj6r1frGm1cv2a4jjO8aapw8uIaoZ9GxGi1s= Status: Connected -- detail -- Connection type: Relayed ICE candidate (Local/Remote): -/- ICE candidate endpoints (Local/Remote): -/- Relay server address: rels://streamline-uk-lon1-1.relay.netbird.io:443 Last connection update: 3 minutes, 52 seconds ago Last WireGuard handshake: 1 minute, 47 seconds ago Transfer status (received/sent) 216 B/648 B Quantum resistance: false Networks: - Latency: 0s netbird-sidecar-test-7f85b7775d-24dt2-170-163.netbird.anon-WtoSq.domain: NetBird IP: 100.68.170.163 Public key: G3nfUePGksrQOCCecGVj7Xk3MeF1n2D1JHRx0aUja0Y= Status: Connected -- detail -- Connection type: Relayed ICE candidate (Local/Remote): -/- ICE candidate endpoints (Local/Remote): -/- Relay server address: rels://streamline-uk-lon1-1.relay.netbird.io:443 Last connection update: 3 minutes, 52 seconds ago Last WireGuard handshake: 1 minute, 47 seconds ago Transfer status (received/sent) 216 B/648 B Quantum resistance: false Networks: - Latency: 0s router-b9754c847-qk4tl-188-11.netbird.anon-WtoSq.domain: NetBird IP: 100.68.188.11 Public key: PDkCopKOepfzgifTu7qC8LsVRfF5BqesSCsFuwKTl1A= Status: Connected -- detail -- Connection type: Relayed ICE candidate (Local/Remote): -/- ICE candidate endpoints (Local/Remote): -/- Relay server address: rels://streamline-uk-lon1-1.relay.netbird.io:443 Last connection update: 3 minutes, 55 seconds ago Last WireGuard handshake: 1 minute, 36 seconds ago Transfer status (received/sent) 472 B/904 B Quantum resistance: false Networks: 10.3.1.0/24, internal.kgateway-system.italia.svc.anon-K2hnC.domain, k8s-gateway.k8s-gateway.italia.svc.anon-K2hnC.domain Latency: 0s router-6b6496d587-sm5fw-194-145.netbird.anon-WtoSq.domain: NetBird IP: 100.68.194.145 Public key: DyvPZq11p7yyDoMRda4DTGiH4OXxe8R3cgyCW+MJsAo= Status: Connected -- detail -- Connection type: Relayed ICE candidate (Local/Remote): -/- ICE candidate endpoints (Local/Remote): -/- Relay server address: rels://streamline-uk-lon1-1.relay.netbird.io:443 Last connection update: 3 minutes, 52 seconds ago Last WireGuard handshake: 1 minute, 48 seconds ago Transfer status (received/sent) 216 B/648 B Quantum resistance: false Networks: - Latency: 0s Events: [INFO] SYSTEM (78c70e88-77c2-4ada-84b8-5320347661c9) Message: Network map updated Time: 11 minutes, 2 seconds ago [INFO] SYSTEM (7410720a-bc95-4dc6-821f-8a7e17b6dd3b) Message: Network map updated Time: 11 minutes ago [INFO] SYSTEM (c9634a0c-d242-438b-bac6-355ef84cd0e3) Message: Network map updated Time: 10 minutes, 58 seconds ago [INFO] SYSTEM (30d36af6-9575-4e6a-8d3e-b9b19e5c44f2) Message: Network map updated Time: 10 minutes, 56 seconds ago [INFO] SYSTEM (92e180af-63d4-4d5f-92d8-44be0088ad9d) Message: Network map updated Time: 10 minutes, 53 seconds ago [INFO] SYSTEM (7e9c2de1-f376-471a-97c3-21185423847a) Message: Network map updated Time: 4 minutes, 48 seconds ago [INFO] SYSTEM (bcd971dc-c6aa-4729-9c02-db99097d1328) Message: Network map updated Time: 4 minutes, 14 seconds ago [INFO] SYSTEM (1d94d8e3-d570-4d19-83fd-30a1c757fb8f) Message: Network map updated Time: 4 minutes, 12 seconds ago [INFO] SYSTEM (d03f8fb2-4a84-4e01-82c2-56bd791e8426) Message: Network map updated Time: 4 minutes, 2 seconds ago [INFO] SYSTEM (dc5310d1-f406-4b4b-920b-8ebe83969a48) Message: Network map updated Time: 3 minutes, 55 seconds ago OS: darwin/arm64 Daemon version: 0.66.4 CLI version: 0.66.4 Profile: default Management: Connected to https://api.netbird.io:443 Signal: Connected to https://signal.netbird.io:443 Relays: [stun:stun.netbird.io:443] is Available [stun:stun.netbird.io:5555] is Available [turns:turn.netbird.io:443?transport=tcp] is Available [rels://streamline-uk-lon1-1.relay.netbird.io:443] is Available Nameservers: [8.8.8.8:53, 8.8.4.4:53] for [.] is Available FQDN: mbp.netbird.anon-WtoSq.domain NetBird IP: 100.68.55.174/16 Interface type: Userspace Quantum resistance: false Lazy connection: false SSH Server: Disabled Networks: - Peers count: 5/5 Connected ``` ``` > netbird debug for 1m -AS -U Upload file key: f79e391890ab27fb37c88b3b4be7011e22aa2e5ca6f38ffa9c4481884941f726/9f169ed3-2eab-4b36-a41b-3dc644a0824d ``` **Screenshots** Working (upstream returns NOERROR): ``` ❯ nslookup myservice.mynamespace.svc.cluster.local 100.68.255.254 Server: 100.68.255.254 Address: 100.68.255.254#53 Name: myservice.mynamespace.svc.cluster.local Address: 10.x.x.x ``` Broken (upstream returns NXDOMAIN): ``` ❯ nslookup myservice.mynamespace.svc.cluster.local 100.68.255.254 Server: 100.68.255.254 Address: 100.68.255.254#53 ** server can't find myservice.mynamespace.svc.cluster.local: NXDOMAIN ``` CNAME chasing fails: ``` ❯ nslookup myapp.example.com 100.68.255.254 Server: 100.68.255.254 Address: 100.68.255.254#53 ** server can't find myapp.example.com: SERVFAIL ``` **Additional context** - The behavior difference is entirely determined by the upstream nameserver response code (`NOERROR` vs `NXDOMAIN`) - Tested with Google DNS, Cloudflare DNS, and OCI VCN DNS (169.254.169.254) — all return NXDOMAIN, all prevent routing peer DNS resolution - A home router that returns NOERROR for `.local` queries allows routing peer DNS resolution to work - Setting `domains` on the only nameserver group removes the catch-all, breaking general DNS - Using the NetBird resolver IP (100.68.255.254) as a `domains`-matched nameserver causes an infinite loop (SERVFAIL) - There is no practical workaround — no public DNS returns `NOERROR` for non-existent domains - This affects Kubernetes integration where routing peers advertise `.svc.cluster.local` service hostnames **Have you tried these troubleshooting steps?** - [x] Reviewed [client troubleshooting](https://docs.netbird.io/how-to/troubleshooting-client) (if applicable) - [x] Checked for newer NetBird versions - [x] Searched for similar issues on GitHub (including closed ones) - [x] Restarted the NetBird client - [x] Disabled other VPN software - [x] Checked firewall settings
saavagebueno added the triage-needed label 2026-08-05 01:31:13 -04:00
Author
Owner

@lixmal commented on GitHub (Mar 21, 2026):

Routing peer network resolution should take priority

There's no such thing (how would it know what IP to serve, you didn't define this anywhere, right?). The routing peer asks the OS, which usually delegates back to netbird. Netbird then just does the regular lookup.

If you point netbird to your upstream resolver that's what it will ask. You can use match domains for that .local zone or custom DNS zones if you want to override that.

<!-- gh-comment-id:4104108207 --> @lixmal commented on GitHub (Mar 21, 2026): > Routing peer network resolution should take priority There's no such thing (how would it know what IP to serve, you didn't define this anywhere, right?). The routing peer asks the OS, which usually delegates back to netbird. Netbird then just does the regular lookup. If you point netbird to your upstream resolver that's what it will ask. You can use match domains for that .local zone or custom DNS zones if you want to override that.
Author
Owner

@benosman commented on GitHub (Mar 21, 2026):

Routing peer network resolution should take priority

There's no such thing (how would it know what IP to serve, you didn't define this anywhere, right?). The routing peer asks the OS, which usually delegates back to netbird. Netbird then just does the regular lookup.

If you point netbird to your upstream resolver that's what it will ask. You can use match domains for that .local zone or custom DNS zones if you want to override that.

Thanks for the clarification. To be clear — the domains I'm trying to resolve are the network resource hostnames created by the NetBird operator itself. For example, the operator advertises:

Hostnames: internal.kgateway-system.ldn-2.svc.cluster.local, internal.kgateway-system.ldn-2.svc.cluster.local
These are Kubernetes services exposed as network resources via the kubernetes operator..

So the question is: how should a client peer resolve the DNS-based network resource hostnames that the operator creates?

For now I'm working around this with A records in a custom DNS zone, but that breaks policy matching since the traffic goes to a raw IP rather than being associated with the DNS-based network resource.

<!-- gh-comment-id:4104428962 --> @benosman commented on GitHub (Mar 21, 2026): > > Routing peer network resolution should take priority > > There's no such thing (how would it know what IP to serve, you didn't define this anywhere, right?). The routing peer asks the OS, which usually delegates back to netbird. Netbird then just does the regular lookup. > > If you point netbird to your upstream resolver that's what it will ask. You can use match domains for that .local zone or custom DNS zones if you want to override that. Thanks for the clarification. To be clear — the domains I'm trying to resolve are the network resource hostnames created by the NetBird operator itself. For example, the operator advertises: Hostnames: `internal.kgateway-system.ldn-2.svc.cluster.local`, `internal.kgateway-system.ldn-2.svc.cluster.local` These are Kubernetes services exposed as network resources via the kubernetes operator.. So the question is: how should a client peer resolve the DNS-based network resource hostnames that the operator creates? For now I'm working around this with A records in a custom DNS zone, but that breaks policy matching since the traffic goes to a raw IP rather than being associated with the DNS-based network resource.
Author
Owner

@benosman commented on GitHub (Apr 4, 2026):

Perhaps this isn't something that isn't supposed to work, the strange thing is it did work when dns was set to my LAN router (a Mikrotik one) but doesn't work on any other nameservers.

Now that you have the concept of dns zones and records inside netbird, it seems a bit of an obvious feature to be able to look up records of network resources as netbird has that information, the host and the ip.

I've had to change approach and add internal nameservers for each cluster, which is a lot more hassle but works reliably.

<!-- gh-comment-id:4187056759 --> @benosman commented on GitHub (Apr 4, 2026): Perhaps this isn't something that isn't supposed to work, the strange thing is it did work when dns was set to my LAN router (a Mikrotik one) but doesn't work on any other nameservers. Now that you have the concept of dns zones and records inside netbird, it seems a bit of an obvious feature to be able to look up records of network resources as netbird has that information, the host and the ip. I've had to change approach and add internal nameservers for each cluster, which is a lot more hassle but works reliably.
Sign in to join this conversation.
No Label triage-needed
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11833