DNS Decision Doesn’t Have to be Difficult

[Editor's Note: Share your Exchange and Outlook discoveries, comments, problems, solutions, and experiences with products. Email your contributions (500 words or less) to [email protected]. Please include your phone number. We edit submissions for style, grammar, and length. If we print your submission, you'll get $100.]

When you set up Exchange 2000 Server on a computer running Windows 2000 Server, you can use either the SMTP virtual server's DNS Resolver or Win2K Server's internal DNS component for DNS name resolution. Although the default is to use the SMTP server's DNS Resolver, there are performance-related benefits to using Win2K Server's DNS. If you find these benefits enticing, there are some points to remember when you're configuring Exchange 2000 to use Win2K Server's DNS. If you decide to use the SMTP server's DNS Resolver, you can still improve the performance of your DNS queries by using a simple technique. If you're lucky enough to be running Exchange Server 2003 on a computer running Windows Server 2003, the decision whether to use the SMTP server's DNS Resolver or Windows 2003's DNS might be moot because Microsoft made some significant changes that let Windows 2003 take advantage of the DNS-resolution code in Exchange 2003.

Benefits of Using Win2K Server's DNS
When you use Win2K Server's DNS instead of the SMTP server's DNS Resolver in an Exchange 2000 environment, you'll enjoy several benefits. First, when you use Win2K Server's DNS, you can take advantage of the added functionality of DNS-query caching—both negative-response caching and positive-response caching. In negative-response caching, Win2K Server's DNS keeps a 15-minute database of DNS servers that were unresponsive so that it doesn't waste time relooking them up if a user queries them again. In contrast, the SMTP server's DNS Resolver doesn't have negative-response caching, so a delay will occur each time a user queries an unresponsive DNS server.

In positive-response caching, Win2K Server's DNS keeps successfully resolved DNS records for 1 hour. (Windows 2003's DNS keeps resolved DNS records 1 day.) Positive-response caching greatly improves performance for two reasons:

Points to Remember When Configuring Win2K Server's DNS
If you decide to use Win2K Server's DNS instead of the SMTP server's DNS Resolver in your Exchange 2000 environment, keep in mind the following points when you're configuring your Exchange organization:

How to Improve DNS Query Performance When Using the DNS Resolver
If you decide not to use Win2K Server's DNS, you can still improve the performance of your DNS queries by using the Smtpmd utility. Before you can make any improvements, though, you need to know how the SMTP server's DNS Resolver is performing. However, there are no performance counters for the SMTP server's DNS Resolver, and the SMTP server's DNS Resolver doesn't update the DNS query/sec counter of the SMTP Virtual Server object that you can view with Windows Performance Monitor. Fortunately, you can use the Dnsq tool to check DNS query performance. Dnsq is a DNS debugging utility that's part of Djbdns, freeware designed to replace BIND. You can find the link to download Djbdns in the ZD.Net UK article "Secure your DNS - replace BIND" (http://insight.zdnet.co.uk/hardware/servers/0,39020445,2129897,00.htm).

To have Dnsq test DNS response times, follow the syntax

dnsq mx Domain -s DNS_IP

where Domain is the name of your domain and DNS_IP is the IP address of the DNS server you want to test. So, for example, if you want to determine the DNS response time for the 210.22.70.3 DNS server in the hotmail.com domain, you'd run the command

dnsq mx hotmail.com  -s 210.22.70.3

Although this command appears on several lines here, you would enter it on one line in the command-shell window. (The same holds true for the other multiline commands in this article.)

If you find that your DNS server is performing poorly, you can significantly improve its DNS response times by increasing the number of threads devoted to DNS resolution. By default, only 1 thread is used. To increase the number of threads, you can use the Smtpmd utility to change the /SmtpSvc/1/MaxRemQThreads metabase key. I recommend that you first try 4 or 8 threads. (For a high-performance environment, set the key to 48 threads.) You must also set the /SmtpSvc/1/RoutingThreads metabase key. The RoutingThreads key's value must be a lot higher than the MaxRemQThreads key's value to ensure that local threads are available for delivery. For example, if you set the MaxRemQThreads key to 8, you should set the RoutingThreads key to at least 16.

You can obtain Smtpmd from Microsoft Product Support Services (PSS). To use Smtpmd, follow these steps:

For more information about using Smtpmd, see the Microsoft article "SMTP Queue Backup Occurs Due to Delivery Threads Attempting to Connect to Unavailable Hosts" (http://support.microsoft.com/?kbid=264891).

Improvements in Exchange 2003/Windows 2003 Systems
Microsoft improved DNS-based Internet mail delivery in Exchange 2003/Windows 2003 systems. When you run Exchange 2003 on a Windows 2003 server, your email infrastructure will have load-balancing capabilities, be more tolerant to network unavailability, and be more responsive to external DNS servers—all of which can lead to higher levels of performance. (If you're running Exchange 2003 on a Win2K server, though, you won't experience these benefits.)

Microsoft achieved these improvements by unifying the code paths and expanding the Windows 2003 DNS event to return the DNS server list from the Exchange 2003 DNS Resolver instead of the default global DNS server list when the SMTP virtual server is configured to use external DNS servers for mail delivery. The Exchange 2003 DNS Resolver exposes both the old interface and a new interface. The new interface checks to see whether the domain to be resolved is an external domain, and if so, returns a DNS server list to the Windows 2003 DNS event. Another change is that the SMTP virtual server uses UDP by default instead of TCP.

Another benefit you'll realize if you run Exchange 2003 on a Windows 2003 server is that you can use the Microsoft Windows Server 2003 Resource Kit's Dnsdiag utility to troubleshoot DNS problems. Dnsdiag reports on the asynchronous and synchronous queries to global DNS servers (or the DNS server called by the DNS sink event) and any corresponding failures or errors.

Dnsdiag has the syntaxdnsdiag hostname [d] [options]

where hostname is the Fully Qualified Domain Name (FQDN) of the host you want to query. The optional d switch runs Dnsdiag in debug/verbose mode. Dnsdiag has several other optional switches you can specify:

Because the SMTP service uses the Asynchronous Thread Queue, Dnsdiag and isatq.dll must be in the same directory. Alternatively, you can add %windir%system32inetsrv to the system path.

—William Yang
[email protected]