Understanding DNS Query Failure Sensitivity in Exchange 2007 SP1 and SP2

  • Article

Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

 

Applies to: Exchange Server 2007 SP1, Exchange Server 2007 SP2

This topic explains the DNS query improvements that are introduced in Microsoft Exchange Server 2007 Service Pack 1 (SP1) and Exchange 2007 Service Pack 2 (SP2). These improvements reduce the sensitivity to Domain Name System (DNS) errors during the search for a destination messaging server that is outside the Exchange organization. You can adjust the DNS query sensitivity for slightly faster message delivery when DNS errors are encountered for the destination domain. However, depending on the DNS errors, this adjustment may cause delivery failures in certain circumstances.

DNS Queries and Remote Message Delivery

In a typical Exchange 2007 organization, an Edge Transport server that is subscribed to the organization is responsible for delivering messages to external recipients. This Edge Transport server is responsible for accepting the outgoing messages from the Hub Transport server in the organization. The subscribed Edge Transport server must be able to find a destination messaging server that accepts mail for the external recipients. Depending on the destination, the messages are put in one or more remote delivery queues as they await delivery to the remote recipients. For more information about delivery queues, see Managing Queues.

The Edge Transport server queries the configured external DNS servers to find the DNS records that are required to deliver the message. You configure the external DNS server settings on the External DNS Lookups tab in the transport server properties in the Exchange Management Console, or by using the Set-TransportServer cmdlet in the Exchange Management Shell. For more information, see Configuring Transport Server Properties.

The DNS servers that are configured for external DNS lookups are queried in the order in which they are listed. If one of the DNS servers is unavailable, the query goes to the next DNS server on the list. The DNS servers are queried for the following information:

  • Mail exchange (MX) records for the domain part of the external recipient   The MX record contains the fully qualified domain name (FQDN) of the messaging server that is responsible for accepting messages for the domain, and a preference value for that messaging server. A lower preference value indicates a preferred messaging server. The preference value is important if the domain has more than one MX records. To optimize fault tolerance, most organizations use multiple messaging servers and multiple MX records that have different preference values.

  • Address (A) records for the destination messaging servers   Every messaging server that is used in an MX record should have a corresponding A record. The A record is used to find the IP address of the destination messaging server. The subscribed Edge Transport server uses the IP address to open a Simple Mail Transfer Protocol (SMTP) connection with the destination messaging server. Although it is technically possible to use the FQDN of a canonical name (CNAME) record in an MX record, this practice violates RFC 974, RFC 1034, RFC 1912, and RFC 2181, and is therefore not supported by most messaging servers.

    The required combination of iterative DNS queries and recursive DNS queries that start with a root DNS server is used to resolve the FQDN of the messaging server that is found in the MX record into an IP address.

In Exchange 2007, there is an unconfigurable DNS query limit of 5 seconds for each DNS server, and a one-minute limit for the whole DNS query.

Potential DNS Problems

Even when the external DNS settings on the Exchange Transport server are configured correctly, problems with the DNS records for a specific domain or problems with any of the DNS servers that are used to find the authoritative DNS server for a specific domain may still occur. Generally, these problems are beyond your control. You can't fix the problems yourself. These DNS-related errors may be caused by one or more of the following conditions:

  • Invalid DNS records for the destination domain

  • Problems with DNS server utilization

  • Problems with DNS server replication

In the release to manufacturing (RTM) version of Exchange 2007, a problem occurs when a particular domain has a combination of valid MX records and invalid MX records that have the same preference value. An MX record is valid when the FQDN of the messaging server can be resolved to a valid IP address. An MX record is invalid when the FQDN of the messaging server can't be resolved to a valid IP address. In Exchange 2007 RTM, instead of using the valid MX records and discarding the invalid MX records, the DNS query discards all the MX records after the one-minute limit for the DNS query is reached. The remote delivery queue is put in a retry state. Message delivery is not tried again until the configured message retry interval is reached. For more information, see Managing Message Retry, Resubmit, and Expiration Intervals.

Modifying the DNS Query Failure Sensitivity in Exchange 2007 SP1 and SP2

In Exchange 2007 SP1 and SP2, the DNS query behavior has been improved. When a DNS query results in errors, the query continues to the next DNS server only if that DNS server has not already returned an error for the current query.

Exchange 2007 SP1 and SP2 also include a parameter in the EdgeTransport.exe.config application configuration file that is named DnsFaultTolerance. This parameter has the following values:

  • Lenient   When the DNS query encounters a combination of valid MX records and invalid MX records, the DNS query continues until the DNS query time-out value of one minute is reached. The invalid MX records are discarded. And the valid MX record that has the lowest preference value is used to deliver the message to the destination messaging server.

  • Normal   When the DNS query first encounters an invalid MX record, any resolved MX records that have a preference value that is greater than or equal to the invalid MX records are immediately discarded. The remaining MX record that has the lowest preference value is used to deliver the message to the destination messaging server without waiting for the whole DNS query to time out. Although this behavior may result in faster message delivery, the potential drawback of this behavior is the DNS query may have no valid MX records if the following conditions are true:

    • The invalid MX record is the first MX record for the destination domain.

    • The valid MX records have the same precedence value as the invalid MX records

The default value of the DnsFaultTolerance parameter on a Hub Transport server or Edge Transport server in Exchange 2007 SP1 and SP2 is Lenient.

In both Normal mode and Lenient mode, the results of the DNS query for an invalid MX record are never cached. The next time that a DNS query is executed, it will try to resolve the MX records for the destination domain.

The EdgeTransport.exe.config application configuration file is located in the C:\Program Files\Microsoft\Exchange Server\Bin directory. The EdgeTransport.exe.config file is an XML application configuration file that is associated with the EdgeTransport.exe file. EdgeTransport.exe and MSExchangeTransport.exe are the executable files that are used by the Microsoft Exchange Transport service. This service runs on every Hub Transport server or Edge Transport server. Changes that are saved to the EdgeTransport.exe.config file are applied after the Microsoft Exchange Transport service is restarted. The default value is enforced if either of the following conditions is true:

  • A configuration option is missing.

  • A configuration option is present and contains the default value.

The following example shows the typical structure of the EdgeTransport.exe.config file:

<configuration>

<runtime>

<gcServer enabled="true" />

</runtime>

<appSettings>

<add key="Configuration Option" value="Value" />

...

</appSettings>

</configuration>

You can add new configuration options or modify existing configuration options in the <appSettings> section.

Changes to the EdgeTransport.exe.config application configuration file take effect after the Microsoft Exchange Transport service is restarted.