How is DNS related to Active Directory and what are some common configurations that I should be aware of?

Solution 1:

Active Directory relies on a properly configured and functional DNS infrastructure. If you have an Active Directory problem, chances are that you have a DNS problem. The first thing you should check is DNS. The second thing you should check is DNS. The third thing you should check is DNS.

What exactly is DNS?

This is a site for professionals, so I'll assume you've at least read the excellent Wikipedia article. In short, DNS allows IP addresses to be found by looking up a device by name. It's critical for the Internet to function as we know it and it's run on all but the smallest of LANs.

DNS, at the most basic level is broken into three fundamental pieces:

DNS Servers: these are the servers that hold records for all of the clients that they are responsible for. In Active Directory, you run the DNS Server role on a Domain Controller(s).
Zones: Copies of zones are held by servers. If you have an AD named ad.example.com, then there is a zone on your Domain Controllers that have DNS installed named ad.example.com. If you have a computer named computer and it was registered with that DNS server, it would create a DNS record named computer in ad.example.com and you would be able to reach that computer via the Fully Qualified Domain Name (FQDN), which would be computer.ad.example.com
Records: As I've mentioned above, zones hold records. A record maps a computer or resources to a specific IP address. The most common kind of record is an A record, which contains a hostname and an IP address. The second most common are CNAME records. A CNAME contains a hostname and another hostname. When you look up hostname1, it performs another lookup and returns the address for hostname2. This is useful for obscuring resources like a web server or file share. If you have a CNAME for intranet.ad.example.com and the server behind it changes, everyone can continue to use the name they know and you only have to update the CNAME record to point to the new server. Useful huh?

Ok, how does this relate to Active Directory?

When you install Active Directory and the DNS Server role on your first Domain Controller in the domain, it automatically creates two forward lookup zones for your domain. If your AD domain is ad.example.com as in the example above (note that you should not use just "example.com" as a domain name for Active Directory), you'll have a zone for ad.example.com and _msdcs.ad.example.com.

What do these zones do? GREAT QUESTION! Let's start with the _msdcs zone. It holds all of the records that your client machines need to find domain controllers. It includes records to locate AD sites. It has records for the different FSMO role holders. It even holds records for your KMS servers, if you run this optional service. If this zone didn't exist, then you wouldn't be able to log on to your workstations or servers.

What does the ad.example.com zone hold? It holds all of the records for your client computers, member servers, and the A records for your Domain Controllers. Why is this zone important? So that your workstations and servers can communicate with each other on the network. If this zone didn't exist, you could probably log in, but you wouldn't be able to do much else except browse the Internet.

How do I get records in these zones?

Well, fortunately for you, that's easy. When you install and configure the DNS server settings during dcpromo, you should elect to allow Secure Updates Only if given the choice. This means that only known domain-joined PCs can create/update their records.

Let's back up for a second. There are a few ways that a zone can get records in it:

They are automatically added by workstations that are configured to use the DNS server. This is the most common and should be used in tandem with "Secure Updates Only" in most scenarios. There are some edge cases where you don't want to go this way, but if you need the knowledge in this answer, then this is the way you want to do it. By default, a Windows workstation or server will update its own records every 24 hours, or when a network adapter gets an IP address assigned to it, either via DHCP or statically.
You manually create the record. This might happen if you need to create a CNAME or other type of record, or if you want an A record that isn't on a trusted AD computer, perhaps a Linux or OS X server that you want your clients to be able to resolve by name.
You let DHCP update DNS when leases are handed out. You do this by configuring DHCP to update the records on behalf of the clients and add the DHCP server to the DNSUpdateProxy AD group. This isn't really a good idea, because it opens you up for zone poisoning. Zone poisoning (or DNS poisoning) is what happens when a client computer updates a zone with a malicious record and attempts to impersonate another computer on your network. There are ways to secure this, and it does have its uses, but you're better off leaving it alone if you don't know.

So, now that we have that out of the way we can get back on track. You've configured your AD DNS servers to only allow secure updates, your infrastructure is chugging along, and then you realize that you have a ton of duplicate records! What do you do about this?

DNS Scavenging

This article is required reading. It details the best practices and settings that you'll need to configure for scavenging. It's for Windows Server 2003, but it's still applicable. Read it.

Scavenging is the answer to the duplicate record problem posed above. Imagine that you have a computer that gets an IP of 192.168.1.100. It will register an A record for that address. Then, imagine that it'd powered off for an extended period of time. When it's back on, that address is taken by another machine, so it gets 192.168.1.120. Now there are A records for both of them.

If you scavenge your zones, this won't be a problem. Stale records will be removed after a certain interval and you'll be fine. Just make sure that you don't scavenge everything by accident, like using a 1 day interval. Remember, AD relies on these records. Definitely configure scavenging, but do it responsibly, as outlined in the article above.

So, now you have a basic understanding of DNS and how it is integrated with Active Directory. I will add bits and pieces down the road, but please feel free to add your own work as well.