Prep for a Windows DNS Deployment

There's a lot to consider when you decide to deploy DNS with Windows network. This overview will get you started, and next week we'll look at securing your setup.

By Deann Corum | Posted Nov 4, 2008
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

So many complex things can follow from things meant to make life simpler. If you use Active Directory (AD), you have to have DNS somewhere in your environment. And somewhere in the process of installing AD, a DNS namespace was decided upon and either second-level or subdomains were configured for AD. And, more than likely, one or more of your DNS servers is Windows-based.

If you're just beginning this not-so-small adventure, we'll go over some basic things you need to consider before you embark, and next week we'll identify some security threats and some ways to harden your Windows-based DNS servers.

Deploying Windows DNS: Some Basic Considerations

Since AD requires DNS, you may have to design an AD name space which will include DNS, or at least integrate an AD-specific DNS zone into your existing network. If you have an established domain and an established DNS server to host the zone, this may involve adding a subdomain as an Active Directory Root, e.g., domain2.company.com, then delegating authority for that zone from the existing DNS server (which hosts the company.com zone) to the new DNS server you'll install for AD.

If you're establishing your domain name and AD/DNS infrastructure anew, you should consider leaving an empty AD domain at the very top of your design, e.g., company.com zone) for growth. Then you'll place your subdomains (zones) below that. These subdomains may be organized by geographical area, department, division - or in myriad ways to support your company's needs and network capabilities.

Unix-based DNS server can also be used for Windows AD. If that is required, then BIND on the Unix-based server must be at least version 8.1.2 or later to support SRV (Server Resource Records) and dynamic update. Server Resource Records are required for AD. Dynamic updates (RFC 2136) are optional, however manual administration of SRV resource records is required for AD to function properly on a DNS server that does not support dynamic updates.

You can also configure a Windows-based DNS server as a primary, and a BIND-based DNS server as a secondary, or vice-versa but then you are stuck with standard -- i.e., not AD-integrated zones. In a Windows DNS environment, this will cost you some functionality that has specifically to do with DNS security, such as secure dynamic updates and AD-integrated zone security. If you'll have internet-facing DNS servers (hopefully well-contained in a DMZ (define)),then separate internal and external DNS servers and zones are highly recommended, and you'll need to be particularly careful in configuring DNS-related communication to, from, and between them to protect your servers and your network.

Active Directory, DNS Capacity, and Zone Planning

If you're designing AD/DNS for your company, you'll need to consider server-to-server traffic caused by zone transfers with other DNS servers, AD replication, and DHCP registrations, particularly across WANS. Much of how you configure DNS and/or AD will depend on your network topology, and where high-speed links and Internet-facing servers are placed. Client-to-server traffic should be considered too. Consider DNS query loads and dynamic updates sent to DNS by newer client computers or DHCP servers providing dynamic updates to down-level clients that do not support dynamic updates (Windows NT 4.0 systems, or Windows 9x clients). Also consider if WINS lookups will be necessary. If you administer a small remote site, it may be best to use a caching-only DNS server if you have a stable, primary AD-integrated DNS server and are located across a WAN, where zone transfers might be resource intensive. Note that DNS servers don't have to be AD Domain Controllers (DCs), but it is recommended that you have two DNS servers for each zone and at least two DCs for each domain for redundancy.

In determining the number and capacity of servers to use for DNS/AD, consider how many domains and/or zones these servers will be expected to service and how large these zones and directories are expected to be. Having sufficient RAM on a DNS server will provide the best performance. This is because the DNS Server service loads all of its zones into memory at startup. According to Microsoft, every resource record in a DNS zone requires about 100 bytes of server memory. If your servers will host large zones and dynamic updates will occur frequently, then the more RAM, the better. If your DNS server is also a DC hosting a large directory, consider AD replication, Flexible Single Master Operation (FSMO) roles, logon traffic, and the impact these will have on your servers and network, particularly across a WAN. For domain controllers, use of AD sites will help control AD replication across WAN links. AD sites define well-connected network areas, and in directory operations, they affect replication and logon traffic. AD replication traffic between sites is compressed down to 10 or 15 percent of the size that would be required to replicate the same changes within a site. Compressed data requires more CPU power at each end of the connection to process, so if a DNS server is also a DC in a site with a large directory, it will need a lot of CPU as well as a lot of RAM.

A side note on Windows 200x DNS/DHCP servers: You should not configure the DHCP service on a computer that is also a DC to perform dynamic DNS updates. If a DHCP server exists on a DC, the DHCP server has full control over all DNS objects stored in Active Directory, because the account it is running under (the domain controller computer account) has this privilege. This configuration creates a security risk that you should avoid. You should not install a DHCP server service that is configured to perform dynamic DNS updates on a DC; instead, you should install it on a member server if you're performing dynamic DNS updates. As an alternative, you can use a new feature in Windows Server 2003 DHCP, which allows for the creation of a dedicated domain user account that all DHCP servers will use when performing dynamic DNS updates.

As you can see, implementing DNS/AD on your network will require considerable planning and design, much of which is beyond the scope of this article! But we hope we've been able to provide enough basic information to get you thinking (or get your head really hurting), and at least give you some idea what you're in for. There are some excellent books on the subject if you're just beginning this journey: DNS on Windows Server 2003 and Active Directory. Microsoft has copious Tech net information on deploying Windows Server 2003 DNS here.

Make sure to come back next week, when we discuss how to identify and mitigate threats to DNS.

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter