If you were to look at the configuration of a DNS server,
you would see a number of different records
that have been defined to that DNS database.
We refer to these as Resource Records, or RR.
And there are a number of different resource records
that you would find-- over 30 different record
types inside of a DNS server.
Fortunately, in this video, we're
not going to go through all 30 of those record types,
but we will look at some of the most popular ones and records
that you should be familiar with if you're ever
having to troubleshoot problems on your network.
Here is a very simple configuration file inside
of a DNS server.
We refer to this as a Forward Lookup file.
Inside of this configuration file,
we'll be able to see information about the domain
in general and more specific records associated
with this domain.
At the very top of the configuration
file is an SOA record.
This is the Start of Authority, and this
is the part of the configuration file
that defines what this DNS server is managing.
It describes the DNS zone details; the structure
of the domain, including the names
of the zone, serial numbers associated
with the configuration, refresh, retry, and expiry timeframes,
and caching information, or TTL--
Time to Live information.
And all of this is added to the beginning of this DNS server
configuration.
Most of the time, we're making a request
to a DNS server that contains a fully qualified domain name,
and we're hoping to receive an IP address in return.
The way that we're able to receive
that IP address is because inside the DNS server
is an Address record.
This Address record is sometimes referred to as an A record
for IP version 4 or a quad A record for IP version 6.
If you ever have to modify the IP or name of a device,
then you're probably going to modify one of these A records.
And if you're running IPv6, you may
have both the A and the quad A records in the same database
referring to the same server but with different IP address
configurations.
For example, in my DNS server, there
might be an Address record that starts
with www.professormesser.com.
I specified this as an Address record.
And in the DNS parlance, this is an Internet Address record.
That's the IN and A. And I have the IP address of the server,
also, as part of that record.
I can also put comments in here so
that if I ever need to go back to this record,
I can see what this particular IP address or name is
associated with.
So if somebody makes a query to the server,
and they're asking for the IP address
of www.professormesser.com, the DNS server
looks through the Configuration file, finds the Address record,
and reports this IP address back to the querying device.
There may be times when we have one IP address that's handling
many different services.
For example, we might have a server that's
handling chat services, file transfer services,
web services, and mail services all on the same IP address.
And instead of putting separate Address records into our DNS
server, we'll instead put Canonical
Name records, or CNAME records.
These are records that provide an alias
to an already existing server.
So if I have a device called mail.mydomain.name,
and that server is providing other services,
I can create a CNAME record for chat, for FTP, and for www.
This means anybody using these particular canonical names
to be able to find an IP address would
have all of those devices resolved back
to mail.mydomain.name.
There may be times when you want to use
DNS to help clients on your network find another service.
And in those cases, we'll want to create
a Service record, or SRV.
If your network has a Windows domain controller,
an instant messaging server, a voice-over IP gateway,
then we might want to create a Service
record that identifies where that particular device might
be.
For example, on this particular network,
there is an LDAP server.
And that LDAP server is located at s1.domain.com.
Almost all the domains you work with
are going to use some type of email service.
And if there is email in that domain,
then you'll need a Mail Exchanger record, or MX record,
in your DNS server.
This record contains the name of the mail server
that you could then perform additional queries to determine
what the IP address might be.
But the Mail Exchanger record is relatively straightforward.
You have an internet address specifying MX and then
the name of the mail server.
In this case, mail.mydomain.name.
In a previous video, we described DNS
as being a hierarchy of Name servers.
For this hierarchy to work, we need
to have references in our Name server
that will point to other Name servers.
So we'll need to add a record called a Name Server record,
or an NS record.
And if someone's trying to find the Name
server for your domain, they can simply perform a query
and receive the response for NS1 and NS2,
our Name servers for this domain.
Earlier in this video, we looked at Address records
and saw that we could query a DNS server with a fully
qualified domain name and receive back
an IP address because we have an Address record.
We can create the reverse of an Address record,
and that's called a Pointer record, or a PTR record.
This allows us to perform a reverse DNS
lookup to this server, where we would provide an IP address,
and the DNS server will respond back
with a fully qualified domain name
because it was able to look that up in the Pointer record.
There may be times when we're not adding a DNS name or an IP
address, but, instead, we're putting in some type of text
into our DNS server.
This text may be something like an SPF Protocol record.
The SPF stands for Sender Policy Framework
that prevents somebody from spoofing email from our domain.
The SPF record allows mail servers
to perform a check to see if the email really
did come from our domain.
Another type of text record might
be a Domain Keys Identified Mail record, or DKIM.
This allows us to digitally sign our outgoing mail,
and we can put the public key in the DKIM record
so that it can be verified by the receiver.
Here's an example of an SPF text record
you can see the SPF has information
that describes the outgoing mail server for my domain.
And I also have a DKIM record, and this
has my public key so that someone receiving mail
from my server can verify that it really did
originate on my email server.
These DNS services are, obviously,
very critical to maintaining uptime and availability
of your services.
And because of that, we need some way
to provide replication and redundancy of this DNS
information.
We provide that redundancy by using zone transfers.
These zone transfers allow us to make DNS changes
on a primary DNS server and have all of those changes replicated
to secondary DNS servers.
This ensures that any changes we make
will be replicated to other redundant servers.
That way, if we lose our primary server,
or we happen to lose connectivity,
all of the other secondary servers
will have identical information.
If you refer back to the Start of Authority record,
there was an entry for a serial number.
That serial number specifies the version number
of the DNS entries.
If we update that serial number, your DNS server
will recognize there's a new version of the configuration,
and a zone transfer will occur.
Although this is great for maintaining uptime
and availability, we do have to be careful
that not everyone is able to perform
one of these zone transfers.
For example, you don't want someone
from the outside performing a zone transfer
to their own machine and obtaining
all of your internal names and IP addresses for all
of your internal services.