DNS in Circumvention: The First Step and the First Leak

Name resolution happens before the connection and announces intent before protection starts. Three roles DNS plays, the silent fallback, and where to resolve names.

2026-08-31 GIGATAP Team #vpn
#vpn#anticensorship#dns#doh#privacy#leaks

DNS in Circumvention: The First Step and the First Leak

Every connection made by name has a step that happens before the connection itself: turning the name into an address. We will look at the three roles that step plays at once, at where resolution ought to happen, and at why a silent fallback to cleartext voids the setup at the worst possible moment.

That step is not usually treated as part of protection. It should be: it happens before everything else engages, and so it can announce intent before there is anything to hide.

Three roles DNS plays at once#

Worth separating, because they are defended differently.

A leak of intent. A name lookup says where you are about to go, a fraction of a second before you go there.

A blocking instrument. The answer can be substituted, or withheld entirely. It is the cheapest form of restriction that exists, and therefore the most common.

A point of failure. If resolution does not work, nothing works — no matter how good the transport is.

name ──► [ DNS ] ──► address ──► [ connection ] ──► data
          ↑                          ↑
     visible, forgeable          protected
     happens first               happens after

The ordering is the whole problem: the protected part begins after the unprotected part has already announced everything.

What does encrypting queries buy?#

Encrypted DNS removes the first role — the query content stops being visible to an intermediary — and greatly complicates the second: an encrypted answer cannot be substituted.

But new properties appear that get discussed less often.

Property Cleartext DNS Encrypted DNS
Name visible to intermediaries yes no
Answer can be substituted yes no
Resolver address visible yes yes
Resolver sees every query yes yes
Resolver can be blocked yes yes

Three rows did not change. Encryption moves trust from the network to the resolver rather than eliminating it. And the resolver’s address stays visible — meaning the fact of using non-standard name resolution is observable even when the content is not.

Silent fallback — the main practical problem#

Here is the class of error more common than the rest combined.

When the protected resolver is unreachable, most clients switch to the ordinary one — silently, without notification, so as not to “break the internet for the user.”

NORMAL                     UNDER INTERFERENCE
client ──► protected DNS   client ──► protected DNS  ✗
             │                          │
             ✓ name hidden              └──► ordinary DNS  ✓
                                              │
                                              └── name exposed
                                                  user not notified

The privacy property disappears exactly when it is most needed: the interference that stops the protected resolver from answering is most often the very interference you were defending against.

A check worth performing once: block the protected resolver and see whether name resolution keeps working. If it does, a fallback exists, and it is silent.

Where resolution ought to happen#

A separate question, specific to tunnels, and it determines whether there is a leak at all.

Scheme Who resolves the name What the local network sees
Resolution on the device the client, before the tunnel the destination name
Resolution at the exit the server on the far side only the server’s address

In the first scheme the connection goes through the tunnel, but the name was requested earlier and outside it. Protection is present; so is the leak.

Hence the rule: the name should be resolved where the trusted segment begins, not before it. The phrasing sounds obvious, yet default configurations are often the other way round, because local resolution is faster.

Leaking past the tunnel#

A related and very frequent case: some queries go around it even when everything is configured.

The causes are typical: the system resolver is pinned at the network level; an individual application uses its own resolver; corporate policy redirects queries; switching networks restores settings to their defaults.

The sign that catches it: everything works, but some names resolve differently than expected. The easiest way to notice is a discrepancy in results: the same name yields different addresses under different check methods.

A numeric example#

One connection to one resource. What an observer on the local network sees under four configurations.

Configuration Sees the name Can substitute Sees the address
Cleartext DNS, local resolution ✗ yes ✗ yes ✗ yes
Encrypted DNS, local resolution ✓ no ✓ no ✗ yes
Encrypted DNS with silent fallback, under interference ✗ yes ✗ yes ✗ yes
Resolution at the tunnel exit ✓ no ✓ no ✓ server only

The third row is the same configuration as the second, under interference. It produces the first row’s outcome. That is the price of a silent fallback: the setup looks protected and stops being protected precisely under pressure.

The fourth row is the only one where neither the name nor the destination address is visible.

Worth noting a dependency that is easy to miss.

The mechanism that encrypts a site name inside the TLS handshake takes its key from DNS. So with unprotected or forgeable name resolution it either leaks through the key lookup or silently fails to engage.

That makes the deployment order unambiguous: protected name resolution first, then everything that relies on it. The reverse order produces the appearance of a property without the property.

A practical checklist#

Where the queries actually go. Not what the settings say, but what leaves on the wire.

Whether a silent fallback exists. Block the protected resolver and watch what happens.

Where the name is resolved while the tunnel is up. Locally, or on the far side.

Whether the answers agree. Different addresses for one name under different check methods indicate substitution or a leak.

What happens when the network changes. Switching often restores system defaults.

Conclusion#

Name resolution is not an auxiliary detail but the first step of a connection, and it happens before protection engages.

Two claims worth taking away. First: encrypting queries moves trust to the resolver rather than removing trust — and the resolver’s address stays observable. Second, more practical: a silent fallback to cleartext voids the setup at exactly the moment it is needed, and is detectable only by a deliberate check, because from outside nothing appears broken.

Terms#

  • Resolver - the service that turns a name into an address; with encrypted queries, trust moves onto it.
  • Silent fallback - an unannounced switch to cleartext queries when the protected resolver is unreachable.
  • Resolution at the exit - a scheme where the name becomes an address on the far side of the tunnel rather than on the device.

FAQ#

Does encrypting DNS remove the need for trust?#

No. It moves trust from the network onto the resolver, and the resolver’s own address stays visible.

How do you check for a silent fallback?#

Block the protected resolver and see whether name resolution keeps working. If it does, a fallback exists.

Where should the name be resolved?#

Where the trusted segment begins. Resolving on the device exposes the destination name before the tunnel is in play.

Further reading#