[Autogenerated] in the this demo will
capture Gabrielle is traffic to see a
query to the local server will use a pre
made profile in wire shark to make
filtering the traffic easier. Who? Go
ahead and download the Betty dashed DNA's
do gzip file that's in the exercise files.
Don't unzip it, though. I'll show you how
to import it in to Wire Shark. Then we'll
walk through the DNS fields in wire shark.
Here we are at Gabrielle is computer.
Let's start a fresh and new peak app.
We'll go ahead and set a filter for DNS.
She'll open up the sales web page, so
we'll be able to see her. DNS query. There
it is. Global tickets sales information
will stop the capture, and I have a few
extra DNA's packets for some background
processes. But we'll go ahead and save the
peak app. All of the peak apps will be in
your exercises Tab. This way, you can
follow along. Now. I have a wire shark
profile for this course to make things a
little bit easier to work with. It has
lots of filters and extra columns and
color coding. Let me show you how to go
ahead and import it into your wire shark.
You'll want to be sure to download the
DNAs profile when you download all of the
peak apps. Let's see how to import that in
to wire shark. I'll go to edit and
configuration profiles and then click
import from a zip file. Now Gabriella has
saved it into her documents folder. So
there it is. Dash DNS does it and just
click. OK, now why A shark will look a
little bit different, but it'll be easier
to work with, since there were some extra
Dean is packets. We'll want to do a
regular expressions, filter or rejects.
We'll use the term matches and gives us a
lot of options. My personal favorite are
wild cards for right now we know that any
DNS query that has the character string
sales is going to be what we want, and
that's what this filter does for us. So I
see in my Info column that I have a query
and a query reply. If I expand, the query
will be able to see that the first field
is the transaction ID. That's the field
that correlates the request and the reply
in my flags field. The message is a query,
and it's a standard client. Query will be
able to see different types of op codes
later when the servers initiated
conversation. The message has not been
truncated. And what what truncated means
is that the response comes back. It's too
large to fit into a single packet. And if
that happens, let's say a response takes
three packets. They're going to be sent in
123 order, but they might not be received
in 123 Therefore, sending those packets
over UDP will not work. They need to be
sent over TCP because TCP Kanban handle
out of order packets, put them back in
order and pass them up. 2D nested in the
proper order. So if the response comes
back and says that has been truncated,
it's up to the client to go ahead and
initiate that same request over TCP so
that the server consent the response all
three packets over that TCP connection,
and if they received out of order, no
worries. TCP will go ahead and take care
of that and the way that the server
comptel the client, that is by flipping
that truncated bit the next one is for
Riker version. We'll talk about Ryker
version a little bit later. The next bit
is for non authenticated data. The client
wants the server to check with the
authority. So if you're not the
authoritative server, then I want you to
go and check with them first. To make sure
you've got good data, This server is going
to go ahead and respond from cache. This
this server will go ahead and answer from
cache because its faster we've got one
single question with no answers or
authority resource records or additional
records. Those will come in the reply.
IPhone up the query. You'll see that the
client requested Salesforce gt dot g m dot
com. The length of the entire request is
15 bites, and the label count is four.
Labels are the words So sales GT GM come
four labels and the client is requesting
an A record, and that is an IP four
address. Why are shark uses that
transaction? IDE to find the response and
you could just double-click on the packet
to go to it. And now we can see our
response notice the transaction IDE is the
same one but we have a little bit more
information in our flags. Field number one
that it's a response to a standard query.
Our server is these authority for the
domain. Gabriella sent her request to her
primary server, which actually is these
authority for the domain message hasn't
been truncated, and that's always where
you look for that is in the responses. The
client asked for incursion and the servers
capable of doing recur version. But the
most important piece is that reply code of
no error in the replies that comeback
noticed that I have to each one with a
different IP address. Global Ticket is
load balancing between the servers.
They're both Taipei records because that
was what was requested on the internet.
That's what the I N stands for on class.
The time to live is 3600 seconds. Time to
live is always listed in seconds, and then
wire Shark puts into parentheses that it's
one hour. The time to live is how long
Gabriella can do cache this information
unless something unforeseen happens for
the next hour. If she requests Salesforce
gt at gm dot com, it'll be there in her
cache, which means she doesn't have to go
to the Dina server again to ask the same
question. Now, of course, if she needs it
two hours from now, she will have to go
back to the Dina server. And then the last
field is. How long did it take? Now that's
a wire shark field noticed that it's in
square brackets. That's how wires shark
says, Hey, I'm putting this in here for
you, and the time is six milliseconds,
which is a great response time. And that's
from the time that it left. Gabriel is
computer to, however it long to go through
the network. However long it took for the
Dina server to process the response and
send it back, that entire process only took six milliseconds.