Since we are on the topic of DNS as it relates to Windows and Active Directory, I thought I'd bring up another issue that I have regularly encountered at customer sites. This has to do with the configuration of the DNS client settings on DNS-enabled Domain Controllers.
In Windows 2000, there were cases where if a server were configured to register to itself and only itself, it could in certain cases become a replication island. This means that the only DCs it knows about is itself and any changes made on that DC do not propagate outward, nor do changes made elsewhere propagate back. (For more information, see http://support.microsoft.com/kb/275278)
The resolution to this was simple: point the DNS client on the server to a different DC and allow replication to continue. For this reason, many clients I have worked with have configured their DCs to point to other servers as primary (and itself as secondary, usually). The problem with this was that it quickly became chaotic and replication islands would appear for groups of DCs instead of single servers.
This questionable practice has carried over into Windows 2003 AD as well. However, there is good news. Most users/administrators do not know this, but the DNS registration process in Windows Server 2003 was changed to eliminate (or at least reduce to the point of statistical improbability) the possibility of the replication islands mentioned above.
Windows Server 2003 domain controllers now not only register themselves with their primary DNS server (usually themselves), but they also register their addresses with several other DNS servers throughout the domain, thereby ensuring that their record stays fresh and is fully replicated across the domain and/or forest. What this means for administrators is that they do not need to create a chaotic hierarchical DNS registration topology to ensure that no islands form. They can instead set the primary DNS server of the DC to itself and leave it at that. For added emotional security, though, the secondary DNS server can be set to another server in the domain. It is usually expected to be the first server or PDC emulator role holder.
When the domain and forest are configured in Native 2003 mode, you can even store all forest DNS domains on all DNS servers in all domains in the forest. This new configuration adds a new application partition in Active Directory called ForestDnsZones.DnsForestName and stores the DNS records for all AD Integrated zones there. Using this setting can help alleviate complex forwarding configurations in a multi-domain forest situation since it would bring all DNS names to all DNS servers and speed name resolution to the client. There is some additional replication overhead cost, but in my opinion, the benefits greatly outweigh the costs.
So, in summary, a highlight of the best DNS practices with respect to Windows Server 2003 DC/DNS client settings is:
Whatever you decide to do, be sure your configuration is fully documented and consistent. This will help greatly in troublshooting name resolution issues and anything that depends on DNS.
I learned something new last week. It has to do with DNS recursive vs. iterative lookups and how the client workstation handles them.
First of all, for those who don't know, a recursive lookup is basically a name request that is forward on until a correct answer is returned [or a "Nobody knows who that is..." comes back]. This means that a DNS client will ask one server, that server will ask another, and so on until the answer is found and then pass it back along the chain to the original client.
An iterative lookup is when a server receives a request and not knowing the answer asks a higher authority where it can be found and then replies to the request with an answer like "I don't know what you need, but I know someone who does. Here's his address..."
The Windows DNS servers default to recursive lookups. Some people change this behavior. "Why?" you might ask. Well, the reasoning is sound... sort of. Let me explain.
Justification for changing a DNS server from recursive to iterative lookups usually has to do with load. A recursive lookup takes much more energy and cycles on the DNS server than does an iterative lookup. So, when a recursive server queries a name on the Internet, it keeps asking until it has an answer. This could take 1 iteration or 20 depending on how deep the forwarders go of both source and destination. An iterative lookup is only one iteration for the server, which then passes the processing burden to the client who requested it.
Sounds smart when you've got hundreds of thousands of machines querying the server, right? Wrong. Not when those machines are client workstations like Windows XP and Windows Vista. Both of these operating systems, and I suspect all versions of Windows and DOS for that matter ignore iterative referrals. They just drop them. The OS gratefully receives a reply, but does not "chase" or follow up on the referral information that an iterative response contains.
Some have found this out to their detriment by setting all Active Directory DNS servers to perform iterative instead of recursive lookups. This pretty solidly breaks Active Directory. So, DON'T DO IT.
That being said, there are perfectly valid reasons for changing to iterative in some limited cases. For instance, the root servers of the Internet MUST only support iterative requests, not recursive. Mostly, this is due to the immense load placed on them. Also, a stand-alone forwarding DNS server that is outside of the AD infrastructure might be a good place for this, but only if no client workstations point to it.
So - don't use iterative on AD DNS servers or on client facing servers of any type.