Diagnosing Problems Arising from Host Resolution Protocols

The DNS host resolution protocol converts common names into IP addresses. DHS host resolution is used frequently when clients interact with Exchange or Exchange interacts with other mail servers. Most of the time, host resolution occurs seamlessly without anyone knowing about it. Host resolution occurs when a client attempts to download or send mail via an Exchange server, when a front-end server communicates with a back-end server, or when an Exchange server contacts a remote SMTP server across the Internet to deliver mail. Host resolution can cause problems with the incoming and outgoing mail server queues. In general, external host resolution causes problems with the outgoing mail server queue, and internal host resolution causes problems with the incoming mail server queue.

Diagnosing Problems Arising from DNS

Because Windows 2000 DNS has overtaken WINS as the core hostname resolution protocol supporting Windows networks, it is unlikely that you will see WINS mentioned on the Exchange Server 2003 exam. DNS translates fully qualified domain names (FQDN) to IP addresses and back.

By default, an Exchange server uses the preferred and alternate DNS server settings configured in the networking properties. As an alternative, the SMTP virtual server can also be configured with separate external DNS servers. This can be achieved by editing the properties of the SMTP virtual server, selecting the Delivery tab, and clicking the Advanced button. Clicking the Configure button allows you to configure particular external DNS servers, as shown in Figure 10.2, for this particular virtual server's name resolution.

Figure 10.2. Exchange Server 2003 allows special DNS servers to be configured for external name resolution.

The specific external DNS server settings override the preferred and alternate DNS server settings in the network configuration.

Using nslookup

Nslookup is a powerful command-line tool that is used to query DNS servers. By default, nslookup queries the preferred and alternate DNS servers that are configured on a computer.

For example, you can check whether an Exchange server can resolve external addresses by running a command prompt and typing:

 nslookup www.examcram2.com 

If DNS resolution is working, nslookup returns the IP address of the Exam Cram 2 Web site. Similarly, you can use nslookup to determine if the computer on which you are running it can resolve internal hostnames in a similar fashion.

Nslookup can also be configured to query DNS servers that are not the preferred or alternate. This is useful if a special external DNS server is configured in the SMTP virtual server advanced properties. You can check resolution for any DNS server by using the following switch for the nslookup command:

 nslookup www.examcram2.com external_server 

In the preceding syntax, external_server is the IP address or FQDN of the special external DNS server.

A final option that Exchange administrators find useful is to locate the SMTP server for a particular domain by using nslookup to determine which particular host in a domain acts as a mail server. For example, to locate the mail servers for the examcram2.com domain, issue the following command:

 Nslookup  querytype=mx examcram2.com 

This displays a list of the MX records for the examcram2.com domain as well as the preferences assigned to each record.

You might want to perform the nslookup querytype=mx domain.name on your own mail domains if there are problems with receiving incoming mail. This is a quick way to determine if the MX records have been configured properly in DNS.

Problems with the DNS Client

The IP address configuration of an Exchange server can be configured statically or via a client reservation on the Dynamic Host Configuration Protocol (DHCP) server. Information about which DNS servers the client has been configured to use can be discovered by issuing the ipconfig /all command. Remember, though, that any custom DNS server settings in the SMTP virtual server are not displayed in such a report.

DNS clients often have a preferred and an alternate DNS server set. The alternate server is used if the preferred server is not available or is unable to resolve the query. There can be multiple alternate servers, and each are queried in succession until the request is resolved or all have been tried.

Exchange servers, depending on their role, might need different DNS client settings than other computers in the organization. For example, many organizations use internal DNS servers that are unable to resolve external hostnames, as the computers on their network do not require this functionality. If an Exchange server is configured to use internal DNS servers that cannot resolve external hostnames, it cannot route email to addresses outside the organization.

An Exchange Server 2003 computer that is configured to route mail through a smart host does not need to be able to resolve external hostnames. This task is handled by the smart host.

Smart Hosts

Smart hosts are Windows Server 2003 or Windows 2000 Server computers that are located on the screened subnet and are configured to relay SMTP traffic from the Internet to the internal network. If the SMTP connector on an Exchange server is configured to use a smart host, the smart host needs to be able to resolve internal and external hostnames via DNS. Smart hosts are different than forwarders, though smart hosts can use a DNS server configured as a forwarder to resolve external hostnames. The same problems that can apply to Exchange servers as DNS clients can also apply to smart servers. If the smart server is unable to resolve an external hostname, it cannot route mail to that hostname. Problems at the smart host do not lead to a rise in the length of the outgoing mail queue. It leads to a rise in the incidence of nondelivery reports when the smart host returns the undelivered email.

If there are problems with external hostname resolution and a smart host is in use, you should look toward the smart host rather than the Exchange server to diagnose the problem. When smart hosts are in use, it is they, not the Exchange server, that are responsible for external name resolution. When the problem is a smart host, there is a greater instance of nondelivery reports. When the problem is with the Exchange server, the size of the external mail queue rises.

Problems with the DNS Server

It might be that the configuration of the DNS client is correct, but the DNS server itself is not configured correctly for the task that it must perform. DNS servers can be configured in a variety of different ways, each of which is appropriate for a particular situation. After you are certain that the Exchange server or smart host is configured correctly, the next step in your diagnosis should be to look at the DNS server that the client is configured to use.

Limitations of DNS Forwarders

When a DNS server is configured as a forwarder, it forwards all queries that it cannot locally resolve to a specified server. Forwarders are often placed on screened subnets (also known as DMZs) so that port 53 on the firewall only has to be opened for one host. Queries can then be forwarded from the internal network to the forwarder, which can then have these queries processed by a trusted DNS server outside the network perimeter.

Internal DNS servers can either be configured to forward unresolved DNS queries on to the forwarder, or clients can be configured to use the forwarder as their alternate DNS server.

Look for several problems when forwarders are being used:

• Internal DNS servers point to the wrong forwarder IP address. If this is the case, external queries cannot be resolved.

• The forwarder on the screened subnet points at the wrong IP address, or the ISP's DNS server fails. In either case, the forwarder needs to be reconfigured for external DNS resolution to occur.

• The firewall is configured to block port 53 access to the forwarder. Until this is resolved, the forwarder cannot forward queries to the ISP's DNS server.

• In a multiple tree forest, a query for a host that might reside in another tree might be forwarded to an external DNS server rather than to a DNS server in another tree. Unless properly configured, a DNS server assumes that a domain in another tree is external to the forest.

It might be that you need to configure your Exchange Server 2003 computer or smart host to use a forwarder to resolve external queries. It also might be that your Exchange Server 2003 is configured to use a DNS server that in turn uses the forwarder. Being aware of the role that a forwarder plays in the chain of DNS resolution can be important when diagnosing problems with external hostname resolution.

Limitations of Active Directory (AD) Integrated Zones

AD integrated zones are used to replicate DNS information. By default, an AD integrated zone is only replicated within the domain in which it is created. When you create a new child domain, this information is added to the zone file of the parent domain. If you install DNS on a domain controller (DC) in the child domain, the zone information from the parent domain, which includes hostnames from the child domain, is not replicated. Windows Server 2003 allows you to replicate zone information throughout the forest, although this is not the default setting of Active Directory integrated zones.

In a multitree Active Directory forest, the replication of zone information throughout the forest aids Exchange immeasurably. In such an environment, it is likely that there are Exchange servers located in many different domains. If name resolution is not working properly, there might be difficulty in routing messages internally.

Secondary Zones

Unlike Windows 2000 Server, secondary DNS servers for primary zones hosted off Windows Server 2003 must be explicitly authorized on the primary DNS server. If the secondary DNS server is not explicitly authorized, no zone transfer can take place. Secondary zones can be hosted off both Windows Server 2003 domain controllers and Windows Server 2003 member servers.

If Exchange Server 2003 is relying upon a secondary DNS server for hostname resolution, ensure that the secondary server updates its zone file on a regular basis.

Secondary DNS zones are a good solution when you might be sending traffic to a partner organization that your company connects to via a wide area network (WAN) link rather than through the Internet. You can host the partner organization's secondary zone on one of your DNS servers and let Exchange resolve queries to the partner organization in this manner.

Stub Zones

Stub zones are abbreviated zone files that can be replicated via Active Directory. They store only the authoritative name server records for the zone for which they are configured. They are extremely useful when a zone delegation has taken place because they can allow the server hosting the parent zone to maintain an automatically updated list of name servers for the child domain. In complex Exchange environments, in which DNS responsibilities have been delegated, stub zones can ensure that Exchange servers in child domains can easily be located by Exchange servers in parent domains. Without stub zones, if the administrators of the child domain move the name server that the parent domain considers authoritative, queries cannot be forwarded to the downstream servers accurately.

It does not matter if a client's DNS settings are correct or if the DNS server is fully operational if the client's network configuration is incorrect. For example, if an Exchange server's default gateway is incorrectly set, and the DNS server resides on a remote subnet, it does not matter whether the DNS server can resolve external queries because the Exchange server will not be able to contact it!