[GH-ISSUE #5654] Domain network resources never resolve IPs - no retry after WireGuard handshake completes #11842

Closed
opened 2026-08-05 01:31:16 -04:00 by saavagebueno · 2 comments
Owner

Originally created by @nuclon on GitHub (Mar 23, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5654

Description

Domain-type network resources permanently show Resolved IPs: - because the initial DNS resolution attempt happens before the WireGuard handshake completes, and there is no retry mechanism after connectivity is established.

Environment

  • Self-hosted NetBird management v0.66.4 (Helm chart 1.9.0)
  • Clients: macOS (userspace) v0.66.4, Ubuntu v0.66.4
  • Network setup: AWS VPC with routing peer, domain resources pointing to *.corp.internal internal DNS names

Setup

  • Network with routing peer in AWS VPC
  • DNS nameserver configured for corp.internal → VPC DNS 172.31.0.2
  • Domain resources (e.g., db.corp.internal, node01.corp.internal)
  • IP-based resource for DNS (172.31.0.2/32) works fine
  • Subnet resource (172.31.0.0/16) for another group works fine

Reproduction

  1. Create a Network with a routing peer
  2. Add domain-type resources (e.g., db.corp.internal)
  3. Create access policies granting a group access to these resources
  4. Connect a client in that group
  5. Run netbird routes list — domain resources show Resolved IPs: - permanently

Debug log timeline

11:29:09 - Routes assigned, routing peer "not available" yet
11:29:09 - DNS match domains registered as extra match domains
11:29:09 - Upstream probe to 172.31.0.2:53 fails (timeout - tunnel not ready)
11:29:09 - "Upstream resolving is Disabled for 30s"
11:29:12 - "upstreams 172.31.0.2:53 are responsive again"
11:29:13 - DNS queries fail: "NO_RECENT_HANDSHAKE no_handshake via_relay"
11:29:39 - "first wg handshake detected" — tunnel is now UP
11:29:39+  — NO domain resolution retry ever happens

After the WireGuard handshake completes at 11:29:39, the tunnel is fully operational. IP-based resources work. Manual nslookup db.corp.internal 172.31.0.2 resolves correctly. But domain resources stay at Resolved IPs: - forever.

Key log lines

INFO  routemanager/client/client.go:237: network [db.corp.internal] has not been assigned a routing peer as no peers from the list [...] are currently available
INFO  routemanager/client/client.go:249: New chosen route is ... for network [db.corp.internal]
DEBG  dns/server.go:642: extra match domains: [files.corp.internal. node01.corp.internal. db.corp.internal. ...]
WARN  dns/upstream.go:292: probing upstream nameserver 172.31.0.2:53: with udp: read udp ...: i/o timeout
WARN  dns/upstream.go:386: Upstream resolving is Disabled for 30s
INFO  dns/upstream.go:364: upstreams 172.31.0.2:53 are responsive again
ERRO  dns/upstream.go:241: 1/1 upstreams failed for domain=db._dns-sd._udp.corp.internal.: 172.31.0.2:53=timeout after 4s (routes through NetBird peer routing-peer...:100.101.x.x NO_RECENT_HANDSHAKE no_handshake via_relay)
INFO  peer/wg_watcher.go:110: first wg handshake detected within: 0.00sec

Expected behavior

After the WireGuard handshake completes successfully, domain resources should retry DNS resolution and populate Resolved IPs so that traffic can be routed.

Workaround

Using subnet-type resources (IP-based) instead of domain-type resources works correctly, as they don't depend on DNS resolution for route creation.

Originally created by @nuclon on GitHub (Mar 23, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5654 ## Description Domain-type network resources permanently show `Resolved IPs: -` because the initial DNS resolution attempt happens before the WireGuard handshake completes, and there is no retry mechanism after connectivity is established. ## Environment - Self-hosted NetBird management v0.66.4 (Helm chart 1.9.0) - Clients: macOS (userspace) v0.66.4, Ubuntu v0.66.4 - Network setup: AWS VPC with routing peer, domain resources pointing to `*.corp.internal` internal DNS names ## Setup - Network with routing peer in AWS VPC - DNS nameserver configured for `corp.internal` → VPC DNS `172.31.0.2` - Domain resources (e.g., `db.corp.internal`, `node01.corp.internal`) - IP-based resource for DNS (`172.31.0.2/32`) works fine - Subnet resource (`172.31.0.0/16`) for another group works fine ## Reproduction 1. Create a Network with a routing peer 2. Add domain-type resources (e.g., `db.corp.internal`) 3. Create access policies granting a group access to these resources 4. Connect a client in that group 5. Run `netbird routes list` — domain resources show `Resolved IPs: -` permanently ## Debug log timeline ``` 11:29:09 - Routes assigned, routing peer "not available" yet 11:29:09 - DNS match domains registered as extra match domains 11:29:09 - Upstream probe to 172.31.0.2:53 fails (timeout - tunnel not ready) 11:29:09 - "Upstream resolving is Disabled for 30s" 11:29:12 - "upstreams 172.31.0.2:53 are responsive again" 11:29:13 - DNS queries fail: "NO_RECENT_HANDSHAKE no_handshake via_relay" 11:29:39 - "first wg handshake detected" — tunnel is now UP 11:29:39+ — NO domain resolution retry ever happens ``` After the WireGuard handshake completes at 11:29:39, the tunnel is fully operational. IP-based resources work. Manual `nslookup db.corp.internal 172.31.0.2` resolves correctly. But domain resources stay at `Resolved IPs: -` forever. ## Key log lines ``` INFO routemanager/client/client.go:237: network [db.corp.internal] has not been assigned a routing peer as no peers from the list [...] are currently available INFO routemanager/client/client.go:249: New chosen route is ... for network [db.corp.internal] DEBG dns/server.go:642: extra match domains: [files.corp.internal. node01.corp.internal. db.corp.internal. ...] WARN dns/upstream.go:292: probing upstream nameserver 172.31.0.2:53: with udp: read udp ...: i/o timeout WARN dns/upstream.go:386: Upstream resolving is Disabled for 30s INFO dns/upstream.go:364: upstreams 172.31.0.2:53 are responsive again ERRO dns/upstream.go:241: 1/1 upstreams failed for domain=db._dns-sd._udp.corp.internal.: 172.31.0.2:53=timeout after 4s (routes through NetBird peer routing-peer...:100.101.x.x NO_RECENT_HANDSHAKE no_handshake via_relay) INFO peer/wg_watcher.go:110: first wg handshake detected within: 0.00sec ``` ## Expected behavior After the WireGuard handshake completes successfully, domain resources should retry DNS resolution and populate `Resolved IPs` so that traffic can be routed. ## Workaround Using subnet-type resources (IP-based) instead of domain-type resources works correctly, as they don't depend on DNS resolution for route creation.
Author
Owner

@nuclon commented on GitHub (Apr 1, 2026):

Update: After further testing, domain resources DO eventually resolve for some domains, but not all. After several minutes of uptime:

  • 2 out of 8 domain resources resolved IPs (db.corp.internal and node05.corp.internal)
  • The other 6 remain at Resolved IPs: -
  • Once resolved, the resource works correctly (TCP connection to allowed port succeeds, ICMP correctly blocked by policy)

So the retry mechanism exists but appears to be unreliable — only some domains get retried successfully. The behavior is inconsistent across domains in the same network with the same routing peer.

<!-- gh-comment-id:4169592969 --> @nuclon commented on GitHub (Apr 1, 2026): **Update:** After further testing, domain resources DO eventually resolve for some domains, but not all. After several minutes of uptime: - 2 out of 8 domain resources resolved IPs (`db.corp.internal` and `node05.corp.internal`) - The other 6 remain at `Resolved IPs: -` - Once resolved, the resource works correctly (TCP connection to allowed port succeeds, ICMP correctly blocked by policy) So the retry mechanism exists but appears to be unreliable — only some domains get retried successfully. The behavior is inconsistent across domains in the same network with the same routing peer.
Author
Owner

@nuclon commented on GitHub (Apr 1, 2026):

Closing — domain resources do eventually resolve via the retry mechanism, though inconsistently. The core issue (initial resolution failing before WireGuard handshake) remains, but it's not a complete blocker. Will reopen if needed.

<!-- gh-comment-id:4169634534 --> @nuclon commented on GitHub (Apr 1, 2026): Closing — domain resources do eventually resolve via the retry mechanism, though inconsistently. The core issue (initial resolution failing before WireGuard handshake) remains, but it's not a complete blocker. Will reopen if needed.
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#11842