Summary
Recent macOS release observed intermittent system-wide DNS failures after sleep/wake on multiple devices running Global Secure Access (GSA) with NETransparentProxyProvider.
Previously successful DNS lookups time out after wake across applications, including browsers and GSA. Two captures contain failure-time evidence of the mDNSResponder resolver queue predominantly waiting in close()/kernel. Other captures show similar DNS failures, but a shared root cause has not been established.
Call chain, from thread entry to kernel wait:
start_wqthread + 8
_pthread_wqthread + 292
_dispatch_workloop_worker_thread + 720
_dispatch_root_queue_drain_deferred_wlh + 284
_dispatch_lane_invoke + 392
_dispatch_lane_serial_drain + 332
_dispatch_source_invoke + 920
_dispatch_source_cancel_callout + 208
_dispatch_continuation_pop + 596
_dispatch_client_callout + 16
close + 8
fleh_synchronous + 72
sleh_synchronous (sleh.c:1610)
unix_syscall (systemcalls.c:181)
fp_close_and_unlock_with_action (kern_descrip.c:1874)
fg_drop (kern_descrip.c:287)
soclose (uipc_socket.c:1345)
soclose_locked (uipc_socket.c:1138)
cfil_sock_close_wait (content_filter.c:5743)
soflow_db_apply (socket_flows.c; line unavailable)
cfil_filters_udp_attached_per_flow (content_filter.c:6675)
_sleep (kern_synch.c:213)
lck_mtx_sleep_deadline (locks.c:1583)
thread_block_reason (sched_prim.c:4060)
thread_invoke (sched_prim.c:3443)
Steps to reproduce
The issue is intermittent. These steps describe the observed sequence, not a deterministic minimal reproduction.
Run the GSA client using NETransparentProxyProvider. The affected configurations also have Microsoft Defender network extensions active.
Verify that a system DNS lookup succeeds for a known hostname.
Allow the Mac to sleep, including maintenance DarkWake cycles.
Wake the Mac and repeat system DNS lookups or use applications requiring hostname resolution.
Observe repeated approximately 30-second lookup timeouts, sometimes longer.
Observed results
November 5, 2026 - UTC+05:30 capture
User-reported impact: Recurrence of the same sleep/wake connectivity symptoms.
OS: macOS 27.2 (26B123).
Incident window: 20:38-20:41 IST / 15:08-15:11 UTC.
The same Chrome client/name A lookup succeeds earlier in 12.984 ms but times out after wake in 29,999.705 ms. The DNS service/server route changed, so this is not a controlled identical-network comparison.
The resolver records 1,007 timeout callbacks during the incident window, across browsers, Teams, GSA, Defender and other processes.
The failure-time spindump at 20:40:21.009-20:40:31.013 IST shows the original mDNSResponder PID 78534 with 715/715 resolver-queue samples under dispatch-source cancellation → close() → kernel → lck_mtx_sleep_deadline. Source: spindump.txt:75998-76093.
This establishes a sampled wait, not a permanent deadlock or proof of the same root cause as November 2. The file descriptor and kernel/filter wait owner remain unidentified.
A later matching Chrome lookup returns an address at 20:43:18.191816 IST on the same resolver PID, without a recorded resolver restart. This establishes some recovery, not that every application or tunnel recovered.
November 2, 2026 - UTC-08:00 capture
User-reported impact: No network upon wake. This eventually resolves without a reboot, after approximately 5 to 15 minutes of waiting.
OS: macOS 27.2 (26B123).
Incident window: 09:40-09:45 PST / 17:40-17:45 UTC.
The same Edge A lookup succeeds before sleep in 19.346 ms but times out after wake in 29,999.826 ms.
The resolver records 1,403 timeout callbacks during the incident window.
The failure-time spindump shows 770/777 resolver-queue samples under dispatch-source cancellation → close() → kernel; 769 include lck_mtx_sleep_deadline.
This establishes a dominant sampled wait, not a permanent deadlock. The file descriptor and kernel/filter wait owner remain unidentified.
November 3, 2026 - UTC-08:00 capture (Mihai)
Evidence: mihai_gsa_error.tar.gz
The following example records a failure resolving GSA’s own control-plane endpoint, whose DNS lookup is not intercepted by the GSA tunnel. Times in these excerpts are local (UTC-08:00).
GSA error
[2026-11-03 10:13:58.463]
Network connection to the Global Secure Access Edge could not be established
StreamId: ControlStream
Hostname: <tenant>.auth.client.globalsecureaccess.microsoft.com:443
Error: hostname lookup error: Address lookup failed
os_error: nodename nor servname provided, or not known
syscall: getaddrinfo
mDNSResponder records
10:13:19.663661
[R125367->DupQ50990->Q38408] Duplicate question <private> dn:04wpeA (Addr)
10:13:58.468519
[R125367] DNSServiceQueryRecord STOP -- name hash: dn:04wpeA, duration: 39s
10:13:59.078847
[R125340] QueryRecordOpCallback: Question <private> dn:04wpeA (Addr) timing out, InterfaceID 0x0
Additional observations
The original resolver records 11 timeout callbacks across GSA, Defender, Spotify and the system time service. A GSA A-query returns a positive result in 1.282 ms earlier (cache-compatible, not a cold upstream baseline), then the same client/name/qtype/flags times out after 41.865784 wall-clock seconds; that interval includes sleep. The DNS service/server set changes, so this is not a controlled same-network comparison.
At 09:40 PST the Wi-Fi interface becomes inactive and loses its IPv4 address, followed by no-dns-service results. The first native lookup errors precede this link loss; it does not explain the entire case.
Four GSA A/AAAA timeout transactions have matching late UDP replies. For one A-query, the reply is logged 25.095999 seconds after its matching send and 7.197434 seconds after the API timeout, during shutdown. 48 acceptable UDP response records appear within 1.467 ms. The location of the delay is not identified.
0
0
75