Secure Updates

A simple yet very effective way to ensure that your DNS records are only updated by the client who owns the record is to make sure that the Secure Only option is used in the DNS console as shown in the following screenshot:

Secure Dynamic Updates is a mechanism where the DNS server does not register new IP addresses if a secret key, generated on first registration, does not match, or is missing from an update request.

Secure Dynamic Updates is the default in Windows 2000 and 2003, and unless you have a very specific reason for doing so, you should not change this option. By changing it to "None" or "Non-secure and Secure", you leave yourself open to the dummy creation of DNS records by clients who are not a part of your domain, resulting in a DoS, or DNS poisoning. If the DoS attack is aimed at exhausting disk space, then your replications will also become extremely slow as the Zone files become huge. This in turn can stop your AD data from being replicated. As you can see, a simple thing can turn into a chain reaction of negative events.

Split Zone DNS

Split Zone DNS, also called split namespace DNS, is a way of separating your internal and external DNS records. If your company uses the same DNS name for the AD and the Internet presence (as is the case for nailcorp.com), you would have an internal DNS infrastructure that contains all of the internal records of the AD, and an external DNS that contains DNS entries only relevant to external users. External records could be something like http://www.nailcorp.com, http://mail.nailcorp.com, and http://vpngateway.nailcorp.com, which would allow visitors to access the website and allow email to find its way, while remote users would have a friendlier name to access the VPN gateway. However, as these are the only records for the external nailcorp.com domain, it is impossible for someone outside to resolve, for example, intranet.nailcorp.com, dc01.nailcorp.com or any other internal name.

Exposing your internal DNS records will provide a wealth of information to anyone attempting to break into your network and your AD.

Active Directory Integrated Zones

According to Microsoft's DNS best practices article (http://technet2.microsoft.com/windowsserver/en/library/66add8fa-0348-4cc4-94d1-6d68127290881033.mspx), you should, wherever possible, use AD integrated zones. For AD Disaster Recovery, this is the recommended DNS implementation strategy. It affords you full integration with AD, and is therefore just as distributed and replicated as your AD infrastructure. Integrated Zones put the DNS zone files within the AD replication and data files. Depending on the option you select, you can push to all DNS servers within the AD, to all the DCs, or both if your DCs are also DNS servers. You can move your zones to AD integrated, and remove them quite easily within the properties of the zone in the DNS console, as shown in the following screenshot:

If you have adequate bandwidth between all the DNS servers, it is a good idea to push the zone files to all the DNS servers within the forest, in order to provide efficient trusts and lookups between all the domains in one forest, . If you have large locations with a lot of dynamic updates, such as through the DHCP updates, then you might consider just pointing stub zones to the main DNS server of the domain in question. This way, your clients will resolve all the client names, as the client looks them up from the correct DNS server, but you won't waste precious bandwidth by replicating all of the DNS data, to all of the servers, all of the time.

Consider, however, that for a good failover, a DNS server should have a partner or peer to which the zone gets replicated. This can be a secondary DNS server or an AD integrated DNS server, but it should be in a different location. Please be aware that a secondary DNS server here refers to the traditional DNS model, which is a single master with several slave or secondary servers. Updates, traditionally, could only be made to the single master, and were then replicated through requests to the slave servers.

AD Integrated Zones are actually stored within the AD data store, and are therefore part of the AD data replication. AD Integrated Zones are also multi-master, similar to AD itself. This means that changes can be made to each DC, and then replicated to all the other DCs in the infrastructure. This provides quite a few benefits, besides just allowing you to scale your network, by combining DNS replication with AD replication and compressing the traffic.

As DNS information is part of the AD, you can apply some of the AD security features , such as ACLs, to DNS records such as ACLs to secure them. Also, all of the records are automatically replicated to each new DC when records are added. Of course, in relation to Disaster Recovery, the zones are backed up with the AD data, and can be restored as such.

Configuring DNS for Failover

Failover mechanisms are built into DNS right from the beginning, through the primary and secondary model. This means that if the primary DNS server is down, the secondary will answer and, possibly with a little delay, provide the result of the request to the client.

The problem begins with providing the client with the IP address of the secondary DNS server. Many times, the secondary or tertiary DNS server is located within the same network and the same location. This, of course, presents the problem of single point of failure. Whilst a hardware failure of one DNS server is easily covered by the secondary server, and the client won't notice anything, the loss of the entire server room will cause the clients to get nowhere and have no DNS server from which to query. If there are multiple locations within an organization, the secondary DNS server should always be located in another building, or even city. As long as the secondary server contains a frequently-updated zone file, which it will when using AD integrated DNS servers and primary or secondary DNS servers that all are part of the same DNS zones, the clients will query the secondary server when the primary is offline, and will receive an answer and therefore be able to authenticate. The AD SRV locators are given to the client for authentication servers. An example of this configuration can be seen in the following figure:

DHCP within AD

Dynamic Host Configuration Protocol (DHCP) has many functions and allows you to tell the clients on your network how to access the network. In AD, DHCP servers need to be authorized before they are allowed to serve IP addresses.

DHCP can be be tightly integrated with the DNS server, to update the DNS records as the IP addresses are given. Many times, a malfunction in the DHCP server, or misconfiguration, is the cause of problems within an AD infrastructure.

In order to make sure the DHCP server IP addresses is working and serving, make sure it has been properly authorized and that all of the configuration necessary for your network are in the scope of the DHCP servers. This way, your clients can always access the AD.

The DHCP server data, the address leases and so on, are not replicated within the AD. Details of which servers are the DHCP servers, however, is replicated and known in the AD. When talking about Disaster Recovery, it is necessary to ensure that when a machine is recovered, the DHCP service is configured correctly and authorized to serve again.