TechKnowSurge
Cisco CCNA 4.3 CompTIA Network+ 1.4 CompTIA A+ Core 1 2.6 CompTIA Network+ 3.4 CompTIA Server+ 2.2
VideoNetworkFree

DNS Caching

DNS caching stores resolved domain-to-IP mappings locally so clients can skip the full lookup process on repeat visits. Time-to-live (TTL) values control how long those cached records remain valid before a fresh lookup is required.

Complete this video to capture a CTF flag worth 1 point.

About this video

DNS caching is a core efficiency mechanism that prevents clients from repeating the full recursive lookup process every time they access a domain. Once a resolver receives an authoritative answer mapping a hostname to an IP address, it stores that record locally. Any subsequent request for the same domain is answered directly from the cache, avoiding unnecessary round trips to root servers, top-level domain servers, and authoritative name servers. Every cached record includes a time-to-live (TTL) value — a countdown that determines when the record expires and a fresh lookup must be performed. TTL configuration requires a deliberate tradeoff between stability and agility. Historically, administrators set long TTLs, sometimes measured in days, to minimize lookup traffic and reduce server load at a time when bandwidth was a limited resource. In modern infrastructure, where server migrations, provider changes, and IP address updates happen frequently, long TTLs can leave clients pointing at stale records for extended periods after a change. A common mitigation strategy is to reduce the TTL well in advance of a planned change — sometimes to just a few minutes — so that cached records expire quickly and clients pick up the updated mapping with minimal delay. Once the transition is complete, the TTL can be restored to a longer value. At the network level, caching operates across multiple tiers. Internet service providers frequently deploy shared caching servers that resolve and store DNS responses on behalf of all their customers, significantly reducing the volume of queries reaching the root server infrastructure. Organizations and enterprises deploy their own internal DNS caching servers for the same reason, keeping resolution traffic off external internet connections and improving performance for users on the local network. Clients can also be configured to use third-party caching resolvers, such as those operated by Google or OpenDNS, as alternatives to ISP-managed servers. On home networks, the router itself typically serves this caching function, acting as the first point of DNS resolution before queries travel further up the chain.

What you'll learn

What's covered

DNS Caching & TTL

Aligned to

Cisco CCNA
4.3 Explain the role of DHCP and DNS within the network
CompTIA Network+
1.4 Explain common networking ports, protocols, services, and traffic types
3.4 Given a scenario, implement IPv4 and IPv6 network services
CompTIA A+ Core 1
2.6 Compare and contrast common network configuration concepts
CompTIA Server+
2.2 Given a scenario, configure servers to use network infrastructure services

Key terms

Domain Name System
DNS
A hierarchical naming system that translates human-readable domain names into IP addresses.
Time to Live
TTL
A value in a packet that limits its lifespan on a network, preventing it from circulating indefinitely.
DNS Caching
The local storage of DNS query results so that future requests for the same domain can be resolved without repeating the full lookup process.
Caching Server
A server that stores copies of DNS query results to serve repeated requests from multiple clients without forwarding each query to authoritative DNS servers.
Internet Service Provider
ISP
A company that provides end users with access to the internet by connecting them to the internet backbone.

Transcript

Your machine, once it goes to www.techknowsurge.com, will probably access a lot of different resources on it. It's probably going to establish a few connections and download a lot of different resources from www.techknowsurge.com.

Caching the answer

If every time it did access this server it would have to go and redo this process of asking the root server, and then the top level domain servers, and then the techknowsurge.com servers, just to get this, it wouldn't be an efficient way of being able to communicate. So what it does is, when it gets the answer back from the last domains, the authoritative answer, then it will cache the answer. That answer will be logged and it will say, okay, www.techknowsurge.com has this IP address. Now, instead of going and asking all the other servers every time, it just looks in its local cache, its local DNS cache, looks for that information, and then uses that information to reach out to www.techknowsurge.com.

Time to live

Obviously, things change often out there. So there are times when, well, I'm going to switch servers, and instead of being on one server I'm going to move that to another server. Or perhaps that server has gone offline and it needs to be moved to another server. Or perhaps I've changed services. So there are going to be times when I want to expire that cache in there.

That's what the time to live is for. When this machine gets the authoritative answer back and it puts it into the cache, it also puts a time to live in that cache as well, and that's going to be a countdown for when that record is going to expire.

It used to be that we'd set really long time to lives on our records, because we didn't want it to keep coming back to our servers and constantly ask for that information — but information wasn't as dynamic either. In today's age, we have some pretty dynamic content that's out there, and pretty dynamic changes that happen within our networks. If we say that our time to live is going to be 10 days, then every time we make a change we're going to have to live with straddling those two environments for 10 days before it actually switches over.

What I mean by that is, let's say we have two servers, and the DNS record that we got back says this is the IP address that you're looking for, for www.techknowsurge.com. I'm hosting it off of this server right here. I decide to change, and now I'm going to move it to a different service provider, so my IP address has changed. If I have a 10-day expiration on that, that means that I am not going to get an update for all of my clients until 10 days later. In that scenario, I may want to change the time to live down to maybe 15 minutes, and then I can make the change and 15 minutes later it makes the change.

What I've also done in the past is I put a long time to live on my records, like let's say 10 days. Then if I know that I'm going to make a change maybe a couple of weeks from now, I'll switch it from 10 days down to just a few minutes. Leading up to that, then everybody will be getting this update and we'll be constantly checking in. I can make my change, and then after my change is made, then I'm going to make it go back to the 10-day time to live, and so then I'm back to where it was before.

In today's age, doing all this DNS work and doing these lookups every 15 minutes isn't as big of a deal as it was 20 years ago. When it was 20 years ago, bandwidth was at a premium and you did whatever you could to save that bandwidth. So lower time to lives are not that big of a deal nowadays, but it used to be a much bigger deal. Especially when you get into more remote areas, like some of the remote areas of Alaska, and other countries that don't have as good an internet connection, and bandwidth still is at a premium — then you do have to start thinking a little bit about what your time to live is and how often you want machines to check in with that time to live.

ISP caching servers

Typically, we all visit a lot of the same resources. There are some pretty popular sites out there. If your internet service provider is allowing all this communication to go out to the root server and the top level domain server and the domain server, if it's doing all of that, then all of the machines that an internet service provider has, that generates a lot of traffic for that internet service provider.

So what an internet service provider often does is they'll set up a caching server. Most of the time your machine is actually going out to maybe a caching server, or some other server that's out there that is going to do the resolution for you and go and contact these servers. This caching server right here will then cache that, so that any other clients that are connecting out and asking for the same resources that you're asking for, it already has an answer for that. So ISPs will cache that information for all their customers to use, and that's pretty common for us to use caching servers.

That happens both from the ISP's perspective, and sometimes you'll bypass the ISP and you'll go to another caching server that Google offers, or OpenDNS, or there's a lot of other options out there that you can send your traffic to, rather than trying to go out directly to the root server. Obviously, if there's too much traffic going to this root server — there's got to be a massive amount of traffic going to this root server already, and if every single client were to do that, then it would really bog down whatever our root servers are.

Company DNS servers

Then we also have a company DNS server. So your machine is contacting this company DNS server. When you're on the network, it's using that DNS server. Then it's going out to the ISP, or maybe something like OpenDNS or some other caching server, and then that is going out and doing the resolution for you. It's caching it for you and for every other customer. When it gets the response back, then this machine caches it right here.

The reason why you would set this up is, once again, so your company doesn't have as much DNS traffic going to the outside world that is unnecessary. As companies grow, it becomes more and more likely that they're going to have a DNS caching server inside the LAN, so that your machine can access things directly rather than all that DNS traffic taking up the lines, the internet connections, to the outside world at your company level.

This also would look like — if you look on your home network, it's probably your router or your ISP that's providing the DNS.

About TechKnowSurge

TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.

Explore free tools and programs →