A device can send a DNS query to 8.8.8.8 and receive a packet that appears to come from 8.8.8.8 without the query ever reaching Google’s resolver.
That can happen when a network intercepts unencrypted DNS in transit. An on-path device recognizes DNS traffic, redirects or answers the request, and returns a response that still looks consistent with the destination the client selected. The application sees no obvious change, even though a different resolver handled the query.
DNS proxy terminology is less precise than it sounds
The phrase “DNS proxy” is used for several different behaviors. RFC 9499, the current DNS terminology Best Current Practice, notes that systems which forward DNS are sometimes called DNS proxies but that the term itself hasn’t been formally defined.
RFC 5625 uses a different idea of transparency. Its “Transparency Principle” says a simple gateway DNS proxy should interfere with DNS as little as possible, forwarding requests and responses so newer DNS mechanisms continue to work. It also recommends that users normally be able to send queries directly to a chosen upstream resolver, except where an active security or network policy requires otherwise.
In operational discussion and research, “transparent DNS proxy” is also used for a more intrusive behavior: an on-path device intercepts DNS that the client addressed to some other resolver. That behavior is more precisely described as DNS interception.
A client knowingly configured to use a local forwarding proxy and a client whose explicit resolver choice is silently overridden aren’t experiencing the same thing.
Hidden interception changes the resolver without changing the client configuration
Consider a client explicitly configured to query a public recursive resolver:
Client
|
| UDP/53 to 8.8.8.8
v
Network interceptor
|
| redirected query
v
Operator-controlled resolverThe network device can recognize conventional DNS by protocol and port, then redirect the request to another resolver. Some interception systems may instead duplicate the query or answer it directly. Implementations vary.
The response can then be returned with addressing that makes it appear to have come from the resolver the client originally selected. Research on DNS interception has documented this source-rewriting behavior, which makes simple inspection of the response source address insufficient to prove which recursive resolver actually processed the query.
Classic DNS over UDP and TCP doesn’t provide cryptographic authentication of the recursive resolver transport endpoint. That leaves room for an on-path network to substitute a different DNS path without negotiating that change with the client.
Interception can serve legitimate network policy
Not every transparent DNS interception mechanism is malicious.
Captive portals are a common example. Before a user has accepted terms or authenticated to a guest network, the network may intercept DNS or web traffic to keep the device inside a pre-authentication environment. RFC 5625 explicitly uses a pre-authentication “walled garden” as an example of an active network policy that may justify preventing direct use of another upstream resolver.
Managed networks may also enforce resolver policy for security, content controls, internal namespace handling, or other administrative requirements. RFC 9499 recognizes policy-implementing resolvers that change answers according to policy criteria, including blocking malware or objectionable content.
The operational question is therefore not simply whether a proxy exists. It’s whether the network is intentionally enforcing a documented policy, whether clients are expected to use that policy, and whether the mechanism preserves DNS behavior well enough for the environment it’s controlling.
Undisclosed interception creates a different problem
Transparent DNS interception has drawn criticism when network operators don’t clearly disclose that queries addressed to third-party resolvers are being redirected through provider-operated DNS infrastructure.
The issue is the mismatch between client intent and actual behavior. A user may deliberately select a resolver because of its privacy policy, filtering behavior, DNSSEC validation, logging policy, or troubleshooting characteristics. Hidden interception can replace those properties while leaving the client configured exactly as before.
RFC 5625’s guidance is relevant here. Outside an active security or network policy, it recommends that end users be able to send queries to specified upstream resolvers and that a gateway not modify those DNS packets.
A 2018 USENIX Security study examined hidden DNS interception using 148,478 residential and cellular IP addresses. The researchers reported interception behavior in 259 of 3,047 autonomous systems they inspected. That is a historical measurement of the networks tested in that study, not a statement about current global prevalence.
Hidden interception can bypass unencrypted DNS filtering
Resolver choice is often part of a DNS filtering design. A router, endpoint, or network may be configured to send queries to a recursive resolver that applies security or content policy.
If those queries leave the device as ordinary UDP or TCP DNS, an upstream network can intercept them before they reach the intended filtering resolver. The client can then receive an answer from a different resolver even though its DNS configuration still points at the filtering service.
That can produce several effects:
- Resolver-side filtering rules may never be evaluated.
- Query logs at the intended resolver may be missing because the query never arrived.
- Different networks may produce different results from the same endpoint configuration.
- Diagnostics that query a specific resolver can report misleading results if the network intercepts that traffic too.
This is one reason DNS filtering architecture can’t be evaluated only by looking at the resolver address configured on the client. The actual network path determines which resolver receives an unencrypted query.
The same issue can appear in less obvious forms when a carrier or network provider offers its own security, parental-control, or content-filtering service. If that service relies on intercepting conventional DNS, it can conflict with a third-party resolver policy selected by the user or organization. Whether that behavior is appropriate depends on the service agreement and disclosure, but the technical conflict is straightforward. Both systems are trying to control the same DNS path.
Encrypted DNS changes what an interceptor can substitute
Authenticated encrypted DNS makes this form of silent resolver substitution harder.
With a strict authenticated DoT connection, for example, the client verifies the identity of the DNS server before sending queries. RFC 8310 describes this specifically as protection against active attacks that redirect clients to rogue DNS servers. DoQ uses the same authentication model for the stub-to-recursive case, and HTTPS provides server authentication for DoH.
An on-path network can still block a connection, rate-limit it, or make the intended encrypted resolver unreachable. What it generally can’t do is transparently terminate an authenticated encrypted DNS session as the intended resolver without satisfying the client’s authentication checks.
That creates a different failure mode. Plain DNS interception can silently substitute another resolver. Strict encrypted DNS is more likely to turn an unauthorized substitution attempt into a connection or authentication failure.
DNSSEC doesn’t identify the recursive resolver
DNSSEC and encrypted DNS solve different problems.
DNSSEC can let a validating resolver or client verify signatures over DNS data from signed zones. It doesn’t establish that the recursive resolver at a particular IP address is the machine that actually answered the client’s transport connection.
The protection also depends on where validation happens. A client is protected from a tampered answer only when it validates signatures itself, or when it receives a validating resolver’s result over a channel it can trust. A stub that merely trusts the AD bit in a cleartext response gains nothing here, because an interceptor that can rewrite the answer can forge or strip that bit just as easily.
An interceptor that forwards a query through another validating resolver can still return correctly signed DNS data. DNSSEC may detect certain forms of answer tampering, but it doesn’t by itself prevent an on-path network from changing which recursive resolver handles the query.
Resolver authentication comes from the encrypted transport and its authentication model, not from DNSSEC signatures on the DNS records.
Troubleshooting requires proving which resolver answered
Transparent interception creates a difficult troubleshooting condition because the configured resolver, packet destination, and actual recursive resolver may be three different facts.
Consider a command such as:
dig @8.8.8.8 example.comThat command proves the application attempted to send a DNS query toward 8.8.8.8. On a network performing hidden interception, it doesn’t prove that Google’s recursive infrastructure processed the request.
Stronger testing uses a resolver or authoritative domain under controlled observation, resolver-specific behavior that can be verified independently, or an authenticated encrypted transport where the server identity is checked cryptographically. The exact method depends on what part of the path is under investigation.
This is also why VPN and split-DNS troubleshooting can become confusing. The route selected for DNS traffic can matter as much as the resolver address shown in operating-system configuration.
Summary
Transparent DNS interception allows an on-path network to alter the path of conventional DNS without changing the resolver configured on the client. The mechanism can support legitimate captive-portal and managed-network policy, but hidden use changes the privacy, filtering, logging, and troubleshooting properties the client may believe it selected.
The practical lesson is that an IP address in DNS configuration expresses where the client intends to send a query. With unencrypted DNS, it doesn’t prove who actually answered it.