[Autogenerated] Welcome back to protocol.
Deep dive DNA SAP. We've seen SSHD nested
configuration and their cache and how to
keep a bit of privacy as the clients are
surfing. But what about the server? How do
we set up a zone? Do we have to add all
the records manually? There's over 1000
hosts, a global ticket and 30,000 in
Globomantics. What about the server OS?
Will it be Microsoft THEANO. Sirs are
coming up in our next module, modifying
DNA's configuration for the servers. DNS
servers are part of a hierarchy. Once you
figure out where your server fits in that
hierarchy, you can configure which zones,
if any should be on it, then we'll add
different types of records. And finally,
at a sub domain, remember our zone
discussion from the previous module? We've
seen this from the client side. Let's go a
bit deep, bit deeper. By focusing on the
server side and just the Globomantics com
zone, two additional types of zones are
forward. Look up zones and reverse look up
zones. The forward look up is these actual
zone, but the reverse is optional, and
it's kind of like bread crumbs. It gives
you a way to find your way back. Suppose
that you know Google's public DNA? CSS is
88 Daddy at eight. But what if you wanted
the name? This is where the reverse look
up zone comes in. It gives you a way to
flip the information back from the
address. We'll use this with Ennis, look
up and Pointer or PTR records. They
reverse the record and let you find a name
based on IP. They let you flip DNS on its
head. Jane's aired nested administrator.
He's in charge of the Globomantics dot com
domain and the global ticket Globomantics
dot com sub domain. His court job is to
configure and maintain the Globomantics
com Zone. The components of the zone, our
servers and records. All DNA's servers are
either authoritative or non authoritative.
Jaden needs to set up some of both
authoritative servers, provide original
and definitive answers to DNS queries for
the zone that it's responsible for in
large environments. They don't respond to
Rikers in requests and therefore they
don't cache. They are a one trick pony.
However, Globomantics DNA servers perform
multiple functions. There are two types of
authoritative name servers. First, we have
a primary server. It has the read write
copy of the Zone records. The primary
requires at least one secondary for
redundancy. The secondary server has a
read only copy of the zone records. There
could be multiple secondary servers to
balance the load and provide faster
responses. Non authoritative servers come
in many flavors. A recursive server is the
one that clients talk to. They will
respond from cache if they have the
answer, and if not, they'll perform an
iterative look up on the client's behalf.
A caching DNA's server is a recursive
server. That cache is replies from an
intuitive look up. A forwarding server
passes all client requests where the
answer is not in cache to another DNA
server with recursive capabilities. Jaden
has to bear in mind that all non
authoritative servers cache, but not all
performed recur. Versioning Just like
people, DNA's servers have to multitask
when clients asked for a server within the
global ticket Globomantics dot com zone
Ennis one responds as these authoritative
server. Yet when the same client asked N s
one for a host outside the zone, Ennis one
could perform occurs in, or he could be
configured as a forwarding server by
sending all of the outside queries to the
Globomantics server, and this one is
acting as that forwarding server. More
importantly, N S and G one can be the
central caching point for all of
Globomantics. Now, when a client in one of
the other divisions wants to go to www dot
Pluralsight dot com, N S n g one already has it in its cache for a fast reply.