Time
3 hours 28 minutes
Difficulty
Intermediate
CEU/CPE
4

Video Description

The first two sessions on DNS covered foundational topics including name resolution, records, and the evolution of the DNS system. In Part 3 of this Session Wednesday series, Kelly takes us on a deeper dive into the implementation and organizational structure of DNS. Some basic terms are introduced. A zone is an area of a namespace for which it is authoritative. In other words, a zone knows about a particular area and can be regarded as the "expert" or authority on it. Zones are set up on DNS servers. An example would be a DNS server that is authoritative for the Cybrary.com domain. There are several options for configuring zones on a DNS server ranging from simple to complex. In the Cybrary.com example, a single zone could handle the entire namespace which could potentially include all sub-domains such as east.cybrary.com and west.cybrary.com. An important rule regarding namespaces is that they must be contiguous: there can be no gaps between zones within a namespace. The decision to use one big zone to handle an entire namespace versus splitting up the namespace into separate zones residing on multiple DNS servers depends on network structure and load handling. Better performance can sometimes be achieved by splitting up a namespace into separate zones. The concept of zone delegation is introduced next. When a DNS server receives a request for a zone outside its scope of authority it must perform what is known as zone delegation. A server can either delegate down or up. In the case of a client request such as from an end user on a PC, the delegation flows downward. A namespace record with a pointer is used to find the DNS server that is authoritative for the requested zone. DNS forwarding is a request originating from one DNS server to another. The request is delegated up in a child/parent relationship. Such forwarding can also occur in a side-to-side direction on a conditional basis, but this is typically avoided since it's cumbersome. External name resolution for a domain outside of a server's namespace is directed to the client's ISP. An example would be a request for Yahoo.com to the Cybrary.com DNS server. More efficient lookups can be achieved by leveraging the cache of the ISP's DNS server.

Video Transcription

00:04
Heisei berry ins. Welcome back to session Wednesday and we're gonna continue our discussion on DNF. In earlier sessions, we just laid down the foundation and talked about name, resolution and how it's evolved throughout the years. Then we moved into a sessions Wouldn't stay episode where we discuss some of the records that D. N s uses
00:24
to resolve names to establish certain service is within the network
00:28
and to provide other assistance that network service is used. Now, what we want to talk about stays. We want to talk about implementing DNF and how that would look in a regular organizational structures. This is more the practical implementation of Vienna.
00:43
All right, so when we talk about the n s, we've got to define some terms and we've got a look at how this whole idea of name resolutions gonna happen for an organization. And when the first in one of the most basic ideas about D. N S
00:58
is what is a zone, what his own is. Okay, So if we talk about his own definition for his own as an area of name space
01:08
for which
01:10
a server is
01:11
1/4 hated
01:14
okay, then we're gonna further define authoritative, as knows about
01:19
All right, so let's talk about what this means. This means that the basic unit of DNF is a zone, and that's a specific area that a D N a server is responsible for. So let's look at, um, like an active directory, how we might have a domain, and this might be cyberia dot com.
01:38
And if we have a DNA server
01:42
that knows the information for the cyberia dot com domain, then we would say that that servers authoritative for the library dot com zone And what that's gonna mean to us is when clients in the side very dot com domain need resolution for Server one that library dot com they go to that d n a server
02:01
who is able to provide results
02:04
right, and it's very simple. It's very easy when you have a single domain. Now, when you have multiple domain, so this might be east,
02:13
that's I bury. And then you might have
02:16
west
02:19
about cyber eri
02:20
dot com.
02:22
Wow, what a result
02:23
Do they have to match toe active directory naming structures to have three zones tohave one zones? And the answer is maybe
02:31
maybe it's always a good answer in any sort of I t. Course. You'll always look very smart by going.
02:38
Okay.
02:38
Okay. So what determines the maiden? Well, it determines on how you set up your zones on this DNF server.
02:46
So one thing that I could do or the basic requirements, though, is that it be contiguous name space. So I can't have a zone for cyber dot com and kelly dot com. That's not contiguous name space. But I could have a single zone for all three of these active directory remains.
03:06
And this one d n a server knows about library dot com.
03:10
It knows about east ops library dot com and it knows about West dots library dot com.
03:15
Now that's very potentially going to be a whole lot of records and a whole lot of information that the CNS server is responsible for. But depending on the size of domains, that may very well be a good idea. You've got a single zone in the single circuit.
03:30
However,
03:32
I may wanna have a zone for each,
03:36
so I may wanna have one d. N s server responsible for cyber dot com.
03:40
I may wanna have a d N s server responsible for East. I may wanna have a d n a server for West that cyber dot com And on each d. N s server, I host the name space,
03:55
which creates the soul.
03:58
So the bottom line is, it really is more driven by your internal structure, your logical structure, things like the workload that you want to put on your d n a server. Ah, whether or not the servers will be across lower wind links, it really is more of a decision that an administrator makes.
04:16
Uh, the only thing I couldn't do in the scenario is host zone
04:20
off just east and west because that wouldn't be contiguous. Name space. Now, if I do cyber dot com and East and West, we got the name space.
04:30
Okay, so let's say that we do have three separate D. N s old. I've decided to have his own for cyber dot com a zone for e stott cyber dot com In his own for west, not cyber dot com. Alright, so every time my client goes to D. M s one will make these d N s 12 and
04:49
three
04:51
when we go to find i t dot library dot com or server one that's library dot com up in this domain with our clients.
05:00
Okay,
05:01
Deena's one can resolve those West requests because D. M S one is authoritative for cyberia dot com.
05:10
But where we get into trouble trouble But where we have to go a little bit further and configuration is, What if I need resolution for East that library dot com What if I need resolution for West? That's Highbury dot com. What if I need resolution for yahoo dot com? Right,
05:26
That's not with CNN Server set up to do. It's gonna give me zone information
05:30
for the name space library dot com.
05:33
Okay, but what if I am a user in this name space that says I need server one dot east dots? I bury dot com? Well, he is configured to ask being a server one for that information.
05:46
So the question is, how can I make this resolution happened seamlessly to the user and still get named resolution outside of the zone for which de ns one is authoritative?
05:58
The answer there is delicate.
06:00
Create a zone delegation and I always remember delegate down
06:05
and what that says essentially is go ask this server. As a matter of fact, when you actually create a zone delegation, essentially, what you do is just simply tell the clients, Go ask de ns two for the question. It's essentially saying, I don't know, go ask this guy.
06:24
So you creating a name service record and essentially a pointer
06:28
down here? So when the clients hit the N S one,
06:31
they're actually redirected. This is seamless to the users, but it's actually still the client who's making the request. That does not put a lot of weight on D. N s one that the NS one says, Go ask him. The client then goes and asks this guy the reason I try to make that distinction. Who is asking
06:50
who is actually the one sending the request down?
06:54
Sometimes we have firewall configurations where we may block on Lee traffic through on it from a certain source address.
07:02
So all the clients in here will have the ability, and we'll have the need to query the server down here so you can't be too specifically restrictive If you're configuring firewalls, source a source. I pee because I hope that makes sense. All right, So what do we do to allow the NS one?
07:21
Help clients resolve names in with
07:25
library dot com. We delegate down, right? So we create its own delegation record
07:31
and we delegate down. So now
07:34
up at the top are our top zone cyberia dot com. We can get named resolution to any of the three zones,
07:44
but we still have a problem. Because what if I'm in east dot cyber dot com
07:48
and I need resolution for library dot com
07:53
Or would if I need resolution for West, not library dot com.
07:57
Well, right now, inherently, I may not have that capability. So where's we look to delegate down with the n s servers. We forward up. So if we've got a parent to child, we delegate a child apparent, we forward. So what? The n s going to color code for your enjoyment.
08:16
All right,
08:18
so what we do here
08:20
is create boarding. Now, boarding has the ns to actually forward the request on behalf of a client. So when you're looking at delegation, the clients making the request down when you're looking at boarding the DNF server is actually the one sending that request.
08:37
All right, so we forward up on this side,
08:41
so we configure what we refer to his afford. All right, that basically says, Hang on, let me go ask this guy. The information that I need
08:50
now, one other thing. Um, if I'm in east, I need access to West. I can get that because I afford the request up to the N s. One who delegates the request down kind of cumbersome, right? So what we also do
09:07
is when we're going side to side or Pierre levels, we forward up
09:13
or side to side, so fording in those in both of those cases would be appropriate.
09:20
But
09:20
if I forward from East, that cyber dot com toe with what that essentially says is
09:28
every single name I can't resolve send over to this guy or that guy
09:35
that
09:35
don't get me wrong. That will work eventually way too cumbersome.
09:39
So we bring in element called conditional form affording. And when we talk about conditional fording, that's always kind of been format. If traffic is going to the east, I'm sorry if traffic is going to the west dot cyber ery dot com domain. Then asked the n s three.
09:58
If traffic is going to the cyber ery dot com domain, then go to the inn. That's one
10:05
A. And that's more of a streamlined way to configure your Dina servers so that they can communicate with each other and make the most out of name resolution. Now, the last thing to figure out is, what if it's not a library dot com name space?
10:18
What if we want? Yeah, What if we want this? That or the other? None of these servers are gonna be authoritative authoritative
10:26
for all the servers out there in the Internet. So who do we ask?
10:30
That's where we go out. We asked our I S p
10:33
so out in the distance, out in the ICO snout in the magic cloud we have our i s peace
10:41
So we'll set up conf additional fording if West go to D. N s three over here
10:48
If East go to the n s too.
10:50
Okay, we'll get delegation down there fording up, but basically all else everything else gets four did to the I S P.
11:01
That way we can take advantage of our Internet service providers cash.
11:05
We have access to all the Internet service is now. Don't get me wrong. Traditionally, we've used things like root servers, but now there's really not as much need to do that. We can take advantage of our Internet service providers, DNF. We've got all the cash we got all the information. We got directives to the other significant servers out on the Internet.
11:24
So I hope that this is helpful in just configuring a D. N s infrastructure. It's kind of an overview of how you're going to go about it. So zone. It's the area of the name space for which a servers authoritative. It does not have to be bound to your number of domains. It's strictly bound to your name, space
11:45
and how you want to configure traffic, the amount each server can handle and how you want to organize your environment.
11:52
Hey, you could have in this scenario a single zone. You could have two zones, you know, cyber dot com West. That's library in the east on its own. Or you could have three independent
12:03
totally your preference. I tend to prefer this because every traffics kind of directed locally and logically. All right, then tow, allow name resolution, all the way throughout, We delegate down,
12:15
we forward up, and then usually we conditional forward, side by side.
12:20
Everything else is configured for traffic out to the Internet service provider That gives us access to any other names that we, uh, that we need resolution. All right, so thanks for joining us on session Wednesday. I hope this information on D. N S was useful, and we'll see you next week.

Up Next

Strategic DNS Ops and Security

Domain Name Servers (DNS) are the Internet's equivalent of a phone book. They maintain a directory of domain names and translate them to Internet Protocol (IP) addresses

Instructed By

Instructor Profile Image
Anthony Harris
Systems Analyst and Administrator at SAIC
Instructor