What you see
Single-label queries now pick up configured DNS search domains, so a bare hostname can turn into a search-list lookup instead of a straight failure. That is useful on paper and annoying in practice when a name resolves one minute and not the next because the suffix list changed under the client.
DNSSEC handling also changed. The local DNS proxy now forwards DNSSEC-signed responses intact, including DO and AD bits and RRSIG records. If a resolver path or filtering layer used to strip that data, the client will stop quietly papering over it.
Where it happens
The breakage shows up most clearly in tunnel-only mode after a custom DNS server changes on the primary adapter while the client stays connected. Name lookups can fail even though the connection itself still looks alive. That points to DNS resolution state inside the client, not a dead tunnel.
The other place to watch is the boundary between plain DNS and Secure Web Gateway filtering. If DNS filtering is not in tunnel-only mode, do not treat every failed lookup as the same fault. A filtered response, a search suffix miss, and a dead upstream resolver produce very different logs and very similar user complaints.
Find the cause
The local DNS proxy is the part touching the response, so test there first. If DNSSEC records now reach the application intact, the client is no longer normalising them on the way out. That means a failure that appears after the beta change is more likely to sit in client handling, profile settings, or adapter state than in the resolver upstream.
Check the active WARP device profile and the DNS search suffix settings tied to it. A suffix list that looks harmless can change which name gets queried, which resolver path gets used, and whether a single-label query ever becomes a valid lookup at all. If the profile scope is wrong, users can end up resolving the wrong thing for a long time before anyone notices.
Fix
Reconnect cleanly after changing adapter DNS settings. A disconnected and reconnected client is dull, but dull is what you want when the DNS state machine has got itself tied in knots.
Use the client UI and warp-cli only where the current build still allows it. The beta has also moved some management around, including split tunnel control through warp-cli tunnel ip and warp-cli tunnel host, so do not assume the new Windows UI exposes every setting you remember from the old one.
Check it’s fixed
Run dig or drill before trusting the result. Check that the response still carries the DNSSEC flags and records you expect, then test both a normal hostname and a single-label query with the configured suffixes in place.
If tunnel-only mode fails again after a primary adapter DNS change, treat that as a client-side regression and not a generic DNS outage. The resolver may be fine. The client is usually the awkward bit.
