[Autogenerated] Now it's time to look at
DNA's errors. Source. I've merged all of
the DNA XFILES we've created so far into a
single file. We will have lots of
opportunities to look for errors. It has
all the DNAs we've seen so far, both
successes and errors. That way, when we
look at an error we can check to see if it
succeeds later. JSON has the file open.
He'll go to statistics and back down to
DNA's. All of our response codes are
listed together. Seems like server failure
has the highest count, with 9.66%. We can
do display filters for each of the
servers. Jaden tries the bind server.
First Bind has a low percentage, but
remember it also had the fewest queries.
Jaden wants to apply an error filter.
Next, he'll go up to the filter button
group for responses and come down to
errors. Don't be afraid of the caution.
Yellow filters. Any time you use a not SQL
filter, which is what the exclamation
point or bang equals is, it will be yellow
just to let you know it could yield
unexpected results. Let's start with the
errors that had that slow response As I
said before, we had a lot of server
failures, and that sounds so scary. But
actually, what it really means is that our
server failed to get a definitive answer
from the authoritative server. They were
able to perform recur version and get an I
P address for the authoritative server.
But when they sent the iterative query on
the client's behalf, they got silence. Now
they're acting on the client's behalf. So,
of course, what do they do? They try again
and they get silence. They'll try three
times, sometimes four, just to be sure.
And if there is no response at all, then
our local recur, sir, will respond back to
the client with I have failed to get a
definitive answer. That's what the server
failure really means. It's not our server.
It's them. Let's change the filter. We've
seen number two server failures. Let's
change it to three and look at no such
name. How's this for irony? One of the
root servers is letting an is primary know
that it doesn't have an S o a record for
in its primary. This is one of those
strange situations because I'm running it
in Azure, and I don't have it set to work
with the actual azure ID nested. I'll
filter for the transaction. IDE. Let's
check with an outside server. Which route
that happens to be, I'll do a. Nen is look
up with the IP address of the server, but
I don't want to use one of the global
ticket servers. I want to use an outside
server, so I'll put in eight. Daddy,
Daddy, Daddy, which is Ghoul's public DNS
server? A. That's the Delta Root server.
So Anna's primary went to the Alfa Root
Server looking for its own name and a
route record, not getting an answer. Then
it went to the Delta Root Server, asking
the same question. When the replies came
back, both servers said, s primary, We
don't have that No such name, that domain
or that host, which ever one you asked
for, does not exist. This is also known as
the N X domain response. The next response
code I want to look at is number four,
which is not implemented. You've just
asked a question that I don't understand
notice they're coming from N s primary
going to an outside DNA server and they're
looking for a txt or text record for what
version of bind are you using? This isn't
coming from another DNS server. This is
reconnaissance. We'll have to discuss this
with Suhani and make a list of different
query types we need to block number nine,
which means not authoritative. Notice that
it's a zone change notification response
coming from the bind server going towards
the primary. That means a change was made
on the primary and the primaries way of
letting the secondary and is bind server
know about it was with a zone change
notification. And yet the response is not
authoritative. This must have been when we
first added bind as a secondary. If we use
our transaction IDE filter we can see the
entire chain of events now we can see that
the primary notified each of the three
other DNS servers about a change, but only
are buying two. Server sent the response
acknowledging the change. A new feature in
3.4 wire shark lets us see the layout in
textbook format. I'm going to go into edit
and preferences and lay out and change it
from packet bites to pack it diagram. Now
the layout looks just like it would in a
textbook or in the RFC. Many people prefer
this to looking at the hex. It doesn't
fill in the values for the queries and
responses yet, but as more releases come out, additional protocols will be added.