Where does website blocking happen? Reading DNS, SNI, and CDN controls

A warning.or.kr notice, a blank timeout, and an HTTP 451 can all feel like “the site is blocked.” They are not the same event. The layer that stopped the connection and whether the result follows the user across networks differ.

Collapsing those events into one label leads to the wrong diagnosis. An unusual DNS answer can be mislabelled as SNI filtering. A legal response returned by a CDN can be mistaken for an on-path interruption. The first task is to locate the decision layer.

One blocked page can originate at five control points

OONI separates IP blocking, DNS interference, HTTP blocking, and SNI filtering into distinct measurement categories.¹ An operations model should add the service endpoint, producing five useful layers.

A warning.or.kr notice does not by itself prove DNS blocking. A synthetic DNS answer and a plaintext HTTP Host or URL filter can both lead to the page, so DNS packets and the HTTP exchange must distinguish them.

DNS tampering also needs evidence. A response that differs from the authoritative data may come from resolver policy, on-path response injection, a stale cache, or a real authoritative change. Comparing resolvers and networks, then recording the TCP connection, TLS handshake, and final HTTP response, narrows the cause. NXDOMAIN or a timeout alone does not prove intentional blocking.

South Korea moved the observation point from DNS to SNI and CDN enforcement

The Korean Board of Audit and Inspection describes DNS-stage controls, URL filtering introduced in 2008, and SNI filtering introduced in 2019.² This is not a clean replacement history. As HTTPS hid plaintext URL paths, enforcement moved to other visible signals while older methods remained available for different cases.

SNI filtering changes precision. A plaintext HTTP filter can see a path such as /page/a; TLS SNI usually distinguishes only the hostname. Lawful and unlawful pages on the same host can therefore share the impact. The KT correction in 2019 shows how that wider unit and list operations can combine into over-application.

Control is also moving to the endpoint. If a CDN serves a response from a domestic cache or terminates TLS, it sees values that an on-path observer cannot. The endpoint mechanics and the reason ECH cannot remove CDN policy are covered in SNI, ECH, and CDN control points.

DoT, DoH, and ECH remove different plaintext clues

DNS over TLS (DoT) and DNS over HTTPS (DoH) encrypt DNS queries and responses between the client and a recursive resolver. DoT defines a dedicated TLS transport; DoH carries DNS over HTTPS.⁹¹⁰ Both make plaintext inspection or modification on the local path harder. The chosen resolver still receives the query and can apply response policy. DNSSEC authenticates DNS data; it does not conceal the queried name.

Encrypted Client Hello (ECH) encrypts ClientHelloInner, which contains the real SNI and other values such as ALPN. It became RFC 9849 in March 2026.¹¹ A real connection normally needs four conditions:

1. The client implements and enables ECH.
2. A DNS HTTPS record delivers a usable ECHConfig, unless the client is otherwise preconfigured.
3. The client obtains and uses that configuration.
4. The server or CDN accepts and decrypts ECH.

This combination changes the premise of an on-path classifier that relies only on plaintext DNS or SNI. In some networks, a filter can no longer reach the same decision from the same signal. Calling that a universal unblock feature would still be wrong. The destination IP, timing and volume, known encrypted-DNS endpoints, and CDN or application policy remain. In Iran, OONI observed SNI filtering after names were resolved over DoH, and separate interference with DoT and DoH endpoints.¹²

July 2026 support is about connection conditions, not a product badge

“This browser supports ECH” is incomplete. Version, release channel, enterprise policy, DNS mode, the destination HTTPS record, and CDN support can change the negotiated result. Where public product documentation does not confirm ECH, this table says so rather than treating missing documentation as proof of no support.

Tools likewise need a distinction between implementing a protocol and observing one.

The table works better as a verification plan than a shopping list. Record whether the HTTPS record exists, whether the client offered ECH, whether the endpoint accepted it, and what DNS and TLS behaviour follows a failure.

International cases show blocking and resistance moving up the stack

One pattern repeats across international cases. When one visible value is encrypted, filtering moves to another value or to a broader unit. Precision then falls and the chance of collateral damage rises.

“Circumvention” is not a permanent binary outcome in these cases. Packet variation or shared infrastructure may temporarily make classification harder, but filters can move to IPs, protocol fingerprints, or throttling. Broad controls then harm legitimate domains and infrastructure. The contest reallocates costs among visibility, precision, collateral damage, and platform policy.

Operators need an evidence bundle, not a screenshot

Availability and compliance work needs repeatable evidence rather than a single success or failure.

1. Compare DNS answers. Record answers, TTLs, and extended errors from local, approved encrypted, and authoritative DNS sources without labelling every difference an attack.
2. Record the stop point. Preserve TCP status, the server response after ClientHello, the certificate, and HTTP status in sequence.
3. Cross-check networks and devices. Compare carriers, corporate networks, mobile networks, and managed endpoints.
4. Separate decision makers and enforcement actors. Regulator deliberation, ISP implementation, and CDN Trust & Safety have different appeal paths.
5. Estimate shared-infrastructure blast radius. Identify legitimate services sharing the IP, edge, certificate, or platform policy.
6. Make encryption and fallback an explicit policy. Document whether DoH, DoT, or ECH falls back to plaintext, fails closed, or conflicts with a managed environment.

The best diagnostic question is not “Which sites open?” It is: who read which value, where did they make a decision, and what log proves it? That framing keeps privacy technology, enterprise security, legal enforcement, and ordinary outages from collapsing into one network symptom.

Cloud & infrastructure covers DNS, TLS, CDN, and fallback verification for production architectures. AX consulting connects regulatory requirements, availability, and operating procedures.

References

Support status was checked against public product documentation on 16 July 2026. Country implementations vary by operator and period; individual measurements are not presented as permanent country-wide behaviour.