Press play to start listening
When a website block works, the request has been stopped at a particular point. The domain may never resolve to an IP address, the connection may be rejected before leaving the device, or endpoint software may prevent the browser or application from reaching the destination.
Each method works with different information. DNS filters inspect domain queries, basic firewall rules inspect network addresses and ports, TLS filters may read hostnames during connection setup, and endpoint tools can use information about the application making the request.
Understanding those differences explains why a website may remain accessible even when a filtering service reports that its rules are active.
Blocking Through the Hosts File and DNS
The earliest decision can happen on the device itself. Before contacting a DNS resolver, an operating system may check its local hosts file. On Linux and other Unix-like systems, this is usually /etc/hosts. Windows uses %SystemRoot%\System32\drivers\etc\hosts.
An entry can redirect a domain to a loopback or unusable address, preventing the system from reaching its normal destination. The method is simple and does not require a separate filtering service.
Its coverage is limited because entries apply to specific hostnames. Blocking only the main domain may leave subdomains, API endpoints, media hosts or alternate entry points reachable unless each one is added separately. Anyone with sufficient permissions can also remove or edit the rules.
DNS filtering applies a similar decision at the resolver. When a device requests a blocked domain, the resolver may return NXDOMAIN, 0.0.0.0, a sinkhole address or another policy response.
A local service such as Pi-hole can apply these rules inside a home or office network, while hosted filtering resolvers can apply maintained blocklists to devices configured to use them. DNS filtering can also provide records showing which domains were requested and blocked.
Both methods depend on receiving a domain query. They do not inspect what an application does after receiving an address, and they cannot block a connection made directly to an IP address based on the missing hostname alone.
How Encrypted DNS Bypasses Local Filtering
Traditional DNS commonly uses plaintext traffic on port 53, allowing a network administrator or local filtering service to see where queries are being sent.
DNS over HTTPS, known as DoH, sends those queries through an encrypted HTTPS connection on port 443. DNS over TLS also encrypts queries but commonly uses the dedicated port 853.
When an application sends its DNS queries directly to an external resolver, the local filtering resolver is bypassed and records no request. Its dashboard may still show that the service is running normally, even though the application used another route for name resolution.
Firefox has enabled DoH by default for many users in the United States since 2020. Chrome can also use secure DNS when the selected resolver supports it, subject to browser settings and administrative policies.
Managed devices can have encrypted DNS settings controlled through enterprise policies. Networks may also block known DoH endpoints, although this requires regular maintenance and can block unrelated services when resolvers use shared hosting or content-delivery infrastructure.
Firefox supports a canary domain that can tell the browser not to activate DoH on a particular network. This behaviour depends on the browser cooperating with the network policy and is not a universal control for every application.
Blocking Connections With Firewalls
Filtering can also take place after a domain has resolved. Linux provides netfilter through tools such as iptables and nftables, while Windows offers the Windows Filtering Platform. Apple devices support filtering through the Network Extension framework. Some consumer applications create a local VPN interface and inspect connections passing through it.
A basic packet filter usually works with source and destination IP addresses, ports and protocols. This is useful when blocking a fixed service, a known malicious host or traffic using a particular port.
Website filtering is harder because one IP address can serve many unrelated domains through shared hosting and content-delivery networks. Blocking that address may affect several services, while allowing it may leave the intended destination reachable. Provider address ranges can also change.
More advanced operating-system frameworks can associate network activity with the application or user responsible for it. Windows Filtering Platform, for example, can apply rules using application identity at its Application Layer Enforcement layers. Apple’s Network Extension framework can provide application and content information depending on the filtering method used.
Kernel or operating-system filtering therefore covers several implementations. It should not be treated as synonymous with simple IP-address blocking.
Filtering Through TLS Metadata
A filtering product may also inspect information exposed while an encrypted connection is being established.
During a standard TLS handshake, the Server Name Indication field can reveal the hostname a client wants to reach. A filter can use this information to stop a connection without decrypting the content exchanged between the user and the website.
SNI inspection provides greater precision than blocking an IP address because the filter can identify a hostname hosted on shared infrastructure. It also avoids the certificate installation and traffic interception required for full TLS inspection.
Encrypted ClientHello, or ECH, limits this visibility by encrypting the sensitive part of the TLS handshake. When ECH is successfully negotiated, the network may see an outer hostname associated with shared infrastructure but not the inner hostname requested by the user.
SNI-based filtering will continue to work where the hostname remains exposed. Its coverage decreases for connections that successfully use ECH, so it cannot be treated as a complete record of every destination reached from a network.
Blocking Websites and Applications on the Device
Endpoint software can apply rules using information available on the device, including application launches, process identity, DNS activity and network connections. Its visibility depends on how the software integrates with the operating system.
A browser extension may see complete URLs, while an operating-system filter may associate a connection with the program that opened it. A process blocker can stop an application from starting without inspecting its network traffic.
Because the policy runs on the endpoint, it can remain active when a laptop moves between home, office and public networks. It may also cover desktop applications that do not use a conventional browser.
Endpoint software does not automatically see destinations before encryption or interpret traffic from every application. Those abilities depend on the operating-system interfaces, permissions and filtering methods used by the product.
According to DigitalZen, its desktop software can block websites and applications and restrict attempts to stop the enforcing process while a rule is active. These product claims were not independently tested for this article.
Installing privileged software gives that product significant control over the device. Organizations and individual users should review its permissions, update process, data handling and removal controls before deployment.
Why Website Filters Still Miss Traffic
No single filtering method sees every request in the same form. A DNS filter only evaluates queries sent to its resolver. A basic firewall works mainly with addresses and ports. An SNI filter can identify a hostname only when it remains visible in the TLS handshake. Endpoint products may add application or URL information, depending on how they are built.
A filtering dashboard therefore describes the activity visible to that product, not every action performed by the device.
When a website remains accessible despite an active block, the investigation should identify which application opened the connection, which resolver it used, whether it connected directly to an IP address, which protocol carried the traffic and whether the device had moved outside the network where the policy was applied.
Effective blocking depends less on finding one universal layer and more on matching the control to the traffic and devices it is expected to manage.
(Disclosure: This article was published in collaboration with DigitalZen)
