Although DNS services are fundamentally simple, certain problems frequently appear. Quite often, unclear wording or poorly documented options in various Windows dialog boxes can cause these problems. Let's look at some common DNS annoyances that plague administrators and how you can deal with them.

Dynamic Updates Won't Update
Windows allows clients to dynamically update A and PTR records with DNS servers to help simplify DNS management across a domain. Thus, in an AD-integrated zone, when you assign IP addresses in your organization, client machines can dynamically update AD with their new IP address. Sometimes, however, you might notice that client systems aren't properly updating their DNS records with the new address. To make updating work, you must configure the DNS server to allow dynamic updates. To do so, open the properties for the DNS zone and select Secure only for the Dynamic updates setting, as Figure 1 shows.

Next, on the client, open the network adaptor's Advanced TCP/IP Settings dialog box, select the DNS tab, as Figure 2, shows, and make sure that Register this connection's addresses in DNS option is selected.

Finally, the DHCP client service—not just the DNS client service—handles DNS registration and must run on each system. Even if you don't use DHCP to assign IP addresses, you need the DHCP client service to run on each machine to dynamically update DNS records.

By default, a client will update DNS records upon start-up, or when an IP address or name changes, or when you force it to update by using the ipconfig /registerdns command. Furthermore, the client will reregister its IP address every 24 hours.

DNS Client Service Causes Performance Hits
When the DNS client service starts, it loads all entries in the hosts file to its cache. If you use a very large hosts file to block access to unwanted host names, you might find that this service significantly slows system performance. In such a case, you might want to disable the service.

However, typically, disabling the DNS client service will have no effect on DNS lookups. You might wonder, then, why anyone would need this service in the first place.

The answer is that the DNS client service isn't necessary for name resolution; it just makes name resolution smarter and more efficient. The main purpose of the DNS client service is to provide local caching of DNS entries. The service is, in effect, a DNS server itself. Instead of publishing a database of DNS records, it simply caches previously resolved DNS records to speed up future lookups. Besides caching, the service optimizes network connections by prioritizing resource records based on network location, speed, and availability.

The DNS client service also manages the list of DNS servers configured on a system. As it does with resource records, the service selects the best DNS server from the server list, based on network location, speed, and availability.

Firewall Rules Need to Be Optimized
When you configure a firewall to allow public requests to a DNS server, you want to build rules that won't let others exploit your configuration. DNS queries typically come in on UDP port 53 from a source port greater than 1023. The DNS server responds from source port 53 to the same port used by the client. Most stateful firewalls can handle DNS responses, so a single rule governing requests should be enough.

If a query response is greater than 512 bytes, the DNS server indicates to the client that the response is truncated. The client can resubmit the query using Extended DNS, which allows for larger UDP responses, or the client can resubmit the response by using TCP. If you allow TCP queries, you'll need a rule that allows packets coming in on TCP port 53 from a source port greater than 1023. If you know that your DNS server won't return query responses larger than 512 bytes, you can leave this port closed. Some DNS servers use UDP or TCP port 53 as both their source and destination port for server-to-server queries, so you might also need to configure your firewall to allow this.

How Windows Queries Multiple DNS Servers
By default, Windows first queries the first listed DNS server on the primary network adaptor. If this server doesn't respond within one second, Windows sends the query to the first listed DNS server on any other network adaptors on the system. If it receives no response within two seconds, Windows sends the query to all DNS servers listed on all network adaptors on that system. If none of these servers respond in two seconds, Windows sends the query to all servers again and waits four seconds. If necessary, it resends the query to all servers and waits eight seconds.

Windows adjusts the list of DNS servers it queries depending on network conditions. If none of the DNS servers on an adaptor reply to queries, Windows assumes a network failure has occurred and doesn't query any servers on that adaptor for 30 seconds. If one DNS server on a network adaptor returns a negative response to a query, Windows won't resubmit that query to any other DNS servers on that adaptor. Furthermore, Windows might adjust the order in which it queries DNS servers to favor a server that responds more quickly than others.

GUIs Slow Configuration
If you do a lot of DNS server configuration for client systems, you'd probably like a quicker, easier method than using the Windows GUIs. Try these commands at a command prompt. To list all of a client's DNS servers, type

c:\>netsh interface ip
  show dns 

To clear the list of DNS servers for a network adaptor where "Local Area Connection" is the name of that network adaptor, type

c:\>netsh interface ip 
   set DNS "Local Area Connection"
   static none 

To add a DNS server for a network adaptor where "Local Area Connection" is the name of that network adaptor, type

c:\>netsh interface ip 
 set DNS "Local Area Connection"
 static 192.168.0.1

Domain DNS Problems
Misconfigured DNS settings are a common source of problems with Windows domains. A quick way to check your settings is to perform a lookup for the domain name itself, which you can do with this command:

c:\>nslookup <yourdomain>

The command should return a list of IP addresses that point to each of your DCs. If you get anything else, check your DNS configuration.

You can also test your DNS configuration by performing a quick network configuration test on any Windows XP or Windows Server 2003 system. From a command prompt, type

c:\>netsh diag show test 

This test pings all DNS servers and gateways in your TCP/IP configuration. If you have the Microsoft Windows Server 2003 Resource Kit, you can use the netdiag or dnsdiag commands instead, as follows:

C:\>netdiag /test:dns 

or

C:\>dnsdiag

If you want to test your public DNS servers from the outside, you can use either one of these URLs: http://www.dnsreport.com or http://www.dnsstuff.com. To test to see if a remote DNS server allows zone transfers, use this command:

c:\> echo ls -d <targetdomain>
| nslookup - <nameserver>

If the name server allows zone transfers for that domain, it will return all records in the zone. Otherwise, it will return an error.

BIND Is an Acronym, Not a Verb
In a DNS server's properties dialog box, you'll find the BIND Secondaries setting. BIND isn't a verb—it's an acronym for Berkeley Internet Name Domain, which is an implementation of DNS used for handling DNS requests on the Internet.

When performing zone transfers, the DNS server uses a faster zone transfer method that utilizes compression and can transfer multiple records per TCP message. This format isn't compatible with older versions of BIND. You need to select the BIND Secondaries option if you use a version of BIND earlier than 4.9.4. This option tells the Windows DNS server not to use the faster zone transfer methods.

When to Disable Recursion
Recursion is the process that DNS uses to track down the authoritative server for a domain. If you query a DNS server for a host in a domain and the server isn't authoritative for that domain, nor does the server have a cached copy of the requested host record, the server recursively queries other servers on the Internet on your behalf to track down the DNS server with the correct answer. If a server doesn't do recursion, it either tells the client it doesn't know that record or it tells the client where it might find the record.

To determine when you should disable recursion, you need to look at what types of records the DNS server will hold. If the DNS server for a domain knows all the records for a domain, it should never provide recursion. Your DC, for example, knows about every host in your domain, so there's no need for it to send a request elsewhere. The same is true for a public DNS server that holds published domain records.

You should typically allow recursion on servers that provide DNS lookups for local users. That is, if you provide Internet access to a user, you should also provide that user with a recursive DNS server that can resolve any Internet host name.

It's important not to make recursive DNS servers available outside of your organization. A server could be attacked and used as an amplifier for Distributed Denial of Service (DDoS) attacks.

Internet Host Blocking
Here's a problem that DNS isn't responsible for but that it can partially help you solve. You can block user access to undesirable Internet hosts by using a firewall or a proxy server, but those solutions don't work well for all situations. An ISP, for example, might want to block certain host names without requiring customers to use a proxy server and without putting too much of a load on the firewall. Blocking host names at the DNS server is one alternative.

To do this, you first need a list of hosts to block. You can get a malware block list formatted for Microsoft DNS servers from Malware Block Lists at http://www.malware.com.br/#blocklist. You can directly import this block list into your DNS server. If you're willing to do some reformatting, you can also get block lists from hpHosts Online at http://www.hosts-file.net or Spamassassin Blacklists at http://www.sa-blacklist.stearns.org/sa-blacklist.

Another alternative is OpenDNS (http://www.opendns.com), a free DNS service that provides filtering by blocking known phishing hosts. To use OpenDNS, you just place its DNS server IP addresses in your network configuration.

Keep in mind that using DNS for blocking only prevents name lookups for hosts on these lists. It doesn't prevent users from accessing hosts by entering their IP address, and it can't block new hosts that haven't yet been listed.

Learn the Fundamentals
DNS problems generally have simple solutions, but you do need to have a good understanding of how DNS works. Expand your knowledge of DNS—for any IT professional, it's certainly time well spent.