DNS Filtering vs Proxy-Based URL Filtering: What Actually Happens at the HTTP Layer

Most articles about web filtering treat DNS filtering and URL filtering as interchangeable names for the same thing. They are not. They operate at different layers of the network stack, have different security properties, and fail in different ways. If you are responsible for a network and you need to enforce web access policies, understanding the distinction matters — particularly around HTTPS traffic, where the commonly held assumptions are frequently wrong.

Let's dig into what's actually happening at the protocol level.

DNS filtering: fast, but operating on the wrong layer

DNS filtering intercepts DNS resolution queries. When a client resolves malicious-site.com, the filter sees the query, checks its blocklist, and either returns NXDOMAIN or redirects to a block page instead of the real A record.

The implementation is simple and the performance overhead is minimal. But it has two architectural weaknesses that matter in practice.

Weakness 1: Domain-level granularity only

DNS filtering operates on hostnames, not URLs. You can block youtube.com entirely, or allow it entirely. You cannot allow youtube.com/watch?v=educational_content while blocking youtube.com/gaming. Any policy requiring path-level or parameter-level control is beyond what DNS filtering can enforce.

Weakness 2: Trivially bypassed via /etc/hosts

The /etc/hosts file maps hostnames to IP addresses locally, before any DNS resolution happens. A user who adds:

93.184.216.34   malicious-site.com

to their hosts file will reach that IP directly, with no DNS query issued. Your DNS filter never sees the request.

Note: hosts file modification requires administrator/root privileges on most systems. In a properly managed fleet with enforced least-privilege, this risk is reduced — but not eliminated.

Proxy-based URL filtering: operating at the right layer

URL filtering via a web proxy intercepts traffic at the HTTP application layer. The proxy sits between clients and the internet, sees the full URL — scheme, host, path, query string — and applies policy before forwarding.

Because the interception happens at the application layer rather than the DNS layer, /etc/hosts bypasses do not work. Policy enforcement happens where the traffic actually flows, not at an advisory step that can be circumvented upstream.

The HTTPS question: how does URL filtering work on encrypted traffic?

This is where most explanations go wrong. The common assumption: "HTTPS is encrypted end-to-end, so a proxy can't see the URL — you need SSL inspection to filter HTTPS." This is partially correct and missing a crucial detail.

In explicit proxy mode, HTTPS filtering works via the HTTP CONNECT method — and the proxy sees the full URL before any encryption is established.

The HTTP CONNECT handshake, step by step

When a browser configured to use an explicit proxy wants to open an HTTPS connection, it opens a TCP connection to the proxy and sends:

CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com:443
Proxy-Authorization: Basic dXNlcjpwYXNz

The proxy receives this CONNECT request in plain text, before any TLS handshake. It sees the target hostname, port, and authenticated user identity.

A common misconception: the proxy does not only see the hostname. Modern browsers include the full Request-URI in the CONNECT request, meaning the proxy can see the path and query string — enabling path-level URL filtering on HTTPS without decrypting a single byte of application data.

If the proxy allows the connection:

HTTP/1.1 200 Connection established

It then acts as a TCP tunnel. The TLS handshake happens between client and upstream server. The proxy never decrypts application data.

If the proxy blocks the connection:

HTTP/1.1 403 Forbidden
Content-Type: text/html

[block page content]

No TLS handshake happens. No SSL inspection required.

So what does SSL inspection actually add?

SSL inspection — where the proxy performs a TLS MITM using its own CA certificate — serves a different purpose: scanning the content of encrypted traffic for malware, detecting data exfiltration, and applying WAF rules to HTTPS request bodies.

URL filtering and SSL inspection are orthogonal features:

• URL filtering → controls where users can go. Works on HTTPS via CONNECT without decrypting content.
• SSL inspection → controls what content passes through. Requires decrypting the TLS session.

You can run URL filtering on HTTPS without SSL inspection. They are independent controls that can be combined.

Explicit proxy vs transparent proxy: the mode matters

The CONNECT method only works in explicit proxy mode, where client devices are configured (manually, via WPAD, or PAC file) to route traffic through the proxy.

In transparent proxy mode, the proxy intercepts at the network layer via iptables REDIRECT or TPROXY rules without client configuration. For HTTPS in transparent mode, the proxy only sees the TCP destination IP and SNI — not the full URL path — unless SSL inspection is enabled.

Practical implementation with Squid

The most widely deployed open-source proxy engine for URL filtering is Squid. In explicit proxy mode it handles the CONNECT method natively and applies ACL-based rules against the full URL.

# Block a URL category list
acl blocked_urls url_regex -i "/etc/squid/blocked_urls.txt"
http_access deny blocked_urls
http_access allow all

For CONNECT requests (HTTPS), Squid applies ACLs against the target before tunnelling:

acl blocked_ssl_hosts ssl::server_name_regex -i blocked-domain\.com
http_access deny CONNECT blocked_ssl_hosts

CacheGuard is a free, open-source network security appliance that ships Squid as its URL filtering engine — pre-integrated with the firewall, gateway antivirus, SSL inspection, WAF, and QoS stack. It supports both proxy modes, LDAP/AD group-based policies, and time-of-day rules without manual component wiring.

→ https://www.cacheguard.com/url-filtering/

Summary

• DNS filtering is fast but domain-only and bypassable via /etc/hosts.
• Proxy-based URL filtering operates at the HTTP layer, is bypass-resistant, and supports path/parameter-level policies.
• In explicit proxy mode, HTTP CONNECT gives the proxy full URL visibility on HTTPS without SSL decryption.
• SSL inspection is a separate, orthogonal capability for content scanning — not a prerequisite for HTTPS URL filtering.
• Transparent mode limits HTTPS filtering to hostname/SNI unless SSL inspection is enabled.

Originally published on the CacheGuard Blog. CacheGuard is a free, open-source UTM appliance — full source on GitHub.