As TLS privacy technologies remove network visibility, DNS becomes the earliest and most reliable enforcement point for threat prevention.
ECH removes TLS hostname visibility but does not affect DNS resolution. DNS therefore remains one of the earliest enforcement points available to network operators.
A common misconception is that TLS 1.3 encrypts all connection metadata. While TLS 1.3 encrypts certificates and application data, the initial ClientHello message remains visible to the network. This includes the Server Name Indication (SNI) field, which reveals the hostname a client is attempting to reach.
This behavior can be easily demonstrated with standard packet capture tools available on any Linux system.
The following command extracts both DNS queries and TLS SNI values from live traffic:
tshark -i any \ -Y "dns.qry.name or tls.handshake.extensions_server_name" \ -T fields \ -e frame.time \ -e dns.qry.name \ -e tls.handshake.extensions_server_name
This allows operators to directly observe how DNS resolution and TLS hostname disclosure correlate during normal browsing activity.
A simple curl request is sufficient to trigger a TLS handshake:
curl --tlsv1.3 https://www.planisys.net > /dev/null
A typical capture may look like:
10:41:22 www.planisys.net 10:41:22 www.planisys.net
The first line corresponds to the DNS query. The second line corresponds to the TLS ClientHello SNI field. This demonstrates that the requested hostname is visible twice in a normal connection workflow.
Even with TLS 1.3, the ClientHello remains visible. A simple packet capture demonstrates that the requested hostname is transmitted in cleartext unless ECH is enabled.
This visibility allows passive observers on shared networks such as public Wi-Fi environments to determine which domains users are accessing, even though the encrypted HTTPS content itself remains protected.
Historically, this visibility enabled network operators to perform:
ECH specifically targets this remaining metadata exposure by encrypting the ClientHello hostname while preserving TLS security guarantees.
In a typical public Wi-Fi environment such as a hotel, airport or café, a passive observer with packet capture capability does not need to break encryption to learn meaningful information about user activity. Because the TLS ClientHello and DNS queries remain visible, an observer can still extract valuable metadata.
Using standard tools such as tcpdump or tshark, an eavesdropper may be able to determine:
Even without access to encrypted content, this metadata can allow behavioral profiling. For example, repeated connections to specific services may reveal professional activity, technology usage patterns or organizational relationships.
This type of analysis is known as traffic metadata analysis and has historically been used both for network troubleshooting and security monitoring, but it also represents a privacy concern in untrusted network environments.
It is important to note that HTTPS and TLS 1.3 still protect the confidentiality and integrity of the session itself. A passive observer cannot see:
ECH therefore does not replace TLS encryption, but rather extends it by protecting the remaining hostname metadata exposed during the initial connection phase.
Beyond simple packet capture, large network operators such as ISPs, enterprises and cloud providers often use flow telemetry platforms based on NetFlow, IPFIX or sFlow to understand network behavior at scale. These systems do not inspect encrypted payloads but instead analyze connection metadata.
Even without decrypting traffic, operators can often combine multiple signals such as:
When correlated together, these signals can provide a fairly accurate understanding of the type of activity occurring on a network without requiring access to encrypted content.
In ISP environments this visibility has traditionally supported:
This type of monitoring is generally focused on infrastructure protection rather than user inspection, particularly in regulated telecommunications environments where operators are responsible for mitigating abuse originating from their networks.
As technologies such as TLS 1.3, QUIC and ECH progressively reduce the visibility of transport and session metadata, traditional network traffic inspection becomes less reliable as a primary security mechanism.
This architectural evolution is one of the reasons why many operators are moving toward earlier control points in the connection lifecycle, particularly DNS-based prevention and endpoint security, rather than relying on post-connection inspection.
From an operational standpoint, this reinforces the role of DNS as one of the earliest observable events in most Internet connections.
Over the past decade, Internet protocols have evolved toward encrypting not only data, but also metadata. For DNS operators and ISPs this represents a fundamental architectural shift.
Security detection historically relied on multiple visibility layers:
Modern protocol evolution is systematically removing these signals.
| Technology | What it hides |
|---|---|
| HTTPS | Application content |
| TLS 1.3 | Handshake metadata |
| DoH / DoT | DNS queries |
| QUIC | Transport patterns |
| ECH | Requested hostname |
The cumulative effect is clear: Network inspection is becoming unreliable as a security strategy.
Modern encryption technologies such as TLS 1.3, QUIC and ECH reduce network inspection capabilities. DNS remains one of the earliest enforcement points available to security operators.
Encrypted Client Hello (ECH) was introduced to address a legitimate privacy limitation in TLS. Even after the adoption of HTTPS, the Server Name Indication (SNI) field remained visible in plaintext, allowing passive observers to determine which websites users were visiting.
The IETF draft on deployment considerations provides an operational overview of this motivation:
ECH Deployment Considerations – IETF Draft
From a protocol design perspective, ECH represents a significant improvement in Internet privacy because it closes one of the last remaining metadata leaks in TLS connections.
ECH primarily protects users against environments where network traffic may be monitored by third parties. Examples include:
In these environments, preventing hostname visibility provides real privacy benefits. ECH significantly reduces the ability of passive observers to build browsing profiles based on TLS metadata.
The operational environment of ISP recursive DNS platforms is fundamentally different from these threat models. ISP DNS resolvers typically operate:
In this context, DNS filtering through RPZ is not designed for traffic inspection or user profiling. Its primary purpose is infrastructure protection and threat prevention.
In practice, large ISP recursive DNS platforms primarily use DNS security to:
These protections operate at the domain reputation level rather than through traffic inspection. ECH does not affect these capabilities because DNS enforcement occurs before TLS connections begin.
ECH provides the strongest benefits in environments where users cannot trust the network they are connected to. This includes:
In these situations, encrypting TLS metadata is clearly beneficial.
In ISP environments, the primary security concern is typically not passive observation of users, but active compromise of customer devices. Infected endpoints generate malicious DNS traffic regardless of TLS privacy protections.
Operational DNS telemetry across large recursive platforms consistently shows that malware relies heavily on domain infrastructure:
Blocking these domains prevents compromise regardless of whether TLS metadata is encrypted.
ECH should not be seen as conflicting with Protective DNS. They address different problems:
| Technology | Primary goal |
|---|---|
| ECH | Protect user privacy |
| Protective DNS | Prevent compromise |
Both approaches can coexist because they operate at different layers. ECH protects metadata confidentiality. Protective DNS prevents malicious infrastructure access.
ECH represents a continuation of the Internet trend toward stronger encryption. For DNS operators this reinforces an already clear direction:
Security must increasingly rely on intelligence-driven prevention rather than traffic inspection.
From an operational perspective, DNS remains one of the earliest and most scalable control points available for protecting large user populations.
ECH removes TLS hostname visibility which many operators used for:
This does not eliminate security — but it changes where security must happen.
Security enforcement must now move earlier in the connection lifecycle.
Regardless of encryption, attackers still require infrastructure:
This creates an operational reality: DNS remains one of the few enforcement layers that cannot be bypassed at scale.
DNS resolution → required TLS handshake → now encrypted Application traffic → encrypted
If a malicious domain is blocked at DNS, the connection never begins.
A common misunderstanding is that ECH reduces DNS security effectiveness. Operationally this is incorrect.
DNS filtering occurs before TLS.
DNS query → blocked No IP returned No TLS connection possible ECH irrelevant
Because DNS enforcement happens first, ECH does not affect:
ECH primarily affects operational workflows after DNS resolution:
For large ISPs this mainly impacts telemetry quality rather than prevention capability.
Large ISP recursive DNS platforms continuously observe malware activity from infected customer devices. Protective DNS often serves as the first containment mechanism.
Without DNS filtering, ISPs typically experience:
These operational realities explain why many ISPs deploy DNS security even when traffic inspection becomes ineffective.
ECH accelerates a broader industry transition:
Old model:
Inspect traffic → detect compromise
Emerging model:
Block infrastructure → prevent compromise
This shift favors DNS security because DNS operates before encryption begins.
As encryption removes inspection capability, organizations must rely more on prevention. DNS becomes one of the few scalable prevention layers available.
Protective DNS helps by:
Operators deploying Protective DNS commonly observe:
The long-term trend is clear: Security visibility will decrease. DNS prevention will increase in importance.
ECH reinforces an architectural direction already visible in modern networks:
DNS remains one of the few control points that scales across ISPs, enterprises and cloud environments.
ECH deployment requires coordination between web infrastructure, DNS publication and client support. Unlike traditional TLS features, ECH depends on DNS discovery through HTTPS resource records defined in RFC 9460.
ECH requires publication of an HTTPS (SVCB) DNS record containing the echconfig parameter.
example.com. 300 IN HTTPS 1 . alpn="h2,h3" echconfig="BASE64CONFIG"
If the HTTPS record is not present, clients automatically fall back to standard TLS without ECH.
ECH support is still evolving and currently depends heavily on browser implementation choices. In practice, ECH is most commonly enabled when browsers use encrypted DNS resolvers such as DNS over HTTPS.
This is not a protocol requirement, but an implementation decision intended to prevent DNS manipulation of ECH configuration data.
ECH encrypts the TLS hostname after DNS resolution. Because DNS queries occur before the TLS 1.3 handshake begins, DNS security controls such as RPZ filtering remain effective prevention points.
If any requirement is missing — DNS record, browser support or server capability — the connection proceeds normally without ECH.
Because ECH deployment is still evolving, the easiest way to observe it is by using domains that already support it. Cloudflare operates one of the largest public ECH deployments, making it ideal for testing. This simple lab requires only dig and Firefox.
Query the HTTPS record:
dig crypto.cloudflare.com HTTPSExample output:
crypto.cloudflare.com. 300 IN HTTPS 1 . alpn="h2,h3" echconfig="AEj+DQBB..."
If the echconfig parameter is present, the domain supports ECH.
kdig crypto.cloudflare.com HTTPSThis sometimes shows the structure more clearly than dig.
Open:
about:configVerify these settings:
network.dns.echconfig.enabled → true network.trr.mode → 3 network.trr.uri → https://mozilla.cloudflare-dns.com/dns-queryExplanation:
https://crypto.cloudflare.com/cdn-cgi/traceLook for:
sni=encryptedIf present, ECH is active.
network.trr.mode → 0Reload the page. ECH may now disappear depending on resolver behavior. This demonstrates how current browser implementations often tie ECH activation to encrypted DNS usage.
dig example.com HTTPSResult:
(no HTTPS record)ECH cannot activate without this record.
ECH support on the server side is still emerging because it requires deep integration in the TLS stack rather than simple web server configuration. Unlike HTTP features that can be enabled through reverse proxy configuration, ECH operates inside the TLS handshake and therefore depends on cryptographic libraries such as OpenSSL, BoringSSL or NSS.
This means that even if a web server supports TLS 1.3, it cannot automatically support ECH unless the underlying TLS implementation also supports it.
| Software | ECH support status | Notes |
|---|---|---|
| NGINX | Early support emerging | Requires experimental OpenSSL ECH branch or upcoming OpenSSL 4.0 |
| Apache | Experimental work | Dependent on TLS library support |
| HAProxy | Early implementation work | Still evolving |
| Caddy | Experimental ecosystem support | Depends on Go TLS developments |
| CDN platforms | Most mature deployments | Cloud providers currently lead adoption |
The main limiting factor for ECH deployment today is TLS library support. Historically, most web servers depend on OpenSSL, which only recently began adding ECH capabilities in development branches and future major releases.
Because of this dependency, many real-world deployments currently occur at large CDN providers that maintain their own TLS stacks based on BoringSSL or similar implementations.
Today, most ECH-enabled connections are terminated at large edge platforms rather than origin servers. This reflects the operational complexity of maintaining TLS infrastructure capable of supporting ECH key rotation, DNS publication and fallback handling.
As TLS libraries mature and ECH support becomes part of mainstream OpenSSL releases, broader adoption in self-hosted environments is expected.
For now, operators evaluating ECH should consider it an emerging capability rather than a universally available feature.
Even with ECH enabled, DNS resolution remains the first required step before any encrypted TLS connection can occur.
No. DNS filtering continues working because it occurs before TLS connections begin.
Yes. As traffic inspection decreases, DNS becomes one of the earliest prevention points.
ECH improves privacy but requires ISPs to rely more on DNS intelligence instead of traffic inspection.