What Is ISP Snooping? (DNS Logging)

ISP snooping is an ISP’s ability to observe network activity, including ordinary DNS requests. DNS logging means recording those requests, which can reveal domain names but not necessarily full pages or search terms. Encrypted DNS hides query contents in transit from your ISP, but shifts trust to the resolver and does not make browsing anonymous.

What if you use a privacy-focused DNS setting on your phone, but your router still sends ordinary DNS requests through your internet provider? Your device may appear protected while other devices, or a fallback path, continue to expose domain lookups.

I start a home-network review by tracing the path a DNS request takes: from the device, through the router and internet connection, to a resolver. That simple map helps separate what the ISP can see from what it cannot, and shows where to make changes.

What ISP snooping and DNS logging mean

DNS, or the Domain Name System, turns a domain name such as example.com into an IP address that a device can use. Ordinary DNS traffic is usually sent over UDP or TCP port 53. Under RFC 1035, this is the basic query-and-response system; it does not encrypt the query by itself.

If an unencrypted request crosses the ISP’s network, the ISP can generally read the requested domain name. The ISP may also keep logs, depending on its systems, policies, and legal obligations. That does not mean every ISP records every request, or that DNS alone reveals the exact page, form, or search term you used.

A DNS lookup is only one clue about online activity. The ISP may also see connection times, data volume, and the IP addresses your devices contact. Encryption on a website protects much of the content exchanged with that site, but it does not automatically hide the DNS lookup that came before the connection.

What can an ISP learn from DNS traffic?

A DNS query can reveal that a device asked for a domain, such as a news site or online store. It usually does not show the complete URL path, such as /account/settings, or the contents of an encrypted page. A site may also load content from several other domains, creating more lookups.

DNS records can be cached, so a device may not need to ask again for every visit. Also, a visible DNS request does not prove someone opened a page; an app or background service may have made the request. Treat DNS logs as useful indicators, not a complete record of browsing.

Planning: Identify the ISP’s DNS Visibility

Before changing settings, identify which device makes DNS requests, which resolver answers them, and how traffic leaves your home. The resolver may be supplied by your ISP, selected in your router, set on an individual device, or managed by a VPN. These choices determine what the ISP can read and whom you trust instead.

Start with a small network inventory. Note your router model, internet provider, operating systems, VPN use, and any custom DNS settings. Check whether the router hands out its own address as the DNS server; that can mean it forwards requests to an ISP resolver or another service.

Setup	What the ISP can generally see	Main privacy consideration
Ordinary DNS over port 53	Query names that cross its network without encryption	ISP or network operator may log queries
DoT to an outside resolver	Not the DNS contents in transit	Resolver can see queries; ISP sees its IP and connection metadata
DoH to an outside resolver	Not the DNS contents in transit	HTTPS can blend with other traffic, but does not hide the resolver from the ISP
DoQ to an outside resolver	Not the DNS contents in transit	Resolver still receives queries; default port is UDP 853
DNS through a VPN	Depends on whether DNS travels inside the VPN	VPN provider takes on visibility; check for leaks and fallback

These are general protocol behaviors, not guarantees about a particular provider’s logging. Review the resolver’s privacy policy, retention terms, and jurisdiction before selecting it. Encrypted transport protects a query on its way to that resolver; it does not prevent the resolver from seeing the query.

Access and Settings: Check Device, Router, VPN, and IPv6 Paths

DNS settings can exist at several levels, and one level can override another. A device may use its own encrypted resolver, while other devices follow the router. A VPN may also direct DNS through its tunnel, or may leave requests outside it. Check the real path instead of assuming one setting covers the whole home.

Trace the path before editing settings

On Windows, ipconfig /all shows network details, including DNS servers assigned to an adapter. On Linux systems using systemd-resolved, resolvectl status reports link and resolver information. On macOS, check the active network service’s DNS settings in System Settings. These commands and screens show configuration; they do not prove that upstream DNS is encrypted.

Also check IPv6. A device may send DNS over IPv6 even when you only changed IPv4 settings. Review the router’s IPv4 and IPv6 DNS options, plus the settings on devices that use their own resolver. Do not disable IPv6 as a shortcut unless you understand the effects on your network and services.

For a VPN, inspect its settings for DNS handling, leak protection, and behavior when the tunnel disconnects. A VPN can hide destination connections from the ISP while it is active, but it shifts trust to the VPN provider. Do not assume a VPN prevents DNS leaks: confirm that queries use the intended path and that ordinary port-53 traffic does not escape.

Execution: Enable Encrypted DNS

Encrypted DNS protects the query between your device and the selected resolver. DNS over TLS (DoT), defined by RFC 7858, uses TCP port 853 by default. DNS over HTTPS (DoH), defined by RFC 8484, carries DNS messages inside HTTPS, commonly over TCP port 443. The standard does not set one universal DoH URL path.

DNS over QUIC (DoQ), standardized in RFC 9250, uses UDP port 853 by default. Availability varies by device, router, and resolver. Choose a method supported by the equipment you use, and select a resolver whose policies you accept. Encryption changes who can inspect the query; it does not remove the need to trust a resolver.

A practical setup sequence is:

• Choose the resolver. Confirm its published DoT, DoH, or DoQ support and the exact configuration details it provides.
• Configure the device or router. Use the supported encrypted-DNS option. On some devices, this setting is called “Private DNS” and requires a provider hostname. In a browser, a DoH setting may protect browser lookups only, not all apps.
• Check VPN behavior. If you use a VPN, follow its DNS guidance and verify whether it handles both IPv4 and IPv6 requests.
• Review fallback settings. Look for options that allow ordinary DNS when the encrypted resolver is unavailable. A fallback can restore connectivity, but may expose queries over port 53.
• Apply changes carefully. Change one layer at a time, then check that browsing and other network services still work.

A router-level setting may cover many devices, but some clients can use their own resolver and bypass it. A device-level setting can protect that device while leaving the rest of the network unchanged. Note which layer you changed so you can test the same path later.

Verification: Confirm Encryption and Check for Leaks

Verification means checking the device and route you actually use, not merely seeing an “encrypted DNS” label in one menu. A resolver’s documented test can help confirm that its service sees your request. Packet inspection can show traffic patterns, but port numbers alone cannot prove that a connection is a particular encrypted DNS service.

First, test the intended device on the home network, with the VPN state you normally use. Then repeat with the VPN off or on only if you need to understand that separate route. A result from a browser-based test may apply only to that browser; it may not describe DNS from other apps or devices.

On a computer, tools such as nslookup example.com can confirm that name resolution works. They do not establish whether the request used DoH, DoT, or DoQ. A packet capture filter such as port 53 or port 853 can help find ordinary DNS and common DoT or DoQ traffic. It cannot identify DoH by port alone, because port 443 also carries ordinary HTTPS traffic.

Use the resolver’s own documented test or a trusted diagnostic that reports the resolver in use. Compare the result with the resolver you selected, and check again after reconnecting the VPN, changing networks, or restarting the router. There is no universal traffic-volume or timing threshold that proves a leak. The useful check is whether queries follow the intended encrypted route, and whether unexpected port-53 requests appear.

Illustrative home-network checks

In a typical troubleshooting scenario, a homeowner changes DNS on a laptop and sees the new resolver in its settings. A phone and smart television still use the router’s DNS address. The laptop’s setting does not cover those other devices, so each device or the router needs a separate check.

In another common scenario, encrypted DNS works until a VPN disconnects. The VPN’s DNS protection may stop with the tunnel, or the device may fall back to ordinary DNS. Testing both connected and disconnected states reveals whether that fallback matches the user’s needs. These examples describe diagnostic patterns, not claims about a specific ISP or product.

Conclusion and FAQ

The key is to trace DNS from each device to the resolver, then verify the route after changing settings. Ordinary DNS can expose query names to an ISP when it crosses the ISP’s network unencrypted. DoT, DoH, and DoQ encrypt DNS in transit to a chosen resolver, but they do not hide all metadata or make the resolver unable to see queries.

Does my ISP see every website I visit?
Not necessarily. It can generally read unencrypted DNS queries and may see connection metadata, but DNS alone does not show every page or action.

Can my ISP read DNS over HTTPS?
It generally cannot read the DNS message contents in transit when DoH is correctly used. It can still see connection metadata, including the resolver’s IP address.

Does encrypted DNS hide my browsing history from the resolver?
No. The selected resolver receives and can process the queries. Review its privacy and retention policies.

Is DoT better than DoH for privacy?
Neither automatically provides stronger privacy. Both encrypt DNS in transit; the resolver and its policies remain central to trust.

What port does DoT use?
DoT uses TCP port 853 by default under RFC 7858. A network or service may use other arrangements, so confirm its documentation.

What port does DoQ use?
DoQ uses UDP port 853 by default under RFC 9250.

Does DoH always use the same URL?
No. RFC 8484 does not prescribe one universal URL path. Use the endpoint information supplied by the resolver.

Does a VPN stop DNS leaks?
Not automatically. Check the VPN’s DNS routing, IPv6 behavior, and fallback settings, then test the route you use.

Does nslookup prove DNS is encrypted?
No. It can show that a lookup works, but not which transport carried it. Use device settings and a suitable resolver or network test.

Can a router’s encrypted DNS setting protect every device?
It can cover devices that use the router’s resolver. Some devices or apps may select their own DNS service, so test them separately.

(This article was written by one of our staff writers, Garrett Vance. Visit our Meet the Team page.)