DNS Resolvers and Encrypted DNS: What 8.8.8.8 and 1.1.1.1 Actually Do
What actually changes when you switch DNS to 8.8.8.8? How recursive resolvers work, the dimensions for comparing public DNS, and what DoH/DoT encrypted DNS can and can't protect — covered in full, in one piece.
"Switching DNS to 8.8.8.8" is many people's first act after getting broadband. But what exactly are you changing? How does it affect browsing speed and privacy? And what is encrypted DNS (DoH/DoT)? This article covers the DNS resolver layer in full.
Where the resolver sits in the DNS chain
A complete domain resolution involves three roles:
- Your device (the stub resolver): asks the question "what's the IP for example.com"
- The recursive resolver: takes the question and runs the entire query chain for you — asks the root servers "who runs .com", asks the .com authority "who runs example.com", then asks example.com's authoritative server for the final answer, caches the result, and returns it to you
- The authoritative server: the machine that actually holds the records; it gives the final answer
The "DNS server" you set is layer 2 — the recursive resolver. 8.8.8.8 is Google's public recursive resolver, 1.1.1.1 is Cloudflare's in partnership with APNIC, and 114.114.114.114 is a domestic one. They run the errands and cache for you — and they see all of your domain queries. That's the core topic of this piece.
Choosing public DNS: three dimensions
Speed — the closer the resolver is to you, the lower the first-hop latency of the recursive query. For users in China, domestic public DNS (223.5.5.5, 119.29.29.29) is usually faster than 8.8.8.8, because Google's nodes are overseas. But note: fast resolution ≠ fast access; what really affects access speed is which CDN node IP the authoritative server hands you — which brings us to ECS.
ECS (EDNS Client Subnet) — the recursive resolver passes your subnet prefix (usually a /24) to the authoritative server, and the CDN uses it to return a nearby node. A domestic resolver passes your subnet to the domestic CDN and you usually get a closer node; some overseas resolvers don't send ECS or route the resolution the long way, and the CDN may schedule you to a far node. So the "some sites got faster/slower after switching DNS" phenomenon is usually not about resolution itself — the ECS scheduling result changed.
Privacy — resolver logs contain your complete browsing trail (which domains you visited, and when). Public DNS providers' privacy policies differ; that's the part most worth reading when choosing one.
DoH and DoT: putting a lock on DNS queries
Traditional DNS is plaintext UDP queries — anyone on the same network (your carrier, the WiFi administrator, a man in the middle) can see which domains you query, and even tamper with the answers (that's where carrier DNS ad hijacking comes from).
Two routes for encrypted DNS:
- DoT (DNS over TLS, port 853): wraps DNS in TLS over a dedicated encrypted channel
- DoH (DNS over HTTPS, port 443): wraps DNS inside ordinary HTTPS traffic, mixed in with web traffic, so the network can't tell "this is a DNS query" from "this is a site visit"
Because DoH shares the port with HTTPS and is harder to identify and block separately, it became the mainstream choice on the browser side: Chrome and Firefox both ship a "secure DNS" toggle, possibly enabled by default. Android's Private DNS (enter dns.google or 1dot1dot1dot1.cloudflare-dns.com in settings) uses DoT.
What encrypted DNS does and doesn't protect
Does protect: local networks snooping on your queries in plaintext (a coffee-shop WiFi admin only sees that you opened an encrypted channel), and carrier hijacking and ad injection based on plaintext DNS.
Doesn't protect: the recursive resolver itself — you've merely swapped "who sees your queries" from your carrier to the DoH provider; SNI leakage — when establishing an HTTPS connection, the target domain still appears in plaintext in the TLS ClientHello, so the network can still see what you visit (until ECH becomes widespread); and the recursive-to-authoritative leg, where the resolver itself still queries authoritative servers in plaintext.
In other words: encrypted DNS fixes the encryption of the "last mile", and privacy across the whole chain improves segment by segment. To check whether the DNS exit in your environment matches the network you expect (whether DNS "bypasses" the proxy and goes direct when you're on one), run the DNS leak check on the IPchase homepage — the mechanism is laid out in DNS leaks explained.
Practical recommendations
- Daily use in China: 223.5.5.5 / 119.29.29.29 — fast and stable; weigh the privacy policies yourself
- Privacy-first: 1.1.1.1 + DoH/DoT (enable "secure DNS" in Chrome, or Android Private DNS)
- Troubleshooting resolution problems: use DNS resolution diagnostics to query from public resolvers, bypassing the local cache, and compare results to tell apart local cache, carrier recursion, or authoritative record issues
- Corporate environments: internal domains depend on internal DNS; blindly switching to public DNS breaks access to internal systems — a classic IT ticket scenario
Resolution is only the first step; whether the resolved IP is healthy and whether it's really the origin are separate topics — see the next article for how CDNs change things, or go straight to the IP geolocation lookup.
Check your own network: run a full disguise check on the homepage, or try the fingerprint test.