Given the symptoms and the tests already done, this should be treated as a Wi‑Fi connectivity problem on the Windows client first, not as a DNS-only problem.
The strongest signal is the occasional packet loss and latency spikes to the local gateway. The guidance for Windows wireless troubleshooting is:
- Classify the scenario correctly This fits connection drops or unreliable roaming, and possibly issue started after an update or resume if the timing matches any recent change. For that scenario, collect the disconnect time, network name, access point, signal conditions, and correlate the client trace with access point or controller logs.
- Collect baseline evidence before changing anything else
Since resets, driver changes, and IPv6 changes were already tried, avoid more disruptive changes until evidence is captured. Run these from an elevated Command Prompt:
Also collect:netsh wlan show drivers netsh wlan show interfaces netsh wlan show networks mode=bssid netsh wlan show profiles netsh wlan show wlanreport- exact date and time of each failure
- adapter model, driver version, and driver date
- Windows build and recent update history
- WLAN AutoConfig Operational log in Event Viewer
mode=bssidis useful here because it shows BSSID, signal strength, channel, and radio type, which helps identify band, channel, or coverage issues. - Check the basics that specifically match this symptom
For cases where Wi‑Fi drops while other devices stay online, confirm:
- the adapter is present and enabled
- WLAN AutoConfig (WlanSvc) is running
- whether the issue started after an OS, driver, firmware, BIOS, sleep, or resume change
- whether other clients can see and use the same network normally
- Capture an ETW trace during a failure
For an intermittent issue like this, capture a trace while reproducing the problem:
Reproduce the issue and record the time, then stop the trace:if not exist c:\tmp md c:\tmp netsh trace start wireless_dbg capture=yes overwrite=yes maxsize=4096 tracefile=c:\tmp\wireless.etl
If needed, convert it:netsh trace stop
This createsnetsh trace convert c:\tmp\wireless.etlwireless.cab,wireless.etl, and optionallywireless.txt. - Interpret what the trace is likely to prove If the trace shows disassociation or port-down behavior, the Windows guidance is to determine where the connection state fails and trace backward from the last known good state. If a disassociation reason appears from the access point, decode that reason before changing client settings, because the reason code comes from the AP and should be correlated with AP or controller logs.
- Check for known issues and recent changes
Before more resets or driver removal, review:
- Windows release health for the installed Windows version
- the motherboard or adapter manufacturer’s support information for wireless driver, firmware, and BIOS updates or known compatibility issues
- Avoid premature destructive steps Do not reset the network stack again, delete wireless profiles, remove the adapter/driver, or restart before collecting baseline state and reproduction time. Those actions can remove evidence or temporarily change behavior.
Based on the supported guidance, the current evidence points more toward a wireless link/adapter/driver/infrastructure path issue than a pure DNS problem, because loss to the local gateway indicates the problem can occur below DNS. The next useful step is not another generic reset; it is collecting wlanreport, WLAN AutoConfig logs, and an ETW trace at the moment of failure, then checking whether the adapter is being disassociated, going port-down, or hitting a driver/power/resume-related transition.
If the issue began after a recent update or resume behavior change, compare the current driver and firmware versions with the versions recommended by the device or adapter manufacturer before making further changes.