Encrypted DNS and what parents see

DNS-over-HTTPS, DNS-over-TLS, and Encrypted ClientHello do not break parental controls on their own. They shrink what a home router can see.

A family router used to read the domain name on every lookup. Modern devices wrap DNS in HTTPS, and they hide the hostname in the TLS handshake. A router-side filter that classifies by hostname sees less and less of the traffic [source: rfc9490-mten].

This page explains what each of the three protocols does, what the router still sees, and where the rule must live instead [source: www-rfc8484-doh].

Why this matters

DNS-over-HTTPS (DoH) moved DNS into HTTPS. DNS-over-TLS (DoT) does the same over a dedicated TLS port. Encrypted ClientHello (ECH) removes the hostname from the visible part of the TLS handshake.

The router’s view of each request changes:

• Before: the router reads the domain name and decides.
• After DoH: the router reads only the encrypted stream to a DoH endpoint.
• After ECH: the router reads only the encrypted stream to a server, with no hostname visible at all [source: www-rfc9849-ech].

The filter did not move. The signal it depends on did.

Definition

DNS-over-HTTPS is the protocol that maps DNS queries and responses into HTTP exchanges inside an HTTPS connection [source: www-rfc8484-doh].

DNS-over-TLS is the protocol that runs DNS over a TLS connection on a dedicated port, separate from HTTPS [source: www-rfc9076-dns-privacy].

Encrypted ClientHello is the TLS extension that encrypts the ClientHello, including the Server Name Indication (SNI) [source: www-rfc9849-ech].

The three together are sometimes called “encrypted client signalling”: the parts of a connection that used to identify the destination no longer identify it in the clear [source: rfc9490-mten].

Scope

This page covers the three protocol changes and what they remove from the router’s view.

It does not cover VPNs, which move all traffic inside an encrypted tunnel. VPNs are covered in VPN and proxy on a child’s device.

It does not cover content classification. The page is about visibility, not about deciding what is and is not appropriate.

What the router used to see

A plain DNS query, and the matching TLS handshake, gave the router three signals:

• The domain name, in cleartext DNS.
• The SNI hostname, in cleartext TLS.
• The IP address the client connected to.

The router could decide on any of the three signals [source: www-rfc7754-filtering]. For HTTPS, the SNI hostname was the load-bearing signal: the domain name the user typed, before the certificate hides it.

What the router sees with DoH and DoT

DNS-over-HTTPS puts the DNS query inside an HTTPS request to a DoH endpoint [source: www-rfc8484-doh]. DNS-over-TLS puts it inside a TLS connection to a DoT endpoint [source: www-rfc9076-dns-privacy].

The router now sees only the IP address of the endpoint. The endpoint belongs to a public DoH provider; the IP is shared by many other HTTPS endpoints.

The router cannot tell from the IP alone whether the request is a DoH lookup for example.com or a visit to a website [source: www-rfc8484-doh].

Android exposes DoT and DoH together through the system Private DNS setting [source: google-android-android-private-dns]. iOS and iPadOS configure DNS through their Wi-Fi or cellular profile, and most current Apple devices accept DoH from the system resolver. In both cases, the family DNS resolver can be replaced at one tap [source: google-android-android-private-dns].

What the router sees with ECH

Encrypted ClientHello encrypts the SNI hostname inside the TLS ClientHello [source: www-rfc9849-ech].

After ECH is in force, the visible part of the TLS handshake no longer names the destination. The router sees an encrypted ClientHello to an ECH-enabled server. The hostname the user typed is inside the encrypted payload [source: www-rfc9849-ech].

RFC 9490 names this as one of the trends that make network-layer content controls less durable over time [source: rfc9490-mten].

What is not removed

Two things stay visible to a well-positioned router:

• The IP address the client connected to.
• The size and timing of the encrypted flow.

A filter that decides on IP address can still work, but IP-based classification is coarser than hostname classification. Shared hosting and CDNs put many unrelated destinations behind one IP [source: www-rfc7754-filtering].

A filter that classifies by traffic flow can still work for known services. A VPN to a known endpoint, a video stream to a known CDN, a DoH endpoint to a known provider. A new endpoint, or a personal server, breaks the pattern [source: rfc9490-mten].

Where the rule must live

Once the hostname is no longer in the clear, the rule has to live where the hostname is: on the device, on the account, or on the service.

• Device-level rules travel with the device, on every network. Examples: Screen Time on iOS, Family Link on Android [source: google-android-android-private-dns].
• Account-level rules travel with the account. Examples: a Netflix profile PIN, a YouTube Restricted Mode lock.
• Service-level rules live in the service itself. Examples: SafeSearch on Google, content maturity on Roblox.

These are the rules that survive DoH, DoT, and ECH [source: rfc9490-mten].

What a router can still do

Three things remain useful at the router layer:

• Require every device on the home Wi-Fi to use the family DNS resolver. DoH and DoT can be blocked at the IP layer; this is maintenance work, not a complete fix [source: www-rfc7754-filtering].
• Force SafeSearch on Google, where the family resolver still receives the query.
• Block known DoH endpoints to encourage the device to fall back to the system resolver, where the family resolver can be asked.

None of these is a complete defence. Each is a layer.

How to notice it stopped working

An encrypted-DNS layer that has stopped working does not announce itself. The page the parent thought was blocked simply loads.

Three signals mean the family DNS resolver is no longer being asked:

• The router’s DNS log shows traffic to an unfamiliar resolver IP.
• A test from the device asks a known DoH endpoint and resolves a domain that the family resolver blocks.
• The device shows a configured Private DNS setting that does not match the family resolver [source: google-android-android-private-dns].

To distinguish these from a configuration mistake:

• Test from a known device on the home Wi-Fi, with mobile data off. If the block holds here, the family resolver is working on this network.
• Test with mobile data on. If the page loads, the gap is the cellular path.
• Test with the device’s Private DNS set to the family resolver. If the block now holds, the device was bypassing it.

Talking about it

Encrypted DNS is a privacy feature, not a circumvention tool. A child who turns it on is exercising a default that several operating systems ship with.

State the difference. “This rule is the family DNS resolver. It only works when the device asks it. When the device uses DoH or Private DNS, it asks a different resolver, and the rule does not apply.”

State what the rule is not. “It is not a guarantee. DoH, DoT, ECH, and VPN are designed to keep the destination private from the network. That includes the family network.”

Re-check the device settings once a year. A new phone, a new OS update, a new app can all change the default resolver [source: google-android-android-private-dns].

Related wiki pages

The article on DNS filtering and its limits is the companion page on the resolver layer.

The article on Why router rules miss the phone covers the network paths a router cannot reach.

The article on What the network layer cannot do is the honest limits page for the package.

Sources

• www-www-rfc8484-doh — IETF, RFC 8484. Standard definition of DoH [source: www-rfc8484-doh].
• www-www-rfc9849-ech — IETF, RFC 9849. Standard definition of ECH and SNI protection [source: www-rfc9849-ech].
• rfc9490-mten — IETF, RFC 9490, IAB M-TEN workshop. Names encrypted resolver and hostname encryption as parental- control complications [source: rfc9490-mten].
• www-www-rfc9076-dns-privacy — IETF, RFC 9076. Network contexts and resolver privacy [source: www-rfc9076-dns-privacy].
• www-www-rfc7754-filtering — IETF, RFC 7754. Scope and efficacy of blocking [source: www-rfc7754-filtering].
• google-android-android-private-dns — Google Android Help. First-party Android Private DNS documentation [source: google-android-android-private-dns].

[source: www-rfc8484-doh] [source: www-rfc9849-ech] [source: rfc9490-mten] [source: www-rfc9076-dns-privacy] [source: www-rfc7754-filtering] [source: google-android-android-private-dns]