[Autogenerated] When the system needs to resolve a domain,
it doesn't just shoot off a query into the void.
There's a method to the madness.
Firstly, it checks its own client cache.
Think of this as like the system's short term memory.
If the domain isn't there,
it sends a query to the DNS server which then checks its server cache.
But of like its own quick reference.
If it's still drawing a blank,
the servers check to see if it's authoritative for that domain or it hosts it.
If so, it looks at its zone and returns the record.
If not,
it then forwards that request onto its configured forwarders
or the root hints that it has only after these steps is a
response formulated and sent back.
Caching is crucial here.
It significantly reduced DNS query ties by eliminating the
need for repetitive lookups persists.
That means understanding and managing these caches can directly
improve network performance and troubleshoot DNS issues.
And this quick demo will unravel the magic behind DNS client side resolution.
We'll begin by peeking into our current cache,
proceed to resolve a domain while bypassing the cache
and then verify our cache's contents.
We'll finish by clearing the client side cache.
Let's dive right into understanding how D NS resolution works.
From the client side,
we use PowerShell to inspect and manage the DNS client cache and
simulate the entire D NS resolution process.
So first, I want to show you what's currently in the client cache,
so I could run the G DNS client cache command lit on any
Windows machine to easily see the client cache.
And it looks like right now it has resolved the srv one name in the past.
So to start from scratch,
let me clear the DNS client cache with the clear DNS client cache command.
Imagine you have a host, let's say example dot PS four assists admin dot local.
Let's see how the client goes about resolving it to
ensure we're really seeing the process.
I will skip the client cache for now,
I can skip the client cache by using the DNS only switch
here on the resolve DNS name command.
This completely skips the cache and then just goes directly to
querying whatever DNS server this machine has set up.
Let me check the cache again and now you can see that it has added the
10.00 0.4 or the PS four sys admins dot local record.
Let's test the speed when using a cache versus not using a cache to that first,
I will clear the client cache again to make sure there's not anything in there.
Let me check that again.
Yep, nothing in there.
And I will time both methods and I can do that by wrapping the
resolve DS name command in front into a script block and using
the measure command command to measure how long it takes for
this operation to happen.
Hey, now that thats done,
lets check and see how much time it took and it took around three milliseconds.
OK.
Well, that's not too bad.
Now, now that the record is in the cache,
let me make sure that it actually is in the cache.
Yes, its in there.
Now run resolve DNS name again.
And this time it should query from the local cache.
And now we can check the time using the cache and you can
see that it's still three milliseconds, the T 37 37405 and the T is 39886.
We did shave off a little bit of time.
This comes into play, especially when you have lots of DNS queries.
So for example,
when you're browse a website and you query dozens of dozens of dames.
This cache significantly speeds things.
Understanding the DNS client side resolution process here helps you troubleshoot
faster and knowing how to quickly perform tasks like this.
With PowerShell is a feather in your cap.
For this demo.
We'll journey through the inner workings of DNS server caching.
We'll start fresh by clearing our server cache,
then we'll resolve an external domains such as google.com.
As we delve deeper,
we'll measure the resolution time first by bypassing the cache and utilizing it.
And we'll observe closely how caching greatly enhances
the speed of our DNS resolution.
Jumping into the server side of things.
DN SS server caching plays a pivotal role in efficient
name resolution using PowerShell.
Let's delve deep into how DNS server handles,
queries, check its cache and interacts with its zones.
So to start off with,
let's ensure we're dealing with a clean slate here
by clearing the DNS server cache.
And if you couldn't tell already,
I'm remote into my SRV two server which is ad nt server on my network.
Clearing the DNS server cache is requires running
clear DNS server cache and confirming.
Yes,
we want to clear the cache records and all the cache
records should be gone on SRV server two.
Now, so let's check and see.
Now we can do show DNS server cache and now you can
see that there are still some there.
Now, you'll always see a set of records like this in the server cache.
Since it's hosting a zone, some records will always be in there.
And also, since it's using root hints,
you will also see all of the A dash B dash C dash,
et cetera, all the root dash servers, .NET,
those will always be in the server cache as well.
Now let's simulate a client and try to resolve a record.
Now, that's not in the cache that's external to the DNS server.
And you notice here that I am using the server
parameter of specifying SS RV two, even though I am on the SRV two server,
that's because the way that I orcus configure the SRV two servers,
NIC has SRV one to it.
So I need to specify SRV two to make sure that I'm being
querying SV two as a client right now that looks like a
successful google.com query has happened.
Now, let's look at the DNS server cache again,
scrolling up here a little bit and now you can see all of the
google.com records that have been cached.
Now for the fun part,
let's time the DNS server in action like we did the clients.
So first,
I'll measure how long it takes to resolve the domain
when it's not using the server cache.
So I will clear it first to make sure we have a clean slate
and time it when I'm not using the cache,
using the DNS only switch and now it should be cached.
Now, let's time it when the google.com records are in the cache.
And now we compare looks like it took a wow,
a whopping 11 seconds to do that query when it was not in the cache.
And the time in the cache looks like we're down to 17 milliseconds.
So you can see that there is a significant difference at the server
cache level when there is already a record in the cache.
That way, it doesn't have to reach out to an external DNS server.