[Autogenerated] Let's see how that looks
on the client and on the server for the
cache and then determine whether or not
it's actually clear in wire Shark. Here we
are at N s primary. We'll go ahead and
start. Another capture with TCP Dump will
need to clear her cache. The command is IP
config slash flush DNA's. We'll start a
fresh capture just to make sure that we
catch everything now in our browser.
We can, go to www dot Globomantics dot
com. Then in a new tab, I can, go to a
site that everyone should be familiar
with. App dot Pluralsight dot com Now,
back at our server, I wanted to show you
the file that has the root hints. This is
that file I was talking about that when
the server was installed, this file came
with it and it's the IP four and IP six
addresses for all of the root servers.
You'll notice that the IP six address for
the G dot root servers is missing, which
is fine considering we're not using IP
IE6. But if we were, we could go ahead and
edit the file and put that entry in on RN
s primary server. The only records that we
have that resolve IP addresses are our
route hints and the two entries for our
sales server 10 12 3D 18 and eight Let's
open up PowerShell So we can See what's in
the DNAs cache of our server. The command
is show Dash Dina Server cache. So the
list of the route hints as well as our
sales servers are inner cache. Plus it has
learned quite a few more addresses. If I
want to clear the cache for the server, we
simply open the snap in and then in the
menu bar, go to action and clear cache.
When I go back into PowerShell and show my
cache again, I only see my root server
list. Let's go back to Gabriella Station
and we'll ping Globomantics com. Now I'm
not interested in getting a reply here
Like a good server. It doesn't reply to
Ping. I'm only interested in the DNAs
query here, So the fact that the server is
not responding is okay Now we'd like to
see what's in. Gabrielle is cache. If we
type in IP config slash displayed ness,
we'll see that she has the Globomantics
servers in her cache and the time to live
is 12 seconds back at the server. If
again, we go ahead and show the DNAs
cache, then we'll see. Once again we've
got Globomantics. Com. Let's look at that
in the peak apps. Here we are. Looking at
Gabrielle is peak app, and I've done a
filter for DNS. But there's 26 packets. I
don't want to scroll through them all, so
I'll narrow the scope even more by putting
in matches Globomantics there. That's a
little easier to work with. I can see how
fast the responses and notice it took a
little bit longer time. But remember, we
had cleared the cache on the server, so he
had to do recur versioning each time. And
here's our three IP addresses. This is a
filter we may do again and again, so let's
save it. I hit the plus button in the
filter bar and enter our button label.
Then, in the comments field, I'll show
that it's all Deena's traffic for a single
host. If you're filtering for a domain
more than once, it's nice to have this
template filter to work from the filter is
saved at the end of the filter bar. That's
what those double Chevron's are for. To
let you know there's actually even more
filters. See how this looks at the server.
I see that before we cleared the cache,
the server new and IP address of a top
level domain server for dot com. And he
asked that server for who is these
authoritative name server for Globomantics
dot com. But once we cleared the cache,
that information was gone. That's why, for
the second set of queries, our DNA server
had to go all the way to a root server. He
made his query for Globomantics dot com,
but he also added in that O. P t query
type so that the root server knows really
all I want. As an authoritative server for
dot com, the reply comes back for Server
H. One of the authoritative top level
domain servers for dot com. H is first in
the list, but you'll notice that the list
is actually quite long. Then, in the
additional records, there's these IP
addresses that we need. Our server will
put all of that information into his cache
and then go to one of those DNA servers to
ask for who is the authoritative server
for Globomantics dot com. Notice. Though
he didn't pick the first one in the list,
he picked the K server. Clients always
choose the first in the list, but servers
don't have to. The server might pick the
first enlist. He might pick randomly from
the list. Or he might pick in round robin
style. If he's had this list before, he'll
just take the next one from the one that
he's asked before going through the entire
list and then coming back to the top. This
gives DNS servers a chance to distribute
the low to those authoritative servers.
It's not perfect, but it's better than
nothing. Otherwise, the A server or Alphas
server is going to get all of the queries.
Now that we've got the IP address for the
case server of 1 92 52.1 78.30 our server
can ask the case server the exact same
question he asked of the root servers with
the same option request. Now our server
can ask the case server the exact same
question he asked before. But the case
server will no, we're really not
interested in W W W Yet what we are really
interested in is who's the authoritative
name server for Globomantics dot com. The
case server comes back with four
authoritative name servers for
Globomantics dot com, as well as an
additional record for that end as Dash 4
95 Server with an I P address. And it's
Primary just has to make a query to the
authoritative A server for Globomantics.
Com. When N. S 4 95 replies, he'll have
the IP addresses that Gabriella asked for.
Now, finally, our server has all of the
information that he needs to go ahead and
reply back to Gabriella. Notice that each
time the N s primary server makes a
request to an authoritative server, he
does not ask for Riker version. He's doing
that iterative Look up. Now let's look at
the time to live for each of these types
of answers for who the top level domain
server is for dot com. Our server can
actually keep that information for two
days. Same thing for how long he's allowed
to keep who. The authoritative server is
for Globomantics dot com, but noticed that
once he gets down to who the Web server is
and those IP addresses that information,
we could only cache for 60 seconds. So
these servers are in an A W s environment,
which is dynamic, and as software defined
networking or SD n. So those IP addresses
may change and may change quickly. That's
probably why whoever configure the domain
gave them such a small time to live. It's
actually the best thing to do, in my
opinion, but whoever configures the domain
gets to determine what the time to live is going to be.