When a stub resolver is switched from the corporate resolver to a public anycast one such as 8.8.8.8, what changes in who resolves its lookups?

## Where the recursive tier sits A **stub resolver** on a host does not walk the DNS tree. It sends one recursive query to a configured resolver and waits for a finished answer. That **recursive resolver** is the only party in a normal lookup that truly recurses: it asks a root server, follows the referral to the TLD servers, follows the next referral to the **authoritative** servers for the zone and assembles the answer. Usually that resolver is the ISP's or the company's own. Pointing the stub at a **public resolver** such as `1.1.1.1` (operated by Cloudflare), `8.8.8.8` (Google Public DNS) or `9.9.9.9` (Quad9) does not change the walk. It changes **where the recursive tier sits**, and with it whose cache answers you, which zones are reachable and who receives your query names. | Question | ISP or corporate resolver | Public anycast resolver | |---|---|---| | Who walks root, TLD and authoritative | the ISP's or company's resolver | the operator's site that routing selects | | Whose cache answers a repeat lookup | that network's users | everyone whose queries reach the same site | | Internal and split-horizon names | resolvable through the company's internal zones | only what the public tree publishes | | Who receives every query name | the ISP or the company | the resolver operator | | Source address authoritative servers see | the ISP's or company's resolver | the operator's resolver | ## One address, many sites: anycast **Anycast** means the same address is announced into internet routing from many sites at once. Routers forward a packet for `8.8.8.8` to whichever announcement is closest in routing terms, so one address is answered by many sites. If one site goes down, its announcement disappears and traffic is routed to the next closest site. Three consequences follow: 1. The site that answers you can change when you travel or when routes change, with no change on the host. 2. Each site keeps its own cache, so the same lookup made from two cities can find different cache state. 3. Losing one site is handled by routing, not by the stub, which never knew which site it was talking to. ## Whose cache you now share - Your lookups land in a cache shared with every other client whose queries reach that site, so popular names are usually already cached. - A name nobody near that site has asked for recently still costs a full walk from the root. - Inside a site an operator may layer its caches, for example a small per-machine cache in front of a tier that sends all queries for one name to the same machine. - How long any answer stays cached is set by its TTL, which is a caching subject rather than a routing one. ## Why internal names stop resolving A public resolver starts every uncached walk at the **public root**. Names that exist only inside a company never appear there: 1. The stub asks the public resolver for `wiki.corp.example.internal`. 2. The public resolver asks a root server, which has no delegation for that private zone. 3. The walk ends with a "name does not exist" answer, which goes back to the stub. **Split horizon** fails more quietly. A company's resolver can serve an internal **view** of `example.com` in which `intranet.example.com` points at a private address. The public resolver only ever reaches the external authoritative servers, so the same name either does not exist or resolves to a public address. Listing the corporate resolver first and a public one second does not repair this: most stubs move to the next listed server when one fails to answer, not when it says a name does not exist, so internal names start failing intermittently whenever the stub happens to be using the public address. ## The second address, and what it does not protect against Each operator publishes a pair, plus IPv6 equivalents: - Cloudflare: `1.1.1.1` and `1.0.0.1`, published as a pair for redundancy. - Google Public DNS: `8.8.8.8` and `8.8.4.4`, with the advice to configure at least two addresses and never the same one twice. - Quad9: `9.9.9.9` and `149.112.112.112`, with the advice to enter all listed addresses to avoid single-path failures. A stub lists both so that when one address gives no answer it can retry on a second **path** to the same service. Both addresses still lead to the **same operator**, so the pair does not protect against a problem across that operator's whole service, and it does nothing about an answer that arrives but is wrong. ## Who now sees your queries - The operator receives every query name the host looks up, together with the address it came from; what it keeps is set by its published privacy policy. - The ISP no longer resolves those names, but plain DNS on port 53 still crosses its network in cleartext unless the stub uses an encrypted transport. - Authoritative servers see the operator's resolver addresses rather than the host's own, unless the resolver forwards part of the client's address to them. - The company loses the resolver logs it used to have for that host, along with any internal views it served.