DNS Decision Doesn’t Have to be Difficult

The decision whether to use the SMTP virtual server’s DNS Resolver or the Win2K Server’s internal DNS component in Exchange 2000 can be difficult unless you know some important facts.


March 27, 2005

8 Min Read
ITPro Today logo

[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:

  • If you use Win2K Server's DNS for name resolution, the lookups are asynchronous, whereas the SMTP server's DNS Resolver lookups are synchronous. With good hardware and a well–set-up network, Win2K Server's DNS can easily handle 5000 queries per second and scale up to 10,000 queries per second.

  • Exchange connects to the DNS server through a local network connection, which means less network latency—another benefit from using Win2K Server's DNS concerns mail exchanger (MX) records. The SMTP server's DNS Resolver doesn't load-balance equal-priority MX records. Win2K Server's DNS does.

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:

  • The SMTP server will use internal DNS, so you need to configure the root DNS server to forward DNS requests to the external DNS server. For information about how to make this configuration, see the articles "How to Delegate All Internet Top-Level Domains on an Internal Root DNS Server" (http://support.microsoft.com/?kbid=294906) and "Deciding Whether to Deploy an Internal DNS Root" (http://www.microsoft.com/resources/documentation/windowsserv/2003/all/deployguide/en-us/default.asp?url=/resources/documentation/windowsserv/2003/all/deployguide/en-us/dnsbd_dns_vlic.asp).

  • If you're worried about zone transfers to the Internet, you can configure your DNS servers to accept transfers from only internal DNS servers (i.e., DNS forwarders). You should also configure your firewall to not accept unsolicited inbound TCP port 53 requests.

  • As I mentioned previously, Win2K Server's DNS keeps the resolved DNS records for 1 hour by default. You can, however, change this default. For information about how to do so, see the Microsoft article "HOW TO: Modify Time to Live on Domain Name System Records" at http://support.microsoft.com/?kbid=297510. (You can also change the 1-day default in Windows 2003. To learn how, see the article "How to Disable Client-Side DNS Caching in Windows XP and Windows Server 2003," at http://support.microsoft.com/?kbid=318803.)

  • Most DNS forwarders use UDP queries to resolve host names. However, when the query contains too many MX records to fit in a UDP packet (the limit is 512 bytes), the DNS forwarders use TCP packets to obtain and resolve host names. Exchange 2000's SMTP service uses only TCP queries by default. So, if you have security settings on the firewall, you need to make sure both the UDP and TCP 53 ports are opened. For more information about this topic, see the Microsoft article "XCON: Windows 2000 and Exchange 2000 SMTP Use TCP DNS Queries" (http://support.microsoft.com/?kbid=263237).

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 DNS server in the hotmail.com domain, you'd run the command

dnsq mx hotmail.com  -s

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:

  1. Make sure that your Exchange server's SMTP virtual server is at the default location (i.e., LMSmtpSvc1).

  2. Stop the IIS Admin Service.

  3. Open a command-shell window and run the following commands:

    smtpmd set  smtpsvc/1/MaxRemQThreads xsmtpmd set  smtpsvc/1/RoutingThreads y

    where x and y are the desired values for the MaxRemQThreads and RoutingThreads keys, respectively.

  4. Restart the IIS Admin Service.

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:

  • v VSID, where VSID is the number of the target virtual server instance (VSI). If you run Dnsdiag on a computer with an Exchange demilitarized zone (DMZ), you can specify a VSI number to simulate DNS for that SMTP virtual server. Dnsdiag will then read the external DNS server list for that virtual server and query that server list for the host you specified with the hostname parameter when that host is an external server. When the specified host is the name of an Exchange computer, the query is generated against the default DNS server for the local computer.

  • s Server List, where Server List is a list of DNS servers you want to target. This option is incompatible with the v option.

  • p protocol, where protocol is TCP, UDP, or DEF. TCP generates a TCP-only query. UDP generates a UDP-only query. DEF initially generates a UDP query; if that query results in a truncated reply, a TCP query is generated. If you don't specify the p option, Dnsdiag uses the protocol configured in the SmtpSvcUseTcpDns metabase key. This option is incompatible with the option.

  • a. When you specify the a option, Dnsdiag queries all the DNS servers and displays the results of each queried server.

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]

About the Author(s)

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like