Switching to a different DNS provider is one of the most frequently repeated pieces of internet advice, usually promising a faster connection. The change is easy and sometimes helpful, but the way it helps is widely misunderstood. DNS almost never affects how many megabits per second your line can carry, and it mostly affects how quickly a page begins to appear. This guide separates the two, puts real millisecond figures on a name lookup, and shows how to measure the effect for yourself before deciding whether a switch is worth making at all.
What a name lookup actually costs
Before your browser can fetch anything from a site, it has to turn the hostname into an IP address, and that request is a DNS lookup. The address it comes back with may be fixed or may change over time, a distinction the guide on static and dynamic IP addresses sets out, but either way the name has to be resolved before a connection opens. When the answer is already waiting in a nearby cache, the lookup is quick, often 10 to 30 milliseconds, roughly the round trip to your resolver. When nothing holds the answer yet, the resolver must ask the root servers, then the servers for the domain ending, then the site’s own authoritative servers, and that chain can take 80 to 150 milliseconds. Either way it happens once per hostname, and the result is stored so the next request skips the work.
Caching happens at every layer
A name lookup can be answered from several places, and each one that holds the record spares a longer query. Your browser keeps a small DNS cache of its own. Below it, the operating system caches records, the home router often does the same, and beyond your walls the recursive resolver caches answers for many users at once. Each record carries a time to live, a count of seconds set by the domain owner that says how long it may be reused. Sites you visit again and again are almost always served from one of these caches, which is why only the first contact with a new name carries the full cost.
Why one resolver beats another
Resolvers vary in how fast they answer, for practical reasons. The first is distance, since a resolver physically closer to you returns answers in fewer milliseconds. The second is how much it has cached, because a resolver serving many people is more likely to already hold the record you want. Large public services such as Cloudflare on 1.1.1.1, Google on 8.8.8.8, and Quad9 on 9.9.9.9 run servers in many cities and use anycast routing to send your query to a nearby one. That often makes them quick, though the fastest choice for you depends on where you live and which resolver your provider runs. The gap is usually tens of milliseconds per uncached lookup, and it sits on a baseline set by the connection itself, since a mobile link and a fixed broadband line start from different latencies, as the comparison of mobile data and broadband describes.
What DNS over HTTPS changes
Traditional DNS travels in plain text, which lets networks read and sometimes alter your lookups. DNS over HTTPS, often shortened to DoH, wraps those queries inside an encrypted HTTPS connection so they look like ordinary web traffic and cannot be quietly redirected. The privacy and integrity gains are the real point, and the speed effect is minor. Setting up the encrypted connection adds a little overhead to the first query, but that connection is reused for later lookups, so the ongoing cost stays small. Depending on which resolver you reach through it, DoH can end up slightly slower or faster, and in neither case does it change your line’s throughput.
| Where the answer is cached | Rough lookup time | What it means |
|---|---|---|
| Browser or operating system | Under 1 ms | Effectively instant, no network hop |
| Your resolver already knows it | A few to tens of ms | One short round trip |
| Cold, full recursive lookup | Tens to hundreds of ms | Several hops before the page starts |
A worked example on a cold cache
Picture a first visit, cache empty, to a shopping page that pulls content from 14 hostnames. Your device must resolve the first hostname before it can request the page, so that lookup sits on the critical path. With an ISP resolver answering in 48 milliseconds and a nearby public resolver answering in 19, the page starts arriving about 29 milliseconds sooner on the faster one. The other 13 hostnames are found as the first response is read, and the browser resolves several at once, so their cost overlaps with downloading rather than stacking up. Total DNS time across the load might fall from around 200 milliseconds to 90. Yet the 3 megabytes of images still take the same time to move over a 100 megabit line, close to 250 milliseconds, because download speed is set by the link, not by DNS. The page feels a shade quicker to start, yet a speed test afterwards reports an identical figure, the split between link rate and responsiveness the guide on Wi-Fi standards also draws.
Measuring lookup time yourself
You do not have to take any provider’s word for it. On Windows, macOS, or Linux, the command line tool dig reports a query time in milliseconds at the end of its output, so running it against a domain shows how long that lookup took. Run it once to prime the cache and again to see the cached figure, which should be near zero. Windows users can reach for nslookup or Resolve-DnsName instead. Browser developer tools also split each request into phases, listing the DNS lookup on its own. Testing a few resolvers at different times gives a more honest picture than one reading.
Deciding whether to switch
Changing DNS is worth trying when your current resolver is slow, distant, or unreliable, since a quicker one shaves the delay before pages begin to load and can make general browsing feel more immediate. It will not add a single megabit to your line rate, clear up a stuttering download, or repair a weak signal. Privacy and integrity, rather than raw speed, are often the stronger reasons to move to a service that supports encrypted queries.
The sensible approach is to measure rather than assume. Note how a few pages feel and what dig reports, switch to a reputable resolver, then check again after a day of normal use. Keep the change if pages clearly start faster, and revert if nothing improves. Remember too that the smoothness of a live video call or a game depends on latency and jitter along the whole path, not on name resolution, so a poor call needs a different fix, the sort the guide on video call quality problems works through. DNS shapes how quickly things begin, and little more.
Frequently asked questions
Does changing DNS make internet faster?
It can make browsing feel faster, but it does not raise your connection speed. A quicker resolver reduces the delay before a page starts loading, which is noticeable if your current one is slow or far away. It cannot increase the megabits per second your line carries, speed up a download already in progress, or fix a weak Wi-Fi signal. The effect lands on responsiveness, not throughput.
What is the fastest DNS server?
There is no single fastest server for everyone, because speed depends on your location and network. Large anycast services such as Cloudflare, Google, and Quad9 are quick for most people since they run nodes in many cities. The only reliable way to know is to measure them from your own connection using dig or a similar tool, at different times, and compare the query times.
Is DNS over HTTPS worth using?
For privacy, and to stop lookups being read or tampered with on the network, it is usually worthwhile, and most modern browsers support it. The speed effect is small and can go either way, so choose it for security rather than performance. If a particular resolver you reach over it sits far away, you may see slightly slower lookups, which measuring will quickly reveal.
