Hello all,
I can confirm that the last Norton release version 26.8.1125 actually does block DNS traffic!! I have the full technical details below.
Firstly, I’d like to send sincere THANKS to 2 places: 
-
I greatly THANK @CCNunes for their post! After many hours of troubleshooting, your post was found. Your symptoms were similar to mine, and therefore it helped give certainty to what I had found.
-
I also must thank Claude (Opus)! 
I would never have been able to precisely pinpoint the technical details without its help.
For easy reading, here is a “Table of Contents” of my post:
Section 1: high-level Summary.
Section 2: my system environment
Section 3: For Users - who want to diagnose, identify, and resolve the problem**.**
Section 4: For NORTON TECH SUPPORT - full technical details.
Section 1: Summary
Issue: Loss of internet connectivity (Web Browsing). Complete DNS resolution failure (all name lookups fail/time out).
It didn’t work via Ethernet or Wi-Fi.
However - pings, TCP handshakes, and general network connectivity to IP addresses work fine.
Start date: August 28, 2026 — the day after installing a Windows cumulative update (KB5099539). At first this looked like it might be Windows-update-related, but that was a red herring (see below).
The start date of my issue is possibly many days after the new Norton version was actually pushed out, because I normally only hibernate my PC each night. The reboot I did on Aug 28th likely installed it.
Resolution: Uninstalling Norton 360 fixed it immediately and permanently. Root cause was traced to Norton’s WFP (Windows Filtering Platform) callout drivers silently “hanging” on outbound DNS queries – never blocking them, never allowing them, just never responding.
This is why no firewall log, IPS log, or blocked-connection entry ever showed anything: the query was stuck, not denied.
I have not tried reinstalling Norton and do not not plan to until a newer (and possibly fixed) version is released.
I’ll be using the native Windows Security (Defender/Firewall) in the meantime.
Key finding for other users: If your Norton update landed around the same time as a Windows update and DNS suddenly breaks, don’t assume the Windows update is the cause. In my case, file timestamps showed Norton had actually downloaded/staged its own update about 2 weeks earlier. It just happened to finish installing during the reboot from the unrelated Windows update, making two independent events look like one coincidence. Thank you Claude (Opus)!!
Section 2: My System Environment
· Computer: Dell XPS 8910 (desktop)
· OS: Windows 10 Pro x64, version 22H2, build 19045.7548 (KB5099539)
· Norton 360 version: 26.8.11125
· Ethernet adapter: Qualcomm Atheros AR8171/8175
· Wi-Fi adapter: Intel Dual Band Wireless-AC 3165 (not in use)
· CPU: Intel 6th-generation (“Skylake”)
I normally only use the Ethernet connection with my PC and not Wi-Fi.
I have 2 other devices on the same network using Wi-Fi – and they were not affected by this issue.
Section 3: For Users who want to diagnose, identify, and resolve the problem.
Here’s the sequence of steps that confirmed it on my system:
**1. Confirm the symptom pattern**
Open a Powershell window:
ping 8.8.8.8
nslookup google .com 8.8.8.8
If ping succeeds but nslookup fails or hangs, this matches the problem pattern.
**2. Confirm it’s above the connection layer**
In the same Powershell window:
Test-NetConnection 8.8.8.8 -Port 53
If `TcpTestSucceeded: True`, the connection itself is fine – the problem is something is intercepting the DNS query specifically, not a blocked port.
**3. Rule out Norton’s visible controls**
In the Norton app , temporarily toggle off Norton Smart Firewall, then Norton Intrusion Prevention.
Re-test the nslookup google .com 8.8.8.8 after each.
Turn both items back on again.
In my case, even with both toggled off the failures still occurred. But this was expected, since the real cause operates at a lower level that these switches don’t touch.
If desired, you can also check Norton’s Intrusion Prevention “Connection Attempts” log.
If it’s empty despite ongoing failures, that’s consistent with this issue – because nothing is being actively blocked or logged.
**4. The decisive test–> Safe Mode with Networking**
Boot into Safe Mode with Networking and run the same nslookup google .com 8.8.8.8 again.
If it succeeds in Safe Mode, that isolates the cause to a service which only runs when Windows is in full normal-mode. In my case, it was Norton.
**5. Try Norton’s Repair tool (Optional)**
I wanted to give this a try before uninstalling it.
In the Norton app-> Settings → Troubleshooting → Repair Norton.
This came back clean for me (aka no problems found). However that does not rule out Norton being the issue – since the Repair only checks installation integrity, and not runtime behavior.
**6. Remove Norton**
Use the Norton Remove and Reinstall tool. Choose the removal option only.
Reboot.
If, like me, you also have Windows Security (Defender Antivirus and Firewall) still installed, it will automatically become active.
But you should go look at each section to verify. And activate any that didn’t turn on.
**7. Retest DNS connectivity**
nslookup google .com 8.8.8.8
DNS resolution should work now.
Section 4: Technical Details for Norton Support
**Affected build:** Norton 360, version 26.8.11125
**Symptom:** Complete outbound DNS resolution failure. All other network activity (ICMP, TCP handshakes to arbitrary ports, non-DNS traffic) functioned normally. No firewall block entries, no IPS log entries, and no Norton Connection Attempts log entries were generated during the failure window. The absence of any log entry was itself a key diagnostic signal, not just background noise.
**Root cause (as best determined from the client side):** Norton’s Windows Filtering Platform (WFP) callout drivers — registered under the provider tag `NLOK` — appear to register callouts at, among other layers:
- `FWPM_LAYER_ALE_AUTH_CONNECT_V4` / `V6` (connection authorization)
- `FWPM_LAYER_OUTBOUND_TRANSPORT_V4` / `V6` (outbound packet send)
In this build, these callouts did not return a timely classification for outbound DNS queries. For UDP-based DNS, the connection-authorization step for the query itself never completed, so no packet was ever handed to the network stack. This explains why the query never appeared in a firewall log, IPS log, or packet capture as “blocked” – it was never sent. For DNS-over-TCP attempts, the TCP handshake completed normally (passing through a different, correctly-functioning Norton-owned layer), but the subsequent query send at the outbound transport layer hung in the same way.
The behavior is consistent with a callout **pending** a classification indefinitely rather than explicitly permitting or denying it. Its a failure mode that is externally indistinguishable from “nothing happening”. And it’s invisible to any firewall/IPS toggle, since those toggles govern policy evaluated *by* the callout, not whether the callout responds at all.
**Diagnostic method / evidence trail, with exact commands used:**
**1. Rule out a simple port block:**
In powershell:
Test-NetConnection 8.8.8.8 -Port 53
Returned `TcpTestSucceeded: True`, ruling out a simple port block and confirming the fault was above the connection layer.
**2. Safe Mode with Networking A/B test:**
Boot into Safe Mode with Networking, then run:
nslookup google .com 8.8.8.8
This succeeded in Safe Mode (Norton services not running) and failed identically in normal mode, isolating the cause to a normal-mode-only component.
**3. Packet-level capture:**
pktmon filter remove
pktmon filter add DNS -p 53
pktmon start --capture --pkt-size 0 -f C:\dns.etl
Run the failing `nslookup` command in another window, let it fully time out, then:
pktmon stop
pktmon format C:\dns.etl -o C:\dns.txt
Searching `dns.txt` for the target DNS server IP and for `UDP` returned **no occurrence of either** — confirming the query never reached the NDIS layer as a packet.
I then ran:
pktmon list -a
and checked the Filter Drivers section for both adapters. All listed filter drivers were Microsoft-signed (`wfplwfs.sys`, `pacer.sys`, native Wi-Fi/vWiFi filters), ruling out a third-party NDIS filter driver as the point of failure and pointing to something above NDIS — i.e., WFP.
**4. WFP state dump:**
netsh wfp show state
This produces a large XML file (`wfpstate.xml` by default).
Searched it for the provider tag **`NLOK`** rather than Norton’s provider GUID directly.
`NLOK` returned 30 hits across 14 distinct callouts, versus 1,240+ hits when searching the GUID directly (which matches every filter merely *referencing* the provider, not the provider’s own registered callouts).
The `NLOK`-tagged callouts present at `FWPM_LAYER_ALE_AUTH_CONNECT_V4/V6` and `FWPM_LAYER_OUTBOUND_TRANSPORT_V4/V6` are the direct evidence pointing to Norton’s own driver code at exactly the two layers where an outbound DNS query is authorized and sent.
**5. Norton Repair:**
Settings → Troubleshooting → **Repair Norton**. Returned a clean “no problems found” result — expected, since this checks installation integrity rather than runtime callout behavior, and does not rule out this class of defect.
**Resolution:** Full uninstall via the Norton Remove and Reinstall tool (no reinstall) resolved the issue immediately. Microsoft Defender Antivirus and Firewall re-registered as active automatically once Norton was no longer the registered security provider. DNS resolution and general connectivity were confirmed restored post-removal and remained stable.
Note on apparent timing coincidence: The DNS failure was first observed the day after installing an unrelated Windows cumulative update (KB5099539), which initially suggested a Windows-side cause.
Norton’s own Security → History → Software Updater log showed the responsible update had been downloaded and staged approximately 15 days prior to the failure. Directory timestamps on C:\Program Files\Norton, by contrast, showed the update files were actually written during the reboot cycle for the Windows update (~10:28 PM, August 27) — corroborating that the staged update completed installation at that later restart, not at the time it was originally downloaded.
I hibernate rather than shutdown-reboot on a daily basis, so a staged update from any vendor can sit pending until a genuine restart occurs. This is flagged specifically because it could mislead engineering triage toward a Windows-update interaction that isn’t actually present here. The two events are independently timed and coincidentally concurrent, not causally linked.
-The End-