Smart DNS is not a VPN: what that DNS setting really changes

You point the TV at a Smart DNS resolver, one streaming app starts working, and the conclusion writes itself: this is a VPN that costs less and installs faster. It is not, and the gap is not pedantry. What changed is the answer the TV got when it asked where a hostname lives; what did not change is that every packet still leaves your house in the clear, on the same path, from the same address the ISP already knows. The myth is that a DNS setting is a tunnel. The reality is narrower and more useful once you see it.

The myth: a DNS change reroutes your traffic

Ordinary DNS tells an application where to connect. A Smart DNS service answers selected hostnames with addresses belonging to the provider's own infrastructure, so the app connects there instead of to the service directly. The provider then relays that one flow to the real destination. Nothing else on the device moves.

That is why the trick works on a television or a console at all. There is no client, no interface, no route table entry, no encryption layer. The device is doing exactly what it always did: resolving a name and connecting to whatever came back. You changed the answer, not the path of every packet.

The label is also used by unrelated DNS projects, so check the provider's own documentation rather than assuming a feature set from the name. There is no standard Smart DNS protocol; the coverage of one product tells you nothing reliable about another.

What is actually steered, and what is not

The distinction is easy to see once you list it by flow rather than by device.

You can watch it happen. Ask the provider's resolver for a hostname and ask a public resolver for the same one:

dig +short @<provider-resolver> example-stream.example
dig +short @1.1.1.1 example-stream.example

Different answers mean steering at the name layer. The same answer means either the service is not covered for that name or the device is not using that resolver — a failure that looks like DNS misconfiguration and is often mistaken for a broken account.

There is a second failure with the same smell. Many providers authorise by the public address you are currently using, so the account works until the address changes. Carrier-grade NAT rotation, or a VPN layered on top, moves that address and the relay refuses you, while resolution keeps succeeding. The registry entry is an access control, not proof of an exclusive exit.

Encrypted DNS is a third thing entirely

DNS over HTTPS and DNS over TLS protect the exchange between your device and the resolver. They encrypt and authenticate the query so the local network cannot read or rewrite it, and DoH carries that in ordinary HTTPS traffic on port 443, which is also why it looks like web traffic to a filter. That is a confidentiality feature for lookups.

Steering a service is a different function: the answer itself points at an intermediary. A product can offer both at once, and many do, but one does not imply the other. Encrypting your lookups has never moved a single byte of video through another country.

So "encrypted DNS" answers a question about who can read your queries. It does not answer who can see your traffic, and it does not give you a new exit address. The DNS over HTTPS specification is the right reference for what that protection covers, and it says nothing about routing.

Who sees what in each arrangement

With Smart DNS, the resolver sees the names you look up, the provider's relay sees the connections it carries, and your ISP still sees everything else in plain text structure: which addresses you contacted, when, and how much. Content remains protected by TLS to the destination in the steered flow, so the relay is forwarding an encrypted session it cannot read — but it can see that you connected, from where, and for how long.

With a VPN, the tunnel operator sees your traffic and your destinations, which is a single concentrated trust decision, and your ISP sees only an encrypted stream to one endpoint. Different exposure, not automatically less. Neither model should be judged by whether one site opens.

Speed follows the path rather than the label. A selective relay can keep unrelated traffic off a detour, which is a real advantage for a device that would otherwise tunnel everything. It is also no guarantee, and no arrangement promises permanent access to a service that is actively trying to detect it.

When Smart DNS is the right tool

It is genuinely the right tool when the device cannot run a VPN client at all — a television, a console, a set-top box with a locked network stack — and when only a named service matters. It is also reasonable when you deliberately do not want every packet on that device tunnelled.

It is the wrong tool when the requirement is encryption, a whole-device exit address, or protection from the local network and the ISP. Those are tunnel properties, and no resolver setting produces them. And if you keep a VPN running on the same device, expect the registration-based authorisation to break, because your public address is now the tunnel's.

Run this decision in order and stop at the first line that is true:

• Do you need the traffic encrypted and the whole device on a new exit? Use a VPN, and check its routes and exclusions rather than its connected indicator.
• Do you only need a few named services on a device that cannot tunnel? Smart DNS is proportionate.
• Do you need your lookups private but not your traffic moved? That is encrypted DNS, which is neither of the above.
• Does the provider rely on your current address? Expect breakage the moment it changes.