DNS is the domain name system, and we often
refer to this as the service that
converts the fully qualified domain names that we might
type into our browser to something our networks might
use, like an IP address.
But what you may not realize about DNS
is that this is not simply a standalone server that
provides this resource.
There are multiple servers across the internet that
provide these translations and they
work on a hierarchy across all of the different fully
qualified domain names.
This is also a very distributed database,
because we have many different DNS servers on the internet.
There are 13 root server clusters.
In actuality, this consists of over 1,000 different servers.
There are hundreds of generic top-level domains.
These are the domains that are the .com, the .org, the .net,
and others.
And then there are also country-level top-level
domains, like .us, .ca for Canada,
or .uk for the United Kingdom.
Here's a very simple visual representation
of this hierarchy from the perspective
of professormesser.com.
We'll start at the top with a period.
This designates the end of the fully qualified domain name.
And working backwards, we would have a .com, a .net, a .edu,
and others.
Obviously, professormesser.com would be the next layer
in this hierarchy.
So you can see underneath .com, we have .professormesser.
And of course, there may be multiple servers
at professormesser.com.
If you go to my website, then you're
visiting www.professormesser.com,
but I might have a mail server, which
is mail.professormesser.com.
And in very large networks, you may have organizational domain
names-- for example, east.professormesser.com
and west.professormesser.com.
And in the east, there may be certain servers.
In the west, there might be other servers.
Having this hierarchy allows us to configure a very specific
structure, and this works across every fully qualified domain
name on the internet.
If you'd like to see visually how this translation operates
and your system supports the dig command,
you can run at the command line dig www.professormessor.com.
The results of this command show us
a summary of what we requested.
It shows the information that was sent asking specifically
for an address associated with www.professormesser.com.
And then you can see in the ANSWER SECTION,
there are actually three different IP addresses
associated with my web server, and you
can see those IP addresses are listed here.
The reason there are three different addresses for my web
server is for redundancy.
If one of those IP addresses is no longer available,
your device can use any of these other IP addresses
to communicate back to www.professormesser.com.
If you're not on a system that supports the dig command,
you can use nslookup professormesser.com.
This will go out to your locally configured DNS server
and provide answers for the professormesser.com IP
addresses, and you can see the results
of this query show exactly the same three IP addresses.
Behind the scenes, the DNS server
has a large database that contains fully qualified domain
names, IP addresses, and other details that
can help your systems perform this translation between fully
qualified domain name and IP address.
We refer to these as resource records, and in this video,
we'll look at a number of different types of resource
records that are used on a DNS server.
There are over 30 different record types.
We won't go through all 30 of those in this video.
Those record types might be IP addresses, certificates,
host names, and other details.
As you can imagine, a DNS server is a critical resource.
If a DNS server isn't available, you
can make the request to visit www.professormesser.com,
but there's nothing behind the scenes
to make the translation between the fully qualified domain
name and the IP address.
This is why we tell people, if you're making a change to DNS,
make sure you have very good backups
of the previous configuration and that you
know exactly what you're changing in that DNS server.
Many DNS servers have a very simple configuration file
that's written in text, and this is an example of one
of those DNS configurations.
The section at the top is the Start of Authority Record.
This has some mail exchanger records inside of it,
a list of IP addresses, and fully qualified domain names,
and you've got some canonical or alias
names that you've also assigned inside of this DNS server.
This makes it relatively easy if you
need to make changes to a DNS server's configuration
because you can use any text editor to modify or update
this configuration file.
You might also find that the DNS service that you're using
can provide you with a web-based front end to the configuration,
so instead of understanding all of those different records
and understanding where they go in the configuration file,
you can put them all into a web-based front end
and make your changes from there.
The first record will look at and perhaps one
of the most common records you see in a DNS server
is an address record.
We often refer to these as in A record or a AAAA record.
The A records are address records for IP version 4.
So this a record will have a fully qualified domain
name and the associated IP version 4 address.
The quad A records are for IPv6.
The same thing applies.
We'd have a fully qualified domain name,
and we would associate the IPv6 associated with that domain
name.
Here's an example of an A record that's
on the professormesser.com DNS server.
You can see that I am specifying that www.professormesser.com
is an internet address using the A record,
and the IP address associated with that fully qualified
domain name is 162.159.246.164.
If you're configuring this in a DNS text file,
then you also have the option to add remarks or other comments
on that record line.
If the front end to your DNS server
is in a web-based configuration, it's the same information,
but we've separated out the A record, the hostname, the IP
address, and the time to live for this IP address.
The time to live in a DNS server is
specifying how long an end station will remember
this match between fully qualified domain name and IP
address.
This 15 minute time to live means
that a device will make the request to a DNS server
and store or cache that information for 15 minutes.
After 15 minutes, that information
is removed from the cache, and if this device
needs to communicate back to the www server,
it will need to request, again, the IP address
for that particular record.
Here's the same thing, but from the perspective
of IPv6, where we're configuring a quad A record,
and we have a hostname, an IPv6 address, and, again, a time
to live.
Another important record in a DNS is where all of your emails
should be delivered.
This is a mail exchanger record or an MX record.
To make this work, you would need two separate records
inside of your DNS server.
The first would be the MX record.
You can see the mail exchange record in this server points
to mail.mydomain.name.
To be able to obtain the IP address for mail.mydomain.name,
we would need to look at an A record,
and you can see there is an A record
for the mail.mydomain.name, which is 123.12.41.41,
and it is a Linux server.
DNS servers have many different functions they can provide.
One of those is to stored text information that can then
be used for other purposes.
We would store the text information
in a text record or TXT record.
This is usually public information.
Since people are able to query these text
records on your server, these text records
were originally designed for very informal purposes.
But today, we have very specific uses for a TXT or text
record in our DNS server.
For example, we might use this for verification purposes.
We might be making a configuration change
to our domain, and that domain change
requires that you add something very specific to a text
record in your DNS server.
This is because the DNS server configuration is usually
very secure, and only authorized individuals
would have access to make changes to a DNS server's
configuration.
We also use this text record extensively for email security,
and you'll see in a moment how we're able to add information
to a text record that can help verify
the origination of a particular email.
If you want to see some example of text records,
you can look at the text records that
are on the professormesser.com DNS server.
If you're running dig, you can use dig professormesser.com
and then txt.
And then it will show all of the text records
that I have currently configured on my DNS server.
You can see that I have two currently configured,
one for a stripe verification, and another one that
is used for mailgun.org, which is used to send out my email
messages.
If dig isn't available, you can also
view these using an nslookup.
You would use nslookup-type=txt, and then the domain name such
as google.com or professormesser.com.
You can see when you perform a google.com lookup that Google
has a number of text records on their device, which include
things like a Facebook domain verification, a Google site
verification, and a DocuSign text record.
A common text record you might find
is an SPF record, or a sender policy framework.
This is a list of all of the email servers that
are authorized to send messages using your fully
qualified domain name.
This was created to help prevent others
from spoofing your fully qualified domain name
and sending email as if you would send it yourself.
A mail server receiving an email that
says it was from professormesser.com
will query the professormesser.com DNS server,
retrieve this SPF record in the DNS server,
and be able to determine is this something that really
came from an authorized host?
Here's the same process for creating a text-based DNS
record, and you can see, you just
paste in the text that is associated with the record
that you'd like to add.
In this example, you can see that I'm adding the SPF
record into my DNS server, and, again,
I have a TTL of 15 minutes.
We can even take this email security one step further
and provide a digital signature that we can
associate with outgoing mail.
We do this through the use of a DKIM text record,
or Domain Keys Identified Mail.
This is going to be validated by the mail servers
as that message is traversing the network,
and the public key associated with this digital signature
is added to a text record in your DNS server.
Here's the same configuration for that DKIM record,
except we're making the configuration
change in this web-based front end, and you can see,
it's a large bit of text that is the public key for all
of the digital signatures that have been sent from my domain.
Now that we have a way to verify messages that have been sent
and to digitally sign messages that are being sent,
we need some way to determine what we do with those messages
if the verification fails.
We would use DMARC for that purpose.
This is the Domain-based Message Authentication Reporting
and Conformance.
This is an extension of the SPF and DKIM processes
that we've already seen, except DMARC takes the extra step
to determine the disposition that
should be used when someone receives a message that
can't be validated.
You might create a DMARC record on your DNS server that
says, if a message is not validated,
simply accept it, or maybe send it to a spam folder,
or simply reject the email entirely.
The mail servers behind the scenes
keep track of how many mail messages have been validated
and how many have failed the validation,
and then you can receive a report that shows exactly how
many messages were able to get through based on the SPF
or DKIM configuration.
And here's an example of adding one of those DMARC text records
to your DNS.
You can see that the content specifies
what to do with the email messages
and where to send the report so that you can examine how
your mail has been distributed.