DNS overview
If we consider Active Directory to be the most common and central role in making our Microsoft-centric networks function, then the Domain Name System (DNS) role slides in at number two. I am yet to meet an admin who has chosen to deploy a domain without deploying DNS at the same time, they always go hand-in-hand.
Tip
DNS is a service that is typically provided by a Windows Server, but doesn't have to be. There are many different platforms available all the way from Linux servers to specialized hardware appliances designed specifically for managing DNS within a network that can be utilized for this role. For most Microsoft-centric networks, and for the purposes of this book, we will assume that you want to use Windows Server 2016 for hosting the DNS role.
DNS is similar to Active Directory in that it is a structured database which is often stored on domain controller servers, and distributed automatically around your network to other domain controller/DNS servers. Where an AD's database contains information about the domain objects themselves, DNS is responsible for storing and resolving all of the names on your network. What do I mean by names? Whenever a user or computer tries to contact any resource by calling for a name, DNS is the platform responsible for turning that name into something else in order to get the traffic to the correct destination. You see, the way that traffic gets from client to server is via networking, and typically via the TCP/IP stack, using an IP address to get to its destination. When I open an application on my computer to access some data that resides on a server, I could configure the application so that it communicates directly to my server by using the server's IP address on the network. If I plug 10.0.0.15 into my application configuration, it would open successfully. If I set up hundreds of different computers this way, all pointing to the IP address, it would work fine for a while. But the day will come when for whatever reason, that IP address might need to change. Or perhaps I add a second server to share the load and handle my increased user traffic. What to do now? Re-visit every client computer and update the IP address being used? Certainly not. This is one of the reasons that DNS is critical to the way that we design and manage our infrastructures. By using DNS we can employ names instead of IP addresses. With DNS my application can be configured to talk to Server01 or whatever my server name is, and if I need to change the IP address later, I simply change it inside the DNS console to the updated IP address and immediately all of my client computers will start resolving Server01 to the new IP address. Or I can even use a more generic name like Intranet and have it resolve across multiple different servers. We will discuss that a little bit more shortly.
Any time that a computer makes a call to a server, or service, or website, it is using DNS in order to resolve that name to a more useful piece of information in order to make the network connection happen successfully. The same is true both inside and outside of corporate networks. On my personal laptop right now, if I open Internet Explorer and browse to http://www.bing.com/, my Internet provider's DNS server is resolving http://www.bing.com/ to an IP address on the Internet, so that my page opens successfully. When we are working inside our own corporate networks, we don't want to rely on or trust a public provider with our internal server name information, and so we build our own DNS servers inside the network. Since DNS records inside a domain network are almost always resolving names to objects that reside inside Active Directory, it makes sense then that DNS and AD DS would be tightly integrated. That rings true in a majority of Microsoft networks, where it is a very common practice to install both the AD DS role, plus the DNS role, on your domain controller servers.
Different kinds of DNS records
Now having installed our DNS role on a server in the network, we can start using it to create DNS records which resolve names to their corresponding IP addresses, or other pieces of information needed in order to route our traffic around the network. Assuming that you are working in a domain network, you may be pleasantly surprised to see that a number of records already exist inside DNS, even though you haven't created any of them. When you are running Active Directory and DNS together, the domain-join process that you take with your computers and servers self-registers a DNS record during that process. I have not yet created any DNS records on my new lab environment, not purposefully anyway, and yet when I open the DNS Manager console from inside the Tools menu of Server Manager, I can see a handful of records already existing. This is because when I joined each of these machines to the domain, it automatically registered these records for me so that the new servers and clients were immediately resolvable within our domain.
Host record (A or AAAA)
The first kind of DNS record we are looking at is the most common type that you will work with. A host record is the one that resolves a particular name to a particular IP address. Pretty simple, and for most of the devices on your network this will be the only kind of record that exists for them inside DNS. There are two different classes of host record that you should be aware of, even though you will likely only be using one of them for at least a few more years. The two different kinds of host records are called an A record, and an AAAA record, which is pronounced Quad A. The difference between the two? A records are for IPv4 addresses and will be used in most companies for years to come. AAAA records serve the exact same purpose of resolving a name to an IP address, but are only for IPv6 addresses, and will only be useful if you use IPv6 on your network.
In the previous screenshot, you can see some Host (A) records that were self-created when those machines joined our domain. I also have another server running on my network which has not yet been domain-joined, and so it has not self-registered into DNS. This server is called ra1, but if I log in to any other system on my network, I fail to contact my ra1 server, since that name is not yet plugged into DNS.
For now, I am going to choose not to join this box to the domain, so that we can manually create a DNS record for it and make sure that I am able to resolve the name properly after doing that. Back inside DNS Manager on my DNS server, right-click on the name of your domain listed under the Forward Lookup Zones folder, and then choose New Host (A or AAAA). Inside the screen to create a new host record, simply enter the name of your server, and the IP address which is configured on its network interface.
Now that we have created this new host record, we should immediately be able to start resolving this name inside our domain network. Moving back to the client machine from which I was trying to ping ra1 earlier, I'll try the same command again, and this time it does resolve and reply successfully.
Alias record – CNAME
Another useful type of DNS record is CNAME, or more commonly these days called the alias record. This is a record that you can create which takes a name, and points it at another name. Sounds a little silly at first glance, because in the end you are still going to have to resolve your final name to an IP address in order to get the traffic where it needs to go, but the purposes of an alias record can be vast. A good example to portray the usefulness of an alias record is when you are running a web server that is serving up websites within your network. Rather than force all of your users to remember a URL like http://web1.contoso.local in order to access a website, we could create an alias record called Intranet, and point it at web1. This way the more generalized Intranet record can always be utilized by the client computers, which is a much friendlier name for your users to remember.
In addition to creating a happier user experience with this new DNS record, you have at the same time created some additional administrative flexibility because you can easily change the server components that are running beneath that record, without having to adjust any settings on the client machines or re-train employees on how to access the page. Need to replace a web server? No problem, just point the alias record at the new one. Need to add another web server? That's easy too, as we can create multiple alias records, all with the same Intranet name, and point them at the different web servers that are in play within the environment. This creates a very simple form of load balancing, as DNS will start to round-robin the traffic among the different web servers, based on that Intranet CNAME record.
In fact, rather than continue to talk about this, let's give it a try. I have a website running on exactly that URL in my environment, but currently I can only access it by typing in http://web1.contoso.local. Inside DNS I am going to create an alias record that redirects intranet to web1.
Now when I ping intranet, you can see that it resolves to my web1 server. And when accessing the webpage, I can simply type the word Intranet into my address bar inside Internet Explorer in order to launch my page. The website itself is not aware of the name change being made, so I didn't have to make any modifications to the website, only within DNS.
Mail Exchanger record
A third type of DNS record is called a Mail Exchanger (MX) record. In your everyday duties you would not have to encounter or configure MX records nearly as much as A or CNAME records, but they are important to understand nonetheless. An MX record is all about e-mail services and delivery. Whatever domain name follows the "@" in your e-mail address, the DNS servers who are handling that domain name must contain an MX record telling the domain where to point for its e-mail services. MX records are only used with public DNS, for name resolutions happening over the Internet. For companies hosting their own e-mail on local Exchange servers, your public DNS servers will contain an MX record that points at your Exchange environment. For companies hosting their e-mail in a cloud service, your public DNS records would need to contain an MX record that directs e-mail traffic toward the cloud provider who is hosting your mailboxes.
Name Server record
Here is another that you don't have to deal with on a day-to-day basis, but you should still know what it's there for. An Name Server (NS) record is an identifier within a DNS zone that tells it which Name Servers, your DNS servers, to use as the authorities for that zone. If you look at the NS records listed in your DNS right now, you will recognize that it is calling out the names of your DNS servers on the network. When you add a new DC/DNS server to your domain, a new NS record for this server will be automatically added into your DNS zone.
There are many other possible types of records that can be stored and used within a DNS database, but they are not generally relevant to the common server administrator in a typical Microsoft-driven network.
Ipconfig /flushdns
Just one final note to finish out this section. I have been saying things like "now when I do this…" or "immediately following this change…" and if you are creating some of your own records, you may have noticed that it sometimes takes a while for your client computers to recognize these new records. That is normal behavior, and the time that it takes before your change rolls around to the whole network will depend entirely on how large your network is and how Active Directory replication is configured. When you create a new DNS record on one domain controller, your new record needs to replicate itself around to all of the other DCs in your network. This process alone can take up a couple hours if AD is not configured for faster replication. Typically, it only takes a few minutes. And then once the new record exists on all of your DC servers, your clients may still take a little bit of time to utilize the new record, because client computers in a domain network hold onto a cache of DNS data. This way they don't have to reach out to the DNS server for every single name resolution request.
They can more quickly refer to their local cache in order to see what the information was from the last time they checked in with the DNS server. If you are trying to immediately test out a new DNS record that you just created and it's not working, you may want to try to run the command ipconfig /flushdns on your client computer. This forces the client to dump its locally cached copies of DNS resolver records, and go grab new information that is current from the DNS server. After flushing your cache, the record will more than likely start working properly.