[Autogenerated] Gabriella wants to
document the Rikers in process. She'll be
capturing both at the client and at the
server to minimize her footprint on the
server. She's going to use the command
line utility dump cap. Then we'll compare
the client and server peak apps using wire
shark. Then we'll compare the peak apps or
pack of capture files from both the client
and server in wire shark. Jaden hardness.
Admin will be running dump cap on N s
primary. We want our capture footprint to
be a small as possible on a server. If the
world were perfect, we would capture off a
tap or span the N s primaries port and
capture from that switch. But this is just
a test bed, so it won't be a problem. I'll
do a dump cap minus D to see which
interface we need. We want to capture from
Interface one, which is the default. We
won't even have to refer to it in the
syntax. I'll do a dump cap minus W to the
file name. Meanwhile, Gabriella will
capture at the client and browse to the
Public web server www dot Globomantics dot
com. Now Jayden will transfer the server
file over to Gabrielle rows Workstation
and compare the files. All you need to
stop the capture of the server side is a
control. See? We can do our filter for DNS
matches Globomantics. And here it the
client. We see we have a single query
and a single reply. This one took a bit
longer 32 milliseconds. But bear in mind,
this one had to go through recur version
this time the server response that he is
not the authority for the domain but in
our replies. Once again, we have multiple
IP addresses and the time to live for each
is 60 seconds. Now we can, look at the
peak app from the servers point of view
Gabriella's request to the local server
for w w dot Globomantics dot com. And this
time the server does not have it in this
cache. So he sends out an iterative
request. Noticed that Riker version
desired. Field says Don't do the query
recursive Lee. He'll ask individual
servers. He will not ask other servers to
find it for him, and he asks it with a
root record request. The response that
comes back is from an authoritative name
server and his primary has in its cache a
top level domain server, so there's no
need for him to go all the way back up to
the route. He starts with 1 92.33 14 30
which is a top level domain server for the
dot com domain. Notice that his query is
for w w dot Globomantics dot com Exactly
what Gabrielle isn't When she sent the
query in the first place, however, we know
it's part of the Ricker version process
from the server. Because of that
additional record the root record any time
that the additional record is for name and
the query type is for Option 41. That's
how we know that the server is really
requesting and on IP address for the
authoritative server for Globomantics dot
com, not who's www. In the response, we
see a new authority resource record for
Globomantics dot com. The type is for the
authoritative name server, so the dot com
server is letting us know that there are
actually three different authoritative
name servers. Three different
authoritative name servers for the
Globomantics dot com domain. Each one our
name server can cache for two days, then
in the additional records. We have the I P
address for one of the servers, and our
server can catch that information for two
days. Three IP address we can use is 205
to 51 1 93 dot to 39. Now RNs primary
server will go to that name server to find
the IP address for W. W. W. And that
request only took a millisecond for
response. Our server makes one more
request still in the query of w w dot
Globomantics dot com, but he asks for
additional records. Our response comes
back from the authoritative names of N S
Dash 4 95 and gives S3 IP addresses for
the three web servers of www dot
Globomantics dot com. Our server puts it
into his cache so that he can respond to
Gabriella in the next packet because this
response is coming from an authoritative
name server, and it's during a Rikers in
process. It's an iterative query. These
authoritative name server, N s Dash 4 95
gives us the three authoritative name
servers for Globomantics dot com for our
server to put into his cache. Finally, we
have a response from N s primary back to
Gabriella. She asked a single query for w
w dot Globomantics dot com, and she got
three answers in the reply. It's basically
the exact same packet as the one above it,
with a big difference of stripping these
authoritative name server responses. In
other words, when we were capturing at
Gabriella, we had no idea if the server
had to perform recur version in order to
get THEANO sirs to come back because we
had no name server records for the
authoritative servers. In other words, did
our server learned this information from
other DNA servers, or did he have it in
cache? We don't know when we capture it,
Gabriella. However, when we capture at the
server, we do see those records and we see
that our DNA serve making the requests on
Gabrielle rows behalf. So we know that
Riker version had to happen, and the
response time for that Riker version from
the top level domain server only took 1.3
milliseconds. But the response from the
authoritative server for Globomantics took
took 24 milliseconds on what concerns me
is the time in between the authoritative
responses received and then stripping
those records to send them to Gabriella
took 26 milliseconds and we were capturing
at the server. So there is no network to
blame. That should have been much faster.
In fact, it should have been in the one or
two millisecond range. Now we know we have
to keep a watch on N s primary. Now, our
server did not have to go all the way to
the route because it did have a top level
domain server for dot com in his cache in
an S primary. Already had a top level
domain server for dot com in his cache.
Let's see how it looks using a flow graph.
Not all of the external DNA's name servers
are resolving, and it's easier to show
names when you use the flow graph. So I'll
just right-click on those IP addresses and
put in the names that I want to use. I'll
put in a A for authoritative answers for
the dot com domain and then for N S Dash 4
95 I'll put in a and Globomantics dot com
and then for N s primary. I'll put in.
I'll put in that he's the local precursor.
Now if we just go up to statistics and
flow graph and then limit to display
filter, otherwise your head will explode.
There we do now I can see the pattern.
Gabriella goes to the local recur, sir,
who goes to a dot com authoritative server
who sends him a referral to the
Globomantics name server. And then the
Globomantics name server sends the IP
addresses. I must have messed up when I
was naming the Globomantics server.
Probably forgot to commit and hit OK, but
you can see how the flow makes it easier
to see who's talking and when. It's
perfect for showing those dependencies in
a protocol. What did we learn? Wires.
Shark profiles Make quick work of
filtering. Never use wire shark on a
production server. Use TCP dump or dump
cap, instead capturing it. A server makes
it easy to see why some responses are
slower. Cache and authoritative. Replies
are always faster than recur. Versioning up next, configuring DNA's for the clients