The configuration of a DNS server consists of a series of records. In this video, you’ll learn about the record types commonly seen in a domain name system server configuration.
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.