Jason: 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 hostnames
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 address 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 our 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 provider is .com,
but we also have things like .mill, .edu, .org, .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 route level, the top level domain,
the second level domains, subdomains, and the host.
The route level is the highest level
in the DNS hierarchy tree,
and the route nameserver is going to answer requests
in the route zone.
These servers contain the global list
of all the top level domains, things like.com,
.net, .org, .mill, 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 route 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 it 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:// 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 hyper text 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:// to the beginning of the web address.
Now, if you want to connect using FTP,
you would use FTP://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 going to create 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, TXT 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.
An 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 @ host,
and this indicates a record for the route domain.
In the example of Dion Training,
our @ record signifies that diontraining.com,
which is the route of our domain, is going to be listed
at a certain IP.
This way, our users can find our website by going
to the subdomain of www.diontraining.com,
or just by going to diontraining.com
by using that A @ 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 can 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 4A 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
for 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 wanted to allow people to type in itil4exam.com
and reach something instead of just an error page.
So I used a 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 at 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've 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 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 enters 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.
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.diontraininf.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 at 10,
all incoming emails are going to alternate
and load balance 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 TXT records, or text records.
Now, a text record is used by domain administrators
to add text 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 where 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 texturing 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."
In your TXT records, you can also put information
such as SPF, DKIM, or DMARC messages to be able
to help verify your email services
and block the transmission of spoofed
or unwanted messages known as spam
to other people using your domain and email addresses.
SPF, or the sender policy framework,
this is a DNS record that identifies
the host authorized to send mail for the domain,
and there's only going to be one allowed
for each and every domain.
Now, as you look at them,
you're going to have something that looks like this,
and this is a DNS record called a text record.
You'll notice it has the @ sign, and then says V=SPF1,
which is sender policy framework one.
It's the first one.
It then has MX, which is the mail server record,
and then it says include:_SPF.google.com,
and include:email.freshdesk.com-all.
Now, what is this telling you?
Well, this is actually the SPF record for my email server.
Now, why do we have google.com there?
Well, it's because we use G Suite from Google,
and so Google is our email service provider.
We don't run our own email server.
Instead, we let them do it,
and we've given them authorization to do that,
that they are authorized to send email on our behalf
by including that SPF statement.
Now, the second one there,
you might be wondering, "What's that for?
I thought you could only have one."
Well, you can only have one SPF statement,
but this entire thing is one line when written in DNS,
and this whole thing from text all the way to all is
one single line, and that is one single SPF statement.
I can authorize multiple servers to send on my behalf,
but I can only do it in one DNS line as you see here,
and what Freshdesk is is our trouble ticket system.
If you email support at Dion Training,
it's going to go to Freshdesk,
but if you email my personal email at Dion Training,
it's going to go over to Google,
because that's who does our personal emails for our company,
and so you have to include both of those in anything else
that's going to be authorized to send on your behalf
inside this statement.
Now, the next thing we need to talk about is DKIM, or dkim.
Now, this is domain keys identified mail.
This provides a cryptographic authentication mechanism
for mail using a public key published as a DNS record.
Now, when you look up an SPF or DKIM,
you're going to see something like this.
Here's an example showing you the mail for adobe.com.
You can see the DMARC at the top,
which we'll talk about in a minute,
you'll see the SPF, which we just talked about,
and then you'll see DKIM,
which is what we're talking about now.
It's basically a very long cryptographic authentication key,
and you can see it there on the screen.
Now, DKIM can either replace or be used with SPF.
The next one we're going to talk about is DMARC, and DMARC is
the domain-based message authentication reporting
and conformance.
This is basically a framework,
and this framework is used for ensuring proper application
of SPF and DKIM utilizing a policy
that's published as a DNS record,
and I showed you that very briefly in the last image
on your screen when I showed you the DMARC
as the top line of that image.
If you want to go back and take a look at that,
you can can at this time.
Now, when you're dealing with DMARC,
you can use this either with SPF, with DKIM, or using both,
because remember,
SPF and DKIM don't have to be used together.
You can use one or the other, or you can use both,
and DMARC is going to be used with one of the other or both.
Now, when you're dealing with MARC,
this is what it looks like.
So how does all of this work together?
Well, first you have to make sure that your SPF,
your DKIM, and your DMARC are all on the DNS server.
Once you have all those records there,
that's what starts this whole process.
Now, once you've done that once,
everything else is going to follow up
each and every time you want to send a message.
In this example, we're going to have two messages being sent,
one from the SMTP server,
which is authorized and being shown as green,
and one from an adversary who's trying to spoof your domain,
which is going to be shown in red.
Let's start with the one that's authorized.
Here, it's listed as 2A.
Your sender is going to send that message over to the MTA.
It goes to the MTA, which is your message transfer agent,
and it's going to end up taking that message
with the SPF or DKIM header in it.
Now, let's stick with this message for a minute,
and then we'll come back to the adversary.
Once the MTA has that message,
it's going to go ahead and look at that message,
and process that message.
When it does that, part of that is going to be looking up
the sender DMARC policy and the SPF and DKIM records
via DNS, just like we talked about
in the last three or four minutes here.
Now, once the MTA does that, if it's legitimate,
that message can be placed into the receiver's mailbox
on the IMAP server, and wait for the person to be able
to read their message using their mail user agent.
That's all good,
because they know this message was authentic,
because it compared those values against the SPF,
the DKIM, or the DMARC, based on the policy that was set up.
Now, if we look at the adversary on the other hand,
when they send the message, it still goes to the MTA,
because it has to get to the MTA to get to that end user.
Once it gets there, though,
the MTA's going to check it versus that DMARC policy,
looking at the SPF or DKIM records.
Once it does that, if they don't match,
it's going to reject that message,
delete it, or quarantine it, and it throws it away,
as you could see in 5B.
Again, this is the way this stuff works,
and by using this DKIM, DMARC and SPF together,
we can add some security into our organizations.
Finally, we have an NS record,
which stands for nameserver record.
Now, a nameserver record is used to indicate
which DNS nameserver in the world is going to be
the authoritative one for that domain.
This is important because DNS uses that hierarchical 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 nameserver 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 records, AAAA records, canonical name records,
MX mail exchange records, and TXT text records.
There are often more than one nameserver for a domain
as well, so you can have a primary and a backup nameserver.
Additionally, you don't always have to host
your own nameservers.
In the case at diontraintraining.com,
we don't host our own nameservers.
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 two
of Cloudflare's nameservers.
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 service 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,
and 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 a 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 host.
So if you're running Windows 10, for example,
your computer's 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 it 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 its DNS cache,
and it's going to see there's a record there.
But if that time to live has 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, and if they had to resync
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 it'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 route domain for diontraining.com,
then it can ask the .com route server
which DNS server is authoritative for diontrain.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 a 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 will 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
with 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 nameservers.
TXT records store text either as human-readable
or machine-readable data.
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.