Network services.

In this section of the course,

we're going to discuss some network services

that are testable on the CompTIA Network+ exam.

For the exam, you must be able to explain the purpose

of each network service, it's use,

and some basic configuration information for each one.

Specifically, we're going to talk about DHCP, DNS, and NTP

in this section of the course.

Now, DHCP is the Dynamic Host Configuration Protocol.

DHCP is a network management protocol

that is used for internet protocol networks

for the automatic assignment of IP addresses to devices,

as well as to providing the subnet mask, default gateway,

and DNS server for the device to use

when it connects to the internet.

We're going to talk more about DHCP

and its configuration options in a separate video

to more fully cover DHCP in depth.

DHCP is going to operate over ports 67 and 68

using the User Datagram Protocol, known as UDP.

Next we have DNS, which is the Domain Name System.

DNS is a protocol that's used to convert domain names

to IP addresses using a hierarchal

and decentralized system of naming.

DNS is a phone book for the internet, essentially.

So, when you type in diontraining.com into your web browser,

you don't have to memorize the IP address of my web server.

Instead, DNS is going to convert it for you.

DNS is a bit unique in that it operates both

over UDP and TCP using the exact same port,

port 53.

When DNS is conducting a domain name query or lookup,

it's going to use UDP to accept that request from a client

and then send the response from that server back.

But, if DNS is going to be doing a zone transfer

between two different servers,

it's going to use TCP for that.

Now, a zone transfer is the method used by DNS servers

to share information between themselves

about which domains they have

and the associate IP addresses for those domains.

For this server-to-server communication,

TCP is going to be used instead of UDP

because these servers want to verify

that the information was received by the other server

and that it was properly received during that transfer.

Again, we're going to talk more about DNS in a separate video,

where we could spend more time digging

into all the different DNS record types and their uses.

Finally, we're going to talk about NTP

or the Network Time Protocol.

NTP is a networking protocol

that's used for the synchronization of clocks

between different computer systems

that communicate over a packet-switched,

variable-latency data network.

Now, TCP IP networks are packet-switched networks.

So, NTP is going to be used for the synchronization of time

across our IP-connected servers when using TCP.

NTP is kind of special because it's really old

and yet, we still use it today.

In fact, NTP is one of the oldest internet protocols

that we still use in modern networks.

NTP data is going to be sent using UDP over port 123.

We're going to be spending an entire video in this section

talking all about NTP as well,

so you can better understand how it operates,

both from the client and server perspective

to make sure everyone's using the same time in,

so you can understand why time is so important.

So, in this section,

we're going to be diving into domain one,

networking fundamentals,

and we're going to focus only on one objective here.

Objective 1.6.

This objective states

that you have to be able to explain the use

and purpose of network services.

All right, let's get started talking

all about DHCP, DNS, and NTP in this section of the course.

DHCP or the Dynamic Host Configuration Protocol.

Initially, we used to have to manually provide an IP address

to every machine on our network,

which is not really a big deal in your house

where you might have three or four machines,

but in the large networks I've worked on,

we have hundreds or thousands,

or hundreds of thousands of computers and servers on them.

That is a ton of labor hours that we spent

just for configuring all of these devices.

So, someone was really smart

and create an automated way of doing it, known as DHCP.

DHCP was invented to help us with this monumentous task

of configuring all of these servers and workstations.

Now, DHCP also can help eliminate configuration errors

because when a person is entering an IP address

into an end user's device,

there is an opportunity for human error,

where they fat finger it and type in the wrong one.

Also, it can be really hard to maintain a good list

of every IP that every computer is using

inside of your network.

So often, you can get IP conflicts by assigning the same IP

to multiple machines inside the same network by accident.

With DHCP, none of this will happen,

because each device is automatically going to get assigned

an IP from a scope.

Now, a scope is simply a list of valid IP addresses

that are available for assignment or lease

to a computer or an endpoint on a given subnet.

Now, for example, in my home network,

I have 254 IPs available for devices in my scope.

So, when the computer joins my home network,

the DHCP server automatically picks one of these unused IPs

from the scope, 192.168.1.2

all the way up to 192.168.1.254

And then it gives that IP to that device to use.

This is known as a lease.

As a network administrator, you can tell your DHCP server

what IP addresses should be used in your scope

and you can even reserve some of those IPs

that you don't want to be handed out

as part of what's known as an excluded range

within your scope.

For example, in my home network,

I have a couple of IP addresses

that have been excluded from my DHCP scope.

These are IP addresses in the range of 192.168.1.2

up to 192.168.1.10.

These IP addresses have already been assigned

to some of those things in my network manually by me.

Things like my printer,

my network file server, and other things like that,

that I always want to have the same IP address for.

Now, another way you could do this

instead of statically assigning these IPs

is to use something known as a DHCP reservation.

This is very commonly used in large networks.

Now, a DHCP reservation lets you exclude

some of these IP addresses

from being handed out to devices

unless they meet certain conditions.

For example, I could set up a DHCP reservation

for my printer based on its MAC address.

That way, whenever my printer joins the network,

the DHCP server sees that it joins, checks its MAC address,

and then assign the exact same IP

every single time to that printer,

because it's been listed as a reserved address

inside the DHCP scope.

This is a great way to do things

when you have a large network,

instead of having to manually configure

each endpoint device with a specific IP address.

This lets your DHCP server do it for you.

Essentially, giving it a static address every single time,

but using this automatic configuration.

So, with DHCP, we can automate the process

of configuring all of our devices whenever they come online.

When the device joins our network,

it's going to reach out to our DHCP server

and it's going to do what's known as a discovery.

It's going to say, hey, DHCP server,

I need to discover an IP address.

This means I need one to be assigned to me.

The DHCP server then says, okay,

does this address look okay to you?

And it offers up an address from the scope.

This is known as the offer phase.

Then the computer's going to say, yeah, I like that address.

I request to take it.

And that's the DHCP request phase,

which is going to be our third step in this process.

Finally, our DHCP server is going to acknowledge

that the IP is now being used by this client,

by sending what's known as an acknowledgment

and saying, okay, that's your address

and you can borrow it for this amount of time.

This is known as a DHCP lease.

Now, when we look at this in our home networks,

the default lease time is going to be about 24 hours usually.

For a corporate network though,

you may choose to use a longer lease time.

Something like seven days or 30 days,

depending on your use case.

In the world of cybersecurity,

having devices that are constantly changing their IPs,

makes it harder for us to track down when bad things happen.

So, in larger networks, we tend to use a longer lease time.

Now, how are you going to remember these four steps of DHCP?

Well, I have a little memory aid or mnemonic for this.

I like to think of "Dora The Explorer".

Dora is D-O-R-A,

and it's discover, offer, request, and acknowledge.

That is our four steps of configuring a device

on a network using DHCP.

Now, when the device gets a configuration

from our DHCP server,

it isn't just getting that IP address though.

Instead, it's going to get four key pieces of information.

This is the IP address, the subnet mask,

the default gateway,

which is the IP address of our router,

and the IP address of the DNS server

so your client knows how to do a DNS name lookup.

Once your client has these four pieces

of information configured, that client can now get online,

get out of your network, and get onto the internet

because it nows knows where it is on the network

with its IP address,

where the router is with that gateway address

and how to convert the domain names to IP addresses

using that DNS servers IP.

Now, I mentioned the fact that we use DHCP

to dynamically assign our configuration needed

for our devices to get online.

But we can also do this manually,

which is known as a static assignment.

You see, when we do it dynamically,

we let DHCP servers do the configuration for us,

but you can also statically assign the configuration

if you provide all four pieces of information

to your client device.

Now again, in most large networks,

you wouldn't want to statically assign the information,

but instead you're going to want to use

a DHCP reservation to do it.

But in your home network or a small network,

you may want to statically configure things.

Now, if you need a statically configure a device,

be sure you double check everything you've entered

for all four pieces of information.

The IP address, the subnet mask,

the default gateway, and the DNS servers IP.

If you're troubleshooting a device

that's having connectivity problems,

you should check if it was statically configured.

And if it was, you need to verify the IP address

and the subnet mask are configured correctly,

because this is often the source of your problems.

So, at this point,

we've talked about dynamic assignment and static assignment.

Now, when we use a dynamic assignment,

what happens if a device can't reach the DHCP server

or it fails to receive a proper configuration?

What should that device do?

Should it just keep asking?

Well, no, because then it's just going to sit there forever

getting hung up.

So, instead, we need to have an alternate configuration.

Whenever you're configuring DHCP,

if DHCP is not successful and it's not able to negotiate

its way through the door or process for whatever reason,

it's going to default to it's alternate configuration

that's set by the system administrator

inside the operating system.

By default, this is going to be set to use

what's known as an APIPA address, A-P-I-P-A,

which is Automatic Private IP Address.

Now, as a network administrator or a system administrator,

you can also configure your device to fall back

to a known good static IP address

as your alternate configuration instead if you prefer.

Now, when you're configuring your DHCP server,

one of the things you can configure is your scope options.

This allows you to configure a bunch of different things,

but the most common are the subnet mask

that is going to be applied to all the devices

requesting that configuration,

the default router or gateway that these devices should use,

and the DNS server to include the IP address configuration

for those devices,

as well as the least time for the IP address.

Now, as you can see, we've already discussed

all of these things in this lesson.

But I wanted to bring this up

so you're aware that you can change and configure them

as part of your scope options inside your DHCP server too.

Another unique configuration you need to make

for DHCP or network is the use of a DHCP relay.

Now, a DHCP relay is any host that forwards DHCP packets

between clients and servers.

Now, really the only time you're going to need a DHCP relay

is when the client device and the DHCP server

are not located on the same subnet or network.

In this case, instead of installing a DHCP server

on every subnet or mini network inside of your network,

you can configure one device to act as the DHCP relay,

and that way you can save yourself a lot of effort.

This device will listen for discovery requests

and then forward that request to the DHCP server

on the other network on behalf of your client,

acting essentially as a middleman.

Another unique thing about DHCP

is that it operates using the User Datagram Protocol or UDP.

For this reason, it is fire and forget method

of sending data.

To help the data get to where it needs to go,

you may need to configure

what's known as an IP helper address on your router.

The IP helper address is used to forward

several different kinds of UDP broadcasts

across the router and can be used in conjunction

with the DHCP relay that we just talked about.

Remember, if the DHCP client and server

are on different network segments,

the router and the client's network segment

has to be configured with an IP helper address

for DHCP to work properly and forward those requests over

to the DHCP server.

Hands-on with DHCP.

In this lesson, I'm going to show you DHCP

and how it works behind the scenes

by looking at the packets as they go across our network.

Now, when we look at DHCP here,

I'm going to do it in a very simplistic manner

and I'm going to use a small office home office

wireless router or wireless gateway.

You can see that here on the left side of the screen.

All right, so let's go ahead and get started here.

We have a wireless router at the top

and I've got two clients, PC0 and PC1.

Right now, PC0 is statically assigned

and PC1 is dynamically assigned.

You can see that if I click on them.

Here's PC1.

You can see it is set up for DHCP

and it's pulled an address of 192.168.0.1

as its default gateway

and if I look at its actual interface card,

you could see its IP address over here at 192.168.0.101.

Now if I look at PC0,

you're going to see on PC0 that I have

a statically assigned default gateway,

and that gateway doesn't match the DHCP one,

which is why I'm having some communication problems

with this one.

So I decided I'm just going to make my life easy

and set up DHCP.

So I'm going to click on DHCP

and it will automatically switch me to DHCP.

Now, once I click on DHCP,

I'm going to minimize this window and that way we can see it

as it steps through the DORA process.

So the first packet that's going to go out

is going to be a broadcast message for the discover process.

Notice here, the destination.

It is 255.255.255.255.

And this tells us that that is the broadcast

for layer three.

And so we're going to send this out

and everybody connected over layer three

is going to get this message.

In this case, the only have the person

that's connected over layer three is wireless router zero.

So when I do this and I hit the next button,

we're going to send that packet up.

It gets to wireless router zero.

When it gets there, it accepts that and it processes it.

It says, oh, somebody on this network

wants to get an IP address.

So this was the discovery phase.

Since this wireless router has a DHCP server,

it's going to say, great.

I can give you an IP address and I'm going to offer you one.

So it's going to send a packet back.

And when it sends that packet,

we are going to send that out as a broadcast.

So it goes to both PC0 and PC1.

In this case, PC0 accepted it and PC1 didn't.

Why didn't PC1 accept it?

Because it didn't ask for it.

It didn't do the discover process.

So it says, this isn't meant for me.

And it simply drops that packet.

Now, on the other hand, PC0 says

I was looking for a message.

And so this message came as a broadcast.

You could see the destination there is listed as broadcast.

Now because this was sent as a broadcast message,

it's coming over layer three at the broadcast.

So again, you could see the destination IP address

of 255.255.255.255.

So everyone on this network got a copy of that,

but only PC0 wanted it,

so it's the only one that's going to process that message

as indicated by those blue lines going over it.

So next, we're going to get that.

And we've discovered where we asked for it.

We received it as an offer.

So now we need to request it and say,

can I keep that address?

Now remember, we just send that out

to everybody in the network.

So maybe there was two or three clients

that wanted that address.

So whichever one requests it

is then going to get an acknowledgement from the server.

So PC0 is going to go back and say, I want this IP address.

And so it sends its request as part of the DORA process.

That goes up to wireless router zero.

When it gets it, it's going to see it.

And in this case, we are sending this as again,

a broadcast message because everything is being done

in broadcasting when you're using DHCP.

Now, once it gets up there and wireless router zero sees it,

it's going to process that message and say,

okay, I acknowledge that PC0 can have this.

And so it sends out another message to everybody,

and this goes to all the PCs.

And again, just like before, this is a broadcast message.

So if it wasn't intended for you,

you're just going to drop it.

This case, PC0 wanted it, so it accepts it

and we get that green check mark.

At this point, PC0 should now have an IP address.

So if we go into PC0 we should now see

that there is a DHCP address assigned.

Now notice we have a default gateway

of 192.168.0.1 that has been assigned

as a dynamic DHCP gateway for us.

Now, if we look at the wireless interface itself,

we will see its actual IP address.

In this case, 192.168.0.100

with a subnet mask of 255.255.255.0,

which means we are now on this network.

We have a valid IP and we can start to communicate

with other computers on this network

or out through that default gateway over to the internet,

if that wireless router is connected to a cable modem

or something else like that.

All right, that is the quick and dirty way

of how DHCP works through the DORA process.

Now, the other thing we might want to look at

is inside the wireless router itself.

Now I'm going to go ahead and maximize this

so you can see it a little better.

And over here on the front page, you see the DHCP server.

It is enabled here.

That's why this wireless router was entering up

and handing out IP addresses,

because it has a DHCP server enabled.

And you can see that the router has an IP address

of one 192.168.0.1.

This is the default gateway

and this router is acting as that default gateway.

We also see it subnet mask, 255.255.255.0.

That means that we have 256 total IPs,

one for the broadcast,

one for the network name and 254

that are reserved for clients.

Now, when it comes to handing out DHCP addresses,

where are we going to start that?

Well, here you can see the start IP address.

It's set at 192.168.0.100.

Now, the maximum number of users we're going to hand out is 50.

That means we're only going to hand out IP addresses

that start with 1920.168.0.100

all the way up to 192.168.0.149,

giving me 50 total clients that we can use.

Now, if you have a particular device that you want

to always get the same IP address,

like maybe a wireless printer or a laptop or a server,

you can do that using DHCP reservations.

In this device, you just click DHCP reservations

and here you'll see it's already been configured

so that there are two devices

that are getting IP addresses this way.

We have one set 192.168.0.101,

and we know which one that was.

That was PC1.

And then we have 192.168.0.100,

which was PC0, the one we just turned on

and went through the DORA process for.

This means that anytime I turn off that thing

and I put it at static and I come back to doing dynamic,

I'm always going to get the same address

because this is what I reserved for it.

Now, if I didn't care what address I had for this device,

I can go ahead and remove the mapping.

In the instance of a laptop,

I really don't care which IP it has,

but if I had a printer or a file server

or something like that,

I might want to have a DHCP reservation

so it doesn't change each time.

If you want to add something to this list,

you can just give it a name.

For instance, let's say I have a printer.

I'm going to say that is going to be 103

and I'm going to save the Mac address for that printer,

and nominally I'm just going to say it's 112233445566,

and then I'll hit add, and you'll see

that it is now being reserved.

Down here we have printer.

We have the IP address of 192.168.0.103

and the Mac address that I just assigned.

If I no longer want to have that reservation,

I simply go over and click remove.

Then, because this is a graphical user interface,

always click save settings so that your settings are saved

and it is applied to that router.

All right, hopefully you enjoyed that little demonstration

with DHCP and it helps you understand a little better

how the whole DORA process works with the DHCP server

and when you might want to use scopes and reservations

inside your DHCP setup.

DNS, Domain Name System.

In this lesson, we're going to talk about

the Domain Name System, or DNS.

The DNS protocol is used to help your network clients

find a website using human-readable host names

instead of numeric IP addresses.

For example, if I told you to visit my website,

I can simply say, "Hey, go over to diontraining.com,"

and that's a lot easier for you to remember

than having to remember it's 66.123.45.237,

or whatever the IP address of my web server happens to be.

After all, saying all those numbers

as part of a TV commercial,

isn't quite as catchy or memorable

as telling your consumer to visit diontraining.com,

or coca-cola.com or microsoft.com, right?

So, how does the computer know how to find

the web server's IP address

from these different domain names?

Well, that's the purpose of DNS, the Domain Name System.

The way DNS works is that the user's computer

gets told to go to someplace like diontraining.com.

And so, it reaches out to a DNS server and says,

"Hey, who is diontraining.com?"

And the DNS server is going to then reply back and say,

"Oh, I know diontraining.com.

Its IP addresses is 66 dot something,

dot something, dot something."

Then, the client gets redirected to a web server

using their router, and their way in connection

since they now know the right IP address

to use as their destination.

And all this happens in the background

for your users and your computer,

without anyone having to actually ask for it,

because DNS is such an embedded part

of our networks and systems.

Now, most of us as home users,

won't be running our own DNS servers,

but instead, we rely on our internet service providers

to do this for us.

But if you're running your own websites

or a large corporate network,

you might also have your own DNS server inside your network

and you'll be responsible for setting up

your own DNS records that dictate what servers are located

at what IP addresses and for what purposes.

This allows you to run your own domain name

and host resolution,

which will convert those domain names to IP addresses.

If you want to think of it like this,

it's similar to having a contact list on your phone.

Nowadays, how many phone numbers do you have memorized?

Probably not a whole lot of 'em, right?

Because normally you're going to pull out your smartphone,

scroll to the person's name and hit their name

with your finger and then the phone dials them up.

For example, if I want to call my wife, I scroll to her name,

I push a picture of her face on my phone

and then immediately my phone dials her number.

I don't have to memorize all 10 digits of her phone number

because my phone does it for me.

That's because as people,

we have a harder time remembering numbers than we do names.

And so we do this face or name

to number conversion using our contact list.

It's the same thing for computers

except computers actually like numbers

a lot better than names.

So we want to convert the domain names

that are easier for us into IP addresses

that are easier for computers to do their routing with.

And that's all DNS really does for us.

It converts names to numbers and numbers to names.

Now, one of the concepts with DNS that we need to talk about

is what's known as a fully qualified domain name or FQDN.

This is when a domain name is under a top-level provider.

For example, the most common top-level of provider is .com,

but we also have things like .mil, .edu, .org and .net.

Let's use the example of Dion Training.

At Dion Training, we have lots of different servers.

One of our servers is our web server

and it's located at www.diontraining.com.

Now the top-level domain here is .com.

The domain name that I use is Dion Training.

To be fully qualified, I have to add the www in front of it.

This makes it www.diontraining.com.

Now, if you want to go to my web server,

that's what you're going to type into your browser,

www.diontraining.com.

And now you're going to get redirected to my web server

because DNS knows how it should revolve the IP address

of my web server using that fully qualified domain name.

Now, if you wanted to go to my file server instead,

you're going to have to type in ftp.diontraining.com

because that's the server I'm running there.

If you want to go to my mail server,

you might type mail.diontraining.com.

All three of these are examples

of fully qualified domain names or FQDNs.

Essentially there's a service, a dot,

a domain name, a dot, and a top-level domain.

And this works the same way,

no matter which domain you're looking at

across the internet.

Now, DNS is going to be set up as a hierarchy.

This occurs at five different levels.

We have the root level, the top-level domain,

the second-level domains, subdomains, and the host.

The root level is the highest level

in the DNS hierarchy tree.

And the root name server is going to answer requests

in the root zone.

These servers contain the global list

of all the top-level domains, things like .com, .net,

.org, .mil and others.

The second level down is going to be the top-level domains.

These are broken up into two categories,

organizational hierarchies, such as .com, .net,

.org and others, and then the geographical hierarchy

such as .uk for the United kingdom, .fr for France,

.it for Italy and other countries like that.

The third level down is known as second-level domains.

These domains sit directly below the top-level domain.

For example, my domain, Dion Training

is a second-level domain under the .com top-level domain.

The .com sits underneath the root domain.

This is the way these things level up together

as part of the hierarchy.

The fourth level down is known as the subdomain.

So if I wanted to create a new server

underneath my second level domain of diontraining.com,

I can do that using a subdomain.

In my case, I have a lot of different subdomains

for different purposes.

I have my main website hosted at the www subdomain.

So you type in www.diontraining.com

and that takes you to my web server,

but I also have one called support.

Now, the support subdomain is located

at support.diontraining.com.

I have another one for mail, mail.diontraining.com.

These are all different subdomains.

Now, the fifth and final level down is the host level.

This is the lowest and the most detailed level

inside of the DNS hierarchy and refers to a specific machine

or server on the network.

Now, when we think of DNS, though,

most of us are just going to think of something

like a fully qualified domain name,

something like www.diontraining.com,

which contains a subdomain,

a second-level domain, and a top-level domain.

Now, if I wanted to take it a step further,

I can look at it from a URL perspective,

which is known as a Uniform Resource Locator.

Again, let's take my web server as our example here,

www.diontraining.com.

That's my fully qualified domain name,

but it doesn't tell you how to access it.

Do you want to do this securely or insecurely?

Well, you're going to have to tell that by doing the URL.

Well, if you want to give me your username and password,

you should do this securely.

So you're going to add the HTTPS colon slash slash

in front of www.diontraining.com.

And that becomes a URL, a Uniform Resource Locator,

because it tells you how to access

diontraining.com's web server.

That's why we have that HTTPS at the beginning.

It is the Hypertext Transfer Protocol Secure,

and that's the method of accessing it.

Now, if you wanted to access my website

and do it insecurely,

you could do that by adding HTTP colon slash slash

to be the beginning of the web address.

Now, if you want to connect using FTP,

you would use FTP colon slash slash,

ftp.diontraining.com as your URL.

And so there's lots of different ways to do this

as you tell the system what to do.

And that's the difference between a URL

and a fully qualified domain name.

Next, we need to talk about the different types

of DNS records that exist within a DNS server.

Inside your DNS server,

you're going to create different records

that hold different types of information

based on your use case.

These are known as A records,

AAAA records, CNAME records,

MX records, SOA records, PTR records, TXT records,

SRV records, and NS records.

Let's take a quick look

at each of these different record types.

First, we have an A record

which stands for an Address record,

and A record is used to link a host name

to an IPv4 address.

For example, there's an A record for www.diontraining.com

and it links it to the IP address of 45.79.184.180.

In addition to this, you may also set

an A record for the at host

and this indicates a record for the root domain.

In the example of Dion Training

are at record signifies the diontraining.com,

which is the root of our domain is going to be listed

at a certain IP.

This way, our users can find our website

by going the subdomain of www.diontraining.com

or just by going to diontraining.com

by using that A at record.

Now, A records only work for IPv4 addresses,

but a lot of modern websites are also supporting IPv6.

To map a domain name to an IPv6 address,

you're going to use an AAAA record.

So using the Dion Training site as the example,

I could set the AAAA record to 2400:cb00:2049:1::a29f:1804

if that was the IPv6 address for my web server.

As you could see, IPv6 addresses are a lot more complicated

than IPv4 and really hard for us humans to memorize,

which is why we like to use these AAAA records

or the four A records.

The next type of record we can use

is known as a CNAME record, or Canonical Name record.

Now a CNAME record is used

instead of an A record or an AAAA record

if you want to point a domain to another domain name

or a subdomain name.

For example, I own a lot of different domain names

out there in addition to diontraining.com.

Some of these are for former companies I've had

or projects I used to run,

and some are ones I plan to use someday in the future.

But in the meantime, I have them set with a CNAME record

that resolves back to diontraining.com.

For example, I used to run a website called itil4exam.com,

but I've since stopped using that domain name

and I've merged all those courses

into my own diontraining.com website.

So when I shut down that old web server,

I still want to do allow people to type an itil4exam.com

and reach something instead of just an error page.

So I use the CNAME record

to point it directly to diontraining.com.

Now, why would I want to do that?

Well, we were in the other site for a few years

in parallel to diontraining.com

and many of the links posted there are all over the internet

with recommendations to our courses that were hosted

on that itil4exam.com website.

One of our most popular courses from that site

was our ITIL 4 Foundation course,

and it was located itil4exam.com/itil-4-foundation.

Now, if you type that into your web browser,

it will resolve the itil4exam.com part

to diontraining.com and take you directly

to diontraining.com/itil-4-foundation.

This means that even if you're using a link

that you found on Reddit that recommended our course

from a few years ago, it's still going to work

and take you to our sales page,

even though the original itil4exam.com server

no longer is even in service and has been taken offline.

Another use case for using a CNAME record

is when you're using a software as a service offering

that provides you with a subdomain on their server.

For example, I use a service desk ticket tracking software

known as Freshdesk, which it comes at freshdesk.com

and they gave us a rather difficult to remember

subdomain for their service,

something like fdus-143-d15.freshdesk.com.

So to make it easier for my staff to find our support desk,

we create a CNAME record called Support,

and we pointed that to this difficult to remember subdomain.

So if my staff enter support.diontraining.com,

it takes them right to our support system,

which is actually redirecting us into this cloud instance,

that's provided by the subdomain issued by Freshdesk.

Remember, CNAME records cannot be used

to point to an IP address.

It can only be used to point to another domain name

or subdomain name.

Next, we have an MX record,

which stands for mail exchange record,

and it does what you think it would.

It helps you figure out where an email server is.

An MX record is used to direct emails to your mail server.

The MX record is going to be used to indicate

how email messages should be routed when they're using

the SMTP or Simple Mail Transfer Protocol over port 25.

MX records like CNAME records can only be used

to point to another domain and not an IP address.

When you create your MX records,

you're also going to be able to provide the priority

for each of these records.

This lets you indicate your preference for which server

the email should try to use first.

When it comes to setting the priority,

the lower the number you enter,

the higher the priority it is.

It's essentially golf rules.

So if we have mail1.diontraining.com set at 10

and mail2.diontraining.com set at 20 for their priorities,

the emails are going to attempt to use mail one first.

If it fails to reach mail one,

then it will try to reach mail two.

Now, if you want to load balance your email

across multiple servers,

you simply need to set their priorities to the same value.

So if I created records for mail one and mail two,

and they both had a priority of 10,

all incoming emails are going to alternate

and load balanced equally between these servers.

The first one goes to one.

The second one goes to two. The third one goes to one.

The fourth one goes to two, and so on.

Next, we have an SOA record,

which stands for Start of Authority.

Now, a Start of Authority record is used

to store important information about a domain or a zone.

This information can include things

like when the domain was last updated,

the email address of the administrator of the domain,

or even how long the server should wait

prior to sending an update for all

of its DNS records to other zones.

These Start of Authority records are critically important

whenever a DNS server is attempting

to conduct a zone transfer.

Now, you may be wondering what is a zone transfer?

Well, a DNS zone transfer is simply the process

of sending your DNS records from the primary name server

to a secondary name server.

When this occurs, the first record that's transferred over

is the SOA record, that Start of Authority.

And this is used by the secondary server

to see if the other records need to be updated

because the Start of Authority record

contains a serial number that acts as a type of versioning.

When a zone transfer occurs,

this is going to use the TCP protocol to do the data transfer.

This ensures the data's going to be sent over successfully

from the primary server to the secondary server

and verify it has been received there.

Next, we have a PTR record or a Pointer record.

Now, a Pointer record is used to correlate

an IP address with a domain name.

Essentially a Pointer record is the opposite of an A record.

These Pointer records are used to conduct what is known

as a reverse DNS lookup.

So if a user is trying to determine if a domain name

is going to be used for a given IP,

that query can be made against the Pointer records

instead of the A records.

This lets you go from an IP address to a domain name.

Now, you may be wondering why do I even need

a Pointer record if I already have an A record?

Well, honestly, you don't always need them,

but they can be helpful if you're trying to prove

your domain is not associated with spam,

if you're trying to troubleshoot an email delivery issue,

or if you're trying to help create

a better logging environment by converting your IP addresses

back into domain names.

Also, when you store an IP address in a Pointer record,

it's going to be reversed and in-addr.arpa

is added to it at the end.

For example, if your IP was 66.55.44.33,

and you're storing it in a Pointer record,

it's actually going to be stored as 33.44.55.66.in-addr.arpa.

Now, you might be wondering

why is the top-level domain .arpa being used here,

and what the heck does that mean?

Well, the internet started out as the ARPANET,

which stands for the Advanced Research

Projects Agency Network.

This was the first wide area packet switch network,

and it was developed by the US military

to connect a bunch of military defense researchers

at universities located all over America.

Now, the ARPA top-level domain was actually created

as the first top-level domain that was defined

for what would become the internet later on and as such,

it was used for managing network infrastructure.

This is why you see the .arpa as the top-level domain

use by all Pointer records.

It's just a relic of history and it's still there

because we built the internet on top of ARPANET.

For the exam, you don't need to know about ARPA

or this internet history that I just talked about.

It's just something that I have a lot of students

ask me about, why do Pointer records end .arpa?

And that's the reason.

So when you conduct this type of lookup,

you're trying to determine the host name

based on a given IP.

And this process is known as reverse DNS

or a reverse lookup.

Normally, when you use DNS, you do a forward lookup,

which goes from a domain name to an IP address.

Instead we're going from an IP address to a domain name

and that's a reverse lookup.

Next, we have TXT records or text records.

Now, a text record is used by domain administrators

to add texts into the Domain Name System or DNS.

Originally, text records were designed

as a way for us to add human-readable notes

into our DNS records and over time,

these things had more and more things

starting to get added to these text records.

And eventually, we started adding machine-readable data

into these text records as well.

And that's what you're going to see mostly these days.

Your domain can have a lot of different text records

as well, you're not limited to just one of them.

Most of the time, you're going to see text records

used to prove domain ownership through adding

some machine-readable code for verification

and to provide email spam prevention

again, by adding specific machine readable code

to a TXT record.

For example, at diontraining.com,

we have a text record with the name fdkey.support

and a text string of 32 hexadecimal digits

inside of our DNS records.

This allows our support system Freshdesk to verify

that we own the domain name, diontraining.com.

So they're authorized to send out emails on our behalf

to our students when our team replies

inside their system to a support ticket.

This is a form of domain ownership verification,

because their system can query our DNS records

and see that we entered this unique series

of 32 hexadecimal digits into our DNS TXT record.

Essentially, it's working like a password to say,

"Hey, I own this domain."

Next, let's talk about SRV records or Service records.

Now, a Service record is used to specify a host and a port

for a specific service such as voiceover IP,

instant messaging or other services like that.

Remember, we normally use an A record or an AAAA record

when we're just associating a domain name

with an IP address, either with IPv4 for an A record

or IPv6 with an AAAA record.

Now, we can use a CNAME record if we want to associate

a domain name with a subdomain or another domain name,

but none of these allowed us to specify a port,

but with a Service record,

we can specify a port along with our IP address.

For example, if I wanted to run an XMPP chat server

and link it to port 5223,

I could do that with a Service record that looks like this,

_xmpp._tcp.diontraining.com. Space 86400 space IN space SRV

space 10 space 5 space 5223 space chat.diontraining.com.

Whew! That's a mouthful.

Now, that is a single SRV record in a DNS server.

This would say that I'm using the XMPP service

with the TCP protocol.

The time to live for the record is going to be updated

every 86,400 seconds, which is 24 hours.

The class is set to IN, which stands for Internet

and it's an SRV or Service record.

The priority is 10 and the weight is five.

These two settings are used for prioritization

and load balancing across multiple servers.

Finally, we see the port number 5223,

and the target server of chat.diontraining.com.

This is the port and server we're mapping

the XMPP service to within this particular Service record.

Finally, we have an NS record

which stands for name server record.

Now, a name server record is used to indicate

which DNS name server in the world

is going be the authoritative one for that domain.

This is important because DNS uses that hierarchal model

we talked about and all the servers need to know

who owns that record and is authorized

to make the changes to it.

Now, a name server is a type of DNS server

that stores all the DNS records for a given domain,

including all the types we've already discussed,

like A record, AAAA records, Canonical Name records,

MX, mail exchange records, TXT, text records,

PTR, Pointer records, and SRV, Service records.

There are often more than one name server

for domain as well, so you can have a primary

and a backup name server.

Additionally, you don't always have to host

your own name servers.

In the case of diontraining.com,

we don't host our own name servers,

instead we rely on Cloudflare,

which is a cloud service provider that does this for us.

So if you look up the DNS records for diontraining.com,

the authoritative source for that

is to of Cloudflare's name servers.

Now, up to this point, I've talked about DNS

from a perspective of hosting a publicly available

DNS server that anyone in the world can access,

but DNS can actually be used internally or externally.

Everything I've talked about so far

is talking about externally.

But let's talk a little bit about internally.

These days with cloud computing,

it is very common to set up an internal DNS servers as well,

that lets your cloud instances within the same network

or private cloud access each other using internal DNS names,

instead of having to use their IP addresses.

To do this internal A records are created,

an internal Pointer records are also created

in the reverse zone.

Luckily, most cloud providers will automatically create,

update, and remove these internal DNS records for you

as you create and remove different virtual machines

and other instances in your private cloud.

External DNS is what most of us

are going to be more familiar with though.

These are the records that are created around

the domain names that we purchase from a central authority

and that we use on the public internet.

Now, for each DNS record,

we also have what's known as a TTL or time to live

that's associated with it.

Now, inside of each of our DNS records,

whether internal or external, we're going to create

what's known as a TTL or time to live

that's associated with it.

The time to live is a setting that tells the DNS resolver

how long it can cache a query before requesting a new one.

So if my DNS records are set with a time to live

of 86,400 seconds, which is usually the default,

that means my computer will resolve that DNS record

and it will remember it for 24 hours

before it has to go back out to the DNS server

and ask for that information again.

This DNS resolver also known as a DNS cache

is located on your individual hosts.

So if you're running windows 10, for example,

your computer is making a local copy of every DNS entry

it resolves as you connect to websites

all over the internet.

This temporary database remembers the answers

that received from the DNS server.

So if you go to diontraining.com,

the first time you do that today,

your computer has to ask the DNS server for that IP address,

but now it knows where it is,

and it remembers that IP for the next 24 hours.

If you visit my website five times today,

you only had to look up that IP address once.

This helps speed up the entire process for us.

Now, if you try again tomorrow,

your computer's going to first check it's DNS cache,

and it's going to see there's a record there.

But if that time to live is already passed,

it's going to invalidate that record

and perform another lookup.

The final thing we need to cover

is the concept of a recursive lookup.

You see, when your computer wants to find a given website

like diontraining.com,

it first has to ask its DNS server where it's located.

So if you're sitting at home

and using a Verizon Fios connection, for example,

you're going to ask their DNS server, who's diontraining.com?

Now, Verizon's DNS may or may not know the IP address

for diontraining.com.

After all, there are millions and millions

of websites out there.

If they had to rethink our records every 24 hours,

that would take a long time.

So instead DNS uses this recursive strategy

to perform the lookup.

So you ask Verizon, and if they don't know the answer,

they're going to go up a level and ask the next DNS server.

If that server doesn't know the answer,

it will go up another level

and we'll keep this process going until it finds somebody

who knows the IP address of diontraining.com.

Now, if during this recursion,

it reaches all the way up to the .com or the root domain

for diontraining.com, then it can ask the .com root server,

which DNS server is authoritative for diontraining.com

and get the authoritative answer directly from them.

Essentially with a recursive lookup,

your DNS resolver saying,

"I don't know what this domain's IP is,

but I'm going to ask my DNS server

and that server will hunt it down until it finds it.

And then tell me that IP."

Now, there's another method that can be used,

which is known as an iterative lookup.

With an iterative lookup, it's similar to recursive lookup,

except that the DNS server is not going to continue

to look up the information for you and send you the result

instead in an iterative lookup,

your DNS resolver is going to ask the DNS server

what the IP for the domain is.

And if the DNS server doesn't know,

it's going to tell your resolver to ask the next DNS server,

and that server will provide its IP.

Now, with the recursive lookup,

the DNS server would hunt it down

and report back to resolver.

But with an iterative lookup,

your DNS resolver is going to continually doing this query

all the way up through this recursion

until it finds the one with the IP for that domain.

So it really is just a matter of who's doing

the hunting for this information.

All right.

We have covered a lot of information in this lesson.

So as a quick summary,

what do you need to know for the exam?

Well, you need to understand how DNS works

by using its various record types to convert domain names

to IP addresses and IP addresses to domain names.

You should remember that A records

are used for domain names and IPv4 addresses,

while AAAA records are used for domain names

with IPv6 addresses.

CNAME records are used to map domain names

to other domain names.

MX records are used for email

and NS records are used for name servers,

TXT records store texts, either as human-readable

or machine-readable data.

Pointer records are used to match up an IP address

with a domain name for reverse DNS lookups

and Service records are used to map both a port and an IP

to a domain name for a service.

If you remember that summary, you should be able to answer

pretty much most of the DNS questions

you're going to see on the exam.

Hands-on with DNS.

In this video, I'm going to take you a little bit

inside of the network and we're going to use a tool

called packet tracer from Cisco

so we can actually watch the packets

and then see exactly what's going to happen

as packets go across the network

when we do our DNS resolution

to be able to pull up a website.

When we go in the environment,

you can see on my left side, I have a sample network.

I have a client and I have a local DNS server,

both attached to switch zero,

then those attached to that company's router.

That company's router has a serial connection,

indicated in red, that's connecting to an internet router.

And this would usually be shown as a big cloud

with a lot of different routers and switches

in the real world, because the internet's a big place.

But in this case, I'm just going to use one router

so I can use that as my sample internet.

In that internet router or in that internet cloud,

if you will, there's also a DNS server there.

This is the root DNS server.

So you can think about something like the .com domain

or the .net domain.

That's what we're talking about here.

Now off to the right, you'll see

there's the Dion Training router.

Now this is our border gateway router

that's connected to the internet.

So when your company tries to access our company,

it goes over the internet and goes

from your company's router

through a bunch of internet routers

and eventually to the Dion Training router.

Now the Dion Training router is then connected

to our internal switch, known as switch one,

and that has two devices hanging off of it that you can see.

One is at the bottom of the screen,

called authority.diontraining.com.

This is our internal DNS server.

And then up top, you have server.diontraining.com,

which is acting as a web server in this example.

All right, the first thing I want to show you

is that all of these DNS servers right now

have empty caches because I haven't done anything

and it's a brand new network.

So if I click in here and go to services,

you can see under DNS that I have a couple of records here

and under my cache it is completely empty.

If it had something in there,

I could clear the cache from here.

Next, we're going to look at the root DNS server,

and I'm going to look at its DNS cache as well

and see that it is also clear.

Finally, I want to look

at the Dion Training authority DNS server.

And I'm going to look at that and see again that it's clear.

All right, so what happens when you, as a client,

want to go to Diontraining.com?

Well, you're going to go onto your client

and you are going to end up hitting desktop

and go to your web browser.

Just like you would at home, you'd open up

Google Chrome or Safari or something like that.

And we're just going to type in what we want to go to,

in this case, Diontraining.com, and then hit go.

Now, because this is a packet tracer

I'm going to step-by-step through each and every packet

as it moves across the network.

You can see when I hit go, two packets showed up,

one with that brownish color and one with the green.

So what I'm going to do is I'm going to minimize

the client right now because it's going to take

a lot of packets going back and forth

before we actually see anything in this web browser.

And I want you to see what I have on the right side

of the screen.

This is a list of all of the different clients

and the different packets going back and forth.

So at time 0.0 you can see there was no last device,

but the first device here is it is at the client.

So it created these new packets.

We have a DNS packet and an ARP packet.

Now why does this happen?

Well, when the client wants to look up something

through DNS, what does it do?

It first checks it's internal DNS cache.

And here we can see that this one has no internal DNS cache,

but we do have a DNS server

of 10.0.0.3 that we want to go to.

Now, our default gateway is 10.0.0.1

and this particular client,

it has an IP address of 10.0.0.2.

So when it says I want to go to Diontraining.com,

it's first going to say, hey, I need to look this up in DNS.

So I'm going to go to my DNS server,

which is shown here as 10.0.0.3,

which is this DNS server down at the bottom of the diagram.

And you can see here, it's on fast ethernet zero,

it's link is up and it's 10.0.0.3/24,

which is this particular DNS server.

But my client doesn't know where that is yet

because it only talks to things using Mac addresses.

And since I've never talked to the DNS server before

'cause this is a brand new network or just created

it doesn't know where to go.

So it's going to send out an ARP packet

and that's why you see that green ARP packet.

Now, as you can expect,

that ARP packet is going to go from the Mac address

of my client and it's going to go to FF FF FF FF FF FF,

which is the broadcast at layer two.

So when that packet goes to the switch,

which we're going to see here in a second,

what is the switch going to do?

It's going to broadcast it out to everybody.

So we see that art packet going from the client

to the switch.

Once it gets to the switch, the switch is going to look at it

and it's going to say, do I know who FF FF FF FF FF FF is?

In this case, they do.

It knows that it goes to the broadcast.

So it's going to send out every other switch port it has.

In this case, it's going to go to the company router

and the local DNS server.

They're going to receive that.

And inside that art packet, they're going to see,

hey, is this for me?

So if I look at this art packet,

you can see the inside of it is asking,

do you know where the 10.0.0.3 address is?

And it's going to say, yes, I do.

I'm that guy.

And so local DNS is going to answer up

back to the switch and say,

I'm the device you're looking for.

Now on the company router side, it's going to look at that

and go, you're looking for 10.0.0.3.

That's not me.

I'm a router and I host the 10.0.0.0/24 network,

but that means I don't need to take this traffic

and pass it outward because in my network.

So I'm just going to drop this packet

because it's not really meant for me.

All right, once we do that,

we're going to go to the next packet that happens.

This time, the DNS server is going to send the message back

to the switch and say, yes, I'm the guy you're looking for.

I am 10.0.0.3.

And the switch says, okay,

let me tell that back to the client.

So the client now knows what the Mac address is

for that local DNS server,

because it reports it inside of that ARP message.

Now the client, when it receives that goes,

great, now I know who to send my DNS traffic to.

So I'm going to create a new DNS message,

which you can see here in brown,

and I'm going to send that back to the switch

and the switch is going to send it to the DNS server,

because it knows that Mac address

was addressed from the client to the DNS server.

At this point, the DNS server looks at it

and it has to see what do I do with this message?

So the first thing we're going to do

when we look at that message is we have to check

our own DNS records.

So as the DNS server, when I see that

I'm going to say, do I know what to do with Diontraining.com?

So I check my DNS records and here they are.

I have two records.

I have one for com and one for root.

Now the com one is a name server for the .com domain.

And it says, if you get something that ends in com,

go to the route server here on the right.

Well, that then looks in the record, says,

okay, where is the root server?

I have an A record for that and it's 10.2.0.2.

So where is that device?

Well, it's not on this network

because that's a different local area network.

So I'm going to have to send this message to my gateway,

which is the company router,

which will then forward it out

to the appropriate network where 10.2.0.2 is.

Now 10.2.0.2 in this example

is simulating the top level domain for.com

because we don't own this name

and we don't know where it goes.

So we're going to go to .com and ask them

for the authoritative name server for it.

Alright, 10.2.0.2 is actually going to be

this root DNS server right here.

And you can see right here, it is 10.2.0.2/24,

and it is up and available.

So we want to get that message over to this server

and then we're going to check our DNS records on this server.

So you're going to watch that brown packet,

and it's going to go up to the switch.

And the switch is then going to send an ARP message

out to the company and out to the client,

because again, nobody knows where 10.2.0.2 is yet.

Now when it gets to the client,

the client says that's not me and drops the message.

The router on the other hand says, hey,

I know how to get to 10.2.0.2.

So I'll answer up for that and say any local area traffic

that's destined for that address comes to me

and then I'll forward it using layer three IP addresses

out to the internet to get it over there.

So it's going to send that message back to the switch

and the switch sees it, and then it sends it back

to the local DNS server.

The local DNS server says, great,

now I know how to get there.

I'm going to send all those requests for 10.2.0.2

over to the company router, which is my default gateway.

So that's what's going to happen.

We see that go up.

We see it hit the switch,

and then it goes from the switch over to the company.

Now, once it gets to the company router,

we need to get that over to the 10.2.0.2 device.

So it's going to look at it and say, not part of my network.

Let me send it out my default gateway to the internet.

So it does that and sends it over to the ISP's router.

The ISP's looks at and goes,

Hmm, where is this thing located?

And in this case, we have it

directly attached to that router.

So it's going to drop that DNS packet

and it's going to change it into an ARP packet,

'cause again, we always send things to the final device

using layer two, using ethernet,

and that's going to require a Mac address.

And so we have to use our ARP

to do the IP and Mac address binding.

So the internet routers then can go down to the DNS server.

When it hits there the DNS server says,

oh, I know what that is.

That's me, I'm 10.2.0.2.

So it sends that message back to the internet router

and the internet router is going to send that message

back over to the company, and in turn,

they're going to say, okay, I know how to get there.

Now at this point, the local DNS server

hasn't gotten its message over to that final server yet.

And it's going to then send it again to the company.

So in this case, it sends it up to the switch zero,

from switch zero to company, and now at this point,

the company router knows what to do with it.

It sends it over to the internet router

and the internet router knows what to do with it as well.

It's going to send it down to the root DNS server.

So we're now going to look at that message, which says,

hey, where is this address for www.Diontraining.com

or Diontraining.com, like we entered in the browser.

Now we're going to look at our DNS records on this server

and see if we have one for it.

So as we go here and we look at our DNS records,

we can see there's nothing in its cache.

And we see three records.

First we have an SOA record, or a start of authority.

Now the start of authority record

is going to have these things about it,

like saying, when does it expire, when does it refresh,

when do you want to retry, what's the minimum time to live

and all those details.

Now this authority record says who owns the authority name.

Now the next one we have is authority.diontraining.com.

And we have an A record associated with that,

which says this address of authority.diontraining.com

goes to 10.4.0.2.

That is not the same as diontraining.com.

It's not the same as www.diontraining.com.

This is a sub domain called authority.

And so authority.diontraining.com

would be at that server's IP.

Now, if we go to the last thing,

we do see that there's Diontraining.com there,

and this is actually a name server record.

So who owns all of the Diontraining.com name server records?

Well, it's owned by what we see on the right,

which is authority.diontraining.com.

So if somebody wants to look up beta.diontraining.com,

wwww.diontraining.com, support.diontraining.com,

they're going to go from this record to that name server

at diontraining.com, which is located

at the authority.diontraining.com

or 10.4.0.2.

So let's look and see, where is 10.4.0.2 on this diagram?

Well, here it is.

It's authority.diontraining.com,

and you can see it's 10.4.0.2.

So again, this root DNS server is now going to send the traffic

over there and to do that,

it's going to have to do that at layer three.

So first we're going to have to go

through the ARP process again,

because we just found a new IP address

that nobody knew of before

and we have to figure out where it's going to be located.

So up we go with the DNS to the internet router,

and then that's going to get sent over to the next router,

which is Diontraining.com.

Now, once it's there, it's now going to have to get delivered

that final leg to that server.

And this is where we have to again use ARP.

So the router is going to drop that message

because it doesn't know what to do with it,

and instead it's going to start sending out

the ARP broadcast again.

So out goes the broadcast to the switch,

the switch then broadcasts it up.

And it goes to server.Diontraining.com,

which is my web server and authority.diontraining.com,

which is my name server.

Now in this case, we were looking for 10.4.0.2,

which happened to be the authority.diontraining.com server,

so server.diontraining.com is going to drop that ARP packet

and not respond to it because it's not meant for them.

Instead, the DNS server is going to respond

back to the switch and say, I'm who you're looking for.

And the switch is going to send that back to the router

at Dion Training.

Now the Dion Training router knows

where the authority.Diontraining.com server is,

and it knows how to address it using its Mac address

because we just did this ARP broadcast.

So the next time we get the retransmit of that DNS request,

it's going to go and it's going to come

from the client to the switch.

The switch says, I know what to do with that.

I'm going to send it over to the DNS server

because I always use my local DNS server first.

Now my local DNS server is going to check its cache.

Again, do we have anything in our cache yet?

Let's take a look.

Right now we don't, because we never got a message

back to this server yet

to know where the final destination is.

So what is it going to do?

If it's not my cache, I'm going to send it

to the next higher DNS server,

which happens to be the root DNS server.

So off it goes.

It transfers it up to the switch,

over to the company router.

That's going to say and take it over to the internet.

The internet's going to deliver it down to the root DNS server.

So the root DNS server is now I'm going to send that message

up to the internet router.

The internet router is going to send it over to Dion Training

and then Dion Training is going to send it over to the switch.

The switch knows where to send it now

because of that ARP broadcast we just did.

And so it's going to send it down

to the authority.diontraining.com.

Everything we did so far was just to establish

that initial connection and get that first DNS request

over to the name server,

who is the authority for this Diontraining.com name.

So now that we're there, what is this server going to do?

It's going to take it,

and it looks at the request and the request said,

I want to know where Diontraining.com is.

So it's going to check its DNS records,

and in its DNS records, does it have an A record

for Diontraining.com or a C name record

for Diontraining.com?

Well, yes it does.

You can see that record number two is Diontraining.com

and it's an A record that points to 10.4.0.3.

Now that same IP address is also going to be used

for server.Diontraining.com.

And there's an A record for that.

And then finally, you see a C name record at the end,

which says www.Diontraining.com,

and that is going to be pointing to server.Diontraining.com.

So if I went in my web browser and asked

for www.Diontraining.com,

it's going to use the C name record

and point me to server.Diontraining.com,

which points me to this A record,

which points me to this IP address.

And you can see how these things linked together,

but when I typed it in,

I just typed in directly Diontraining.com.

So I'm only going to be looking at record number two here,

which is the A record with the IP address we want to go to.

So the question is where is 10.4.0.3?

Well, if we look at that,

it's up here and it's server.Diontraining.com.

So now what we want to happen

is once the client finds out where the server is located,

it's going to start sending all this traffic

to the IP address of server.diontraining.com.

And we're going to go from the client to the switch

across the network, to the other switch,

and then up to server.Diontraining.com.

So let's see what happens as this DNS message goes back.

So it's going to go back to the switch.

It's going to give the reply and say,

here's the IP address you were looking for.

Then it's going to go over to the Dion Training router.

From the Dion Training router it's going to go

back to the internet router,

and now it's going to send it back to the root DNS server,

because we want them, that lower level server,

to know where is Diontraining.com

so if anybody else asks in the future,

they can just tell them where it is

using that .com domain name

instead of having to go all the way back

to my individual DNS server.

So when I do this, you're going to see

that we're going to actually get a cache

happening inside this root DNS server.

So there we go.

Now we've got the root DNS server and it knows where it is.

So if I go to services and look at my DNS cache,

you're going to see that it now knows that there's an A record

for Diontraining.com at this timestamp,

and it's going to be going to 10.4.0.3.

Now, depending on the time to live for this DNS record,

it's going to stay in this cache.

And then once that cash is going to expire,

it's going to go back and ask again directly from the server

instead of using its cache in the future.

All right, once we have that,

you can see though it did not add that as an A record

in its DNS.

The reason for this is that this A record

is not owned by this root server.

It's owned by the authoritative name server,

authority.Diontraining.com

over on the right side of our screen.

So it only can cache it.

It can't add the A record automatically.

All right, once it gets that we still need to go

and tell the lower level DNS server what's going on.

So it's now going to send a message

up to the internet router, over to the company router,

which sends it over to the switch.

The switch knows where it needs to go.

So it sends it down to the local DNS server.

And now if we check the local DNS server,

we're going to see that its cache

now has that same A record in it.

And so, again, we didn't add it as an A record here.

We added it as a cache,

and you can see now that we now have the cache name

for the name server on the way over,

and now we have the cash name for the IP address

for Diontraining.com.

So at this point our local DNS server

can now interrupt for anybody

who's asking where Diontraining.com is,

and we don't have to go through all those packets

we just did to get that information again,

because we already have it.

Now once the time to expire happens,

we're going to have to have that cache invalidated

and it happens automatically.

So then we would have to go all the way back to the server

and get a new copy because maybe I changed my IP address

or move that server.

All right, so now that the DNS server has it,

it can answer that back to the original requester,

which was our client.

So now our client knows where to go.

So now the client can actually start sending traffic

and we want to send on HTTP traffic

because that's what we were trying to do by going to a website.

Now first, you're seeing this ARP again.

This ARP is going to the switch,

and then that's going over to the company

and the DNS server, because we now know

what the IP address we want to go to is.

And that IP address was the IP address

for server.Diontraining.com.

But our switch doesn't know that

and our router doesn't know that.

So we again have to ARP to say, hey,

what is the Mac address for this IP address?

Both these things are going to get it.

And both of them are going to say, it's not me.

The company router on the other hand is going to say,

it's not me, but I know where to send it

so you can send that to me

and I'll send it out my default gateway.

So that's what's going to happen.

We get that ARP request going back to the switch.

The switch now knows anytime somebody's asking

for that server.Diontraining.com IP

that we were talking about,

it's going to go over to the company router

because that is considered the default gateway.

All right, now that we see that,

what's the next thing that's going to happen?

Well, the Dion Training router is also going to be doing

an ARP request on its side of the connection,

because it needs to know how to do that final delivery

to that server.

So it's doing an ARP broadcast.

It goes out to the switch,

the switch sends it to both the servers.

And then the one that it is,

is going to respond back to the switch,

in this case, server.Diontraining.com.

Now, as we do that,

the switch now gets that message

and it sends it back to Dion Training using ARP

to say, hey, I know where to send messages

for the server.Diontraining.com,

so go ahead and send it to me as a switch

and I'll deliver it on the local area network.

All right, so now that we did all of that,

our client knows where to go.

It's going to go to its local DNS server

for that address resolution.

Now that it knows the IP name,

anytime it wants to do things

to go to the server.Diontraining.com or Diontraining.com,

it can do that using the IP,

using its local cache on the client.

If it's client has expired on that cache,

it can then go to its local DNS server.

If the local DNS server is expired,

it's going to go back to the root server.

If the root server is expired,

it's going to go all the way back

to the authority.Diontraining.com name server

and we do this whole process again.

All right, so now I want to go ahead

and look at my browser and make sure

we can get traffic going back and forth

now that we've done the DNS part of this.

So I'm going to go to Diontraining.com and I'm going to hit go

and off it goes with the message.

And there we go: DNS, DNS.

We're going to go all through that process again

so you can see what it looks like,

going through, getting to the root DNS server,

back to the router, back over to Dion Training's router,

back to the switch, down to the authority.DNS

and up to the server.DNS.

It drops it at the server

because there's no DNS record there.

And then the authority one sends back its message

and says, here is what we have.

And so when it does that it goes back through

to one router, to the second router,

to the root DNS, back to the internet router,

over to the company router, over to the company switch

and then down to the local DNS server.

And then that goes all the way back up to our client.

All right, that is the DNS process

as we're looking at using hierarchies

and going from our local to our root DNS

and then over to our authoritative name servers.

So at this point, we want to send out a request

back to that HTTP server, which is holding Diontraining.com.

And at this point, we will be able to send our get message

using HTTP and we'll receive the webpage back.

So we create our packet.

We address it with the Mac address of our default gateway.

And that way our company router will send it out

to the Dion Training router across the internet.

So here we go.

We're going to send that HTTP traffic.

It goes over to switch zero.

From switch zero is going to send it to the company router.

The company routers is going to then readdress it,

using the IP address that we want to go to,

which happens to be the IP address

for server.Diontraining.com.

And it sends it out to the internet.

The internet then says, where does this belong?

Finds the right network as it passes it

from router to router and eventually getting

to the Dion Training router,

which hosts the network for server.Diontraining.com.

Once it gets to that router,

it's going to strip it down to layer two

and start using ethernet as it goes to the switch

and using Mac addresses.

So it does the IP to Mac address conversion using ARP.

Once it does that, it hits the switch.

The switch knows where it goes and sends it

up to the server.

Notice it only went from the client to the server.

It never touched those DNS servers again,

'cause we already did the DNS part.

We know what the IP address is.

Now, once it gets to the server,

the server is going to process that message.

In this case, it was a get message saying

give me the website.

And so it's going to send back the website

in a series of packets.

In this case, it's only one packet

because it's a very small website I'm sending

and it goes back across the internet to the company,

over to the switch and then up to our client.

Now, once I do that,

we can go and look at what page it was that we received.

This would happen all in the background

and you'd see it on your web browser.

And there it is.

So in this case, I have server.Diontraining.com,

also known as www.Diontraining.com.

And this is used to simulate the Dion Training homepage

within my lab environment.

Now, if I actually put pictures on there

and things like that,

it would make this a much bigger website

and it would be a lot of different packets

and this purple packet going back and forth

would just keep on happening.

I would send the one packet over and say,

give me the website.

And then I would get a whole series of packets back

from the web server,

with the videos and images and texts that I need

to build that website at layer seven,

the presentation layer on my client.

And that's how you get to see the webpage

once you go to something like Diontraining.com.

Hopefully this explanation helped you understand

a little bit more about how DNS works in the background

and how these things layer upon each other

from the local to the top level domain

and to the authoritative servers.

NTP, the Network Time Protocol.

In this lesson, we're going to talk all about NTP,

the Network Time Protocol.

NTP is a networking protocol

that's used for the synchronization of clocks

between different computer systems

that communicate over a packet-switched,

variable-latency data network.

Now TCP/IP networks are packet-switched,

variable-latency data networks,

so NTP is going to be used to synchronize the time

across all of our IP-connected servers.

Now NTP is pretty special

because it's a really old protocol.

In fact, it's one of the oldest internet protocols

that we still use today.

NTP data is going to be sent over UDP using port 123.

The most current version of NTP is NTP version 4,

and that was released back in 2010.

Now NTP is really important in our computer networks

because it ensures we're all using the same time.

In fact, NTP is designed to synchronize the clocks

of all participating computers

to within a few milliseconds of the UTC

or the Coordinated Universal Time.

Now you can have an internal NTP server within your network,

which is usually going to be more accurate

up to within a few milliseconds,

or you can use an external NTP server

that is publicly available on the internet,

but the accuracy of this

is only within tens of milliseconds.

Now why is it important to care so much about time?

Well, the reason that using NTP is so important

and making sure time is accurate

is that a lot of our security protocols

rely on reliable time for things to work properly.

For example,

if the time between your workstation and your server

are off by more than about five minutes,

you could get an error

that prevents you from logging in to the domain.

So how do we make sure NTP works?

Well, to learn how it works,

we need to talk about three components:

the stratum, the clients, and the servers.

Well, NTP is designed to use a hierarchal,

semi-layered system of time sources.

Each layer of this hierarchy is known as a stratum.

As with most things in computers,

we begin counting our stratum with zero,

and then we start counting up one each time

as we go further down the hierarchy.

So if we start with Stratum 0,

this is the most precise timekeeping devices

that we have access to.

This includes things like the atomic clock, GPS,

and other very accurate devices

that generate a pulse per second as a trigger

to create an interrupt and create a timestamp

on a connected computer.

If you're directly connected to a time source like this,

you are in Stratum 0.

These Stratum 0 clocks are known as reference clocks.

It's important to note that the NTP server itself

cannot be considered at Stratum 0.

Only these reference clocks can.

So the first NTP servers we have in our hierarchy

will actually occur at Stratum 1,

which is any computer whose time source

is synchronized to within a few microseconds

of an attached Stratum 0 device.

To verify their time, these Stratum 1 servers

can also pair with other Stratum 1 servers.

And that way, they can verify their time

is accurate as well.

These Stratum 1 servers are known as primary time servers.

Next, we have NTP servers at Stratum 2.

A Stratum 2 server is connected

to a synchronized Stratum 1 server.

Often, a Stratum 2 server

is configured to query multiple Stratum 1 servers

to ensure it has a stable and robust time source

to provide the other devices within its peer group.

The next level we go to is Stratum 3.

These Stratum 3 servers

are synchronized upward to Stratum 2 servers.

This pattern continues

with Stratum 4 synchronizing the Stratum 3,

Stratum 5 synchronizing the Stratum 4, and so on.

Each time, we add a little bit more delay

and things become a little bit further from Stratum 0

with that precise time that we started with.

Now there is a limit to how many layers

or stratum we can have in NTP, and the limit is 15.

If something is classified as a Stratum 16 device,

this indicates that the device is unsynchronized

according to the algorithm and the protocol.

So what does this look like in your enterprise networks?

Well, usually, you're going to connect the time server

to your network, or you're going to run a time service

on something like your domain controller

with a dedicated hardware reference clock.

This will be at one of those stratum levels

we already discussed, depending on how far away

from the time source you are at Stratum 0.

Then you're going to install

a piece of client software on each workstation

to interface with your server and get the time.

If you're using Windows,

it already has this functionality built in

to its workstations,

and your domain controllers can run the NTP service

to act as their time source at one of the stratum levels.

So you can make sure everybody has the same time

within your network,

and they don't have problems logging on to your domain.