Introduction to DNS Configuration for Exchange Admins

DNS is one of the core technologies on which the Internet is based. DNS is used for name resolution; it turns a human-readable computer name into an IP address that a computer can use. In addition to the Internet, many Windows Server technologies rely on DNS. Active Directory (AD) depends upon the correct configuration of DNS, and Microsoft Exchange Server in turn depends on the correct configuration of both DNS and AD. Exchange uses DNS for many things, including finding domain controllers and Global Catalog servers within each AD site. Exchange also uses DNS to determine where each individual piece of email should be delivered.

Because DNS is foundational for Exchange Server, every Exchange administrator should know some DNS basics. This includes understanding how DNS should be configured for Exchange and how to verify that DNS has been configured properly for your domains.

DNS Basics
A domain is a group of networked devices that are grouped together under a name that identifies them as a unit. This sounds simple but is actually very powerful. DNS domain names are hierarchical, in a right-to-left direction (where the right-most domain is the top of the hierarchy). The highest-level domain is called the parent domain, the root domain, or the top-level domain (TLD). For example, in a domain named Sales.TheEssentialExchange.com, the parent domain is the part of the name at the far right: com. TheEssentialExchange.com is a subdomain of com. Sales.TheEssentialExchange.com is a subdomain of TheEssentialExchange.com. Exchange Server 2007 SP1 and future releases won’t support domain names consisting of only a TLD (or single-label domain names). This restriction is related to AD intricacies, and you can learn more about how to work with DNS and AD, by reading the articles listed in the Learning Path that accompanies this article.

Separate DNS servers, controlled by different DNS administrators, can administer each level of the domain hierarchy, except the root. ICANN (for more information about ICANN, see http://www.icann.org) identifies and controls all Internet-available roots. In a process known as delegation of authority, a registrar delegates the responsibility for administering each domain (that is not a root domain) to a Name Server (NS). An NS is a specific computer that runs DNS server software. Popular implementations of DNS server software include BIND, Windows DNS Server, and tinydns. This delegation of authority is done by a registrar. A registrar is responsible for registering second-level domains (e.g., Microsoft.com, TheEssentialExchange.com, etc.) to specific name servers. A zone is a collection of domains that share both a namespace and authority—for example, the abc.com zone might contain both the abc.com and foo.abc.com domains, but the bar.abc.com domain might be delegated elsewhere.

You configure zones in DNS by using Resource Records (RRs). RRs let you define computer names, IP addresses, aliases, and many other things. I’ll discuss a couple of RRs specific to email configuration in this article.

You must configure the mail exchanger (MX) RR for each domain that will receive email. The MX record indicates the destination of email for a zone. An MX record must have a Fully Qualified Domain Name (FQDN), not an IP address. Using an IP address in an MX record is a very common configuration error that will prevent your domain from receiving email from many locations.

The FQDN that you specify in the MX record is usually the email server that will receive email for that domain. However, it might also be a gateway server that performs some activity on the email before forwarding it to the final email server for the domain or to the next gateway on the path to the final destination. Gateway servers perform message hygiene activities such as spam and virus filtering, attachment blocking, store-and-forward, and compliance archiving.

DNS Configuration Overview
To receive email, a DNS zone requires a forward lookup entry on the DNS server for the server specified in the MX record and the MX record itself. A forward DNS lookup entry takes an FQDN—for example, a computer name that you type into your Microsoft Internet Explorer (IE) address bar—and turns it into an IP address. A forward lookup would take the FQDN of mail.TheEssentialExchange.com, for example, and translate it into an IP address, such as 64.202.166.12. Computers communicate over the Internet using numeric IP addresses, not FQDNs.

To send email, your DNS zone also needs a reverse DNS lookup entry. As the term implies, a reverse DNS lookup entry takes an IP address and turns it into an FQDN.

An address block must be delegated to a particular DNS server for that NS to be able to authoritatively perform reverse DNS lookups for the addresses in that address block. A reverse DNS lookup entry is created and maintained by whoever is delegated authority for a particular network. All of the reverse DNS lookup entries for that network, taken together, are referred to as the reverse DNS lookup zone for that network. Each IP address in that network should have a reverse lookup entry. If you administer Exchange for a small or midsized company, you probably won’t be able to configure reverse DNS lookup entries for your public IP addresses. Because your ISP is probably the delegated authority, you’ll have to ask your ISP to create a reverse DNS lookup entry for you.

Configuring Forward DNS Lookup
The company that hosts your DNS zone maintains all of the forward DNS lookup entries contained in the zone. Although a company of any size can host its own DNS zone, the hassles involved probably aren’t worth it. Your ISP likely has Web-based control panels that you can use to modify the records in your DNS zones and can provide those tools at a low cost or for free.

To properly configure your forward DNS zone, you first need to create an address record for your mail server. This address record is the forward address entry discussed earlier. To create this record, you need to use the DNS Microsoft Management Console (MMC), if your company self-hosts the DNS zone; otherwise, you should use the tools your ISP provides. The address resource record is represented by an A record. This address record must point to the public IP address where email for the zone should be delivered. This public IP address will probably be your Exchange server’s IP address, and this address must be assigned to you by your ISP. Then, assign the FQDN of that address record to your zone’s MX record. It is possible to use aliases within a DNS zone. Using aliases can minimize the amount of typing required to configure a zone, and it makes possible to provide users with easy-to-remember computer names. The Canonical Name (CNAME) RR specifies both an alias and its target.

For this article, I use TheEssentialExchange.com as a sample zone. The zone file for TheEssentialExchange.com is shown in Figure 1 and is typical for a domain that has only email and a Web site. You might ask whether you’d ever see a zone file. The answer is: It depends. Both BIND and Microsoft DNS Server use zone files to display and record information about the configuration of any given DNS zone. Also, most ISP DNS tools present zone information in a very similar format. Therefore, it makes good sense to be familiar with the format of a zone file. When attempting to determine practically any email issue, you begin your investigation with the zone file (and the data it contains).

When the first character on a line is @, it means that the line refers to the current zone file and that it applies to the entire zone file. In this case, the zone file is named TheEssentialExchange.com.dns and contains all the information for the TheEssentialExchange.com zone.

In Figure 1, the Start of Authority (SOA) record defines administrative information about a zone: the primary name server, the administrative contact’s email address, and the length of time a response is valid after an inquiry is made to a NS.

The NS RRs specify NSs. They define the computers, recorded with the Domain Registrar, that host DNS for the domain.

The MX record points to mail.theessentialexchange.com.

The first zone record is an address (A) RR that contains the address 208.109.181.119. The A RR specifies the IP address that would be used for delivering email if an MX record didn’t exist.

The number (10 in this example) that follows MX in the MX record is the MX weight, which is used to prioritize multiple MX records. The lower the weight, the higher the record's priority; thus, a record having a weight of 10 would be used before a record that has a weight of 20. If multiple records have the same weight, the sending server should choose one randomly.

The line that follows the MX record defines the host that corresponds to the MX record. In this case, the corresponding host has the IP address 64.202.166.12.

If neither an A RR nor an MX RR exists, the email is returned to the sender, because the domain does not accept email.

Finally, there’s a CNAME RR for www that points to the root of the zone. In our example, any time the DNS server receives a DNS query for www.TheEssentialExchange.com, the server will return address information for TheEssentialExchange.com.

Reverse DNS Lookup
Reverse DNS lookup is typically handled by the company that’s responsible for a given network of IP addresses. Delegation of authority for reverse DNS zones is complex. Most ISPs delegate authority for reverse DNS lookup to only large networks. If you administer a midsize or smaller network, to get your reverse DNS configured properly, you have to ask your ISP to set up the reverse DNS lookup entry for your Exchange server’s IP addresses.

In the request you make to your ISP, ask that the ISP create a pointer (PTR) record in the reverse zone for your IP address that references the FQDN for your mail server's public IP address. Check behind the ISP and verify that the ISP has done this properly.

Verifying DNS Configuration
Next, I’ll show you a series of verification tests you can run to ensure that DNS is properly configured for your domain. If DNS is not properly configured for your domain, you may find that email cannot be properly received by your Exchange server or that destination servers will not accept the email that your server attempts to deliver. DNS is the first place to look when you're debugging connections to an email server, or to a destination domain. (Online third-party testing Web sites, such as www.dnsreport.com, can also help you test your DNS configuration.) You can use the Nslookup command to verify that the domain is valid, that an MX record exists, that the MX server has a valid external IP address, and that a reverse DNS lookup entry exists for the IP address. Then, you can use the Telnet command to verify that an SMTP connection can be opened to a destination email server.

The Nslookup command is a tool you can use to interact with a DNS server. You ask questions (called queries) of a DNS server and view the response(s) from the server. You can also choose to use non-default DNS servers for making those queries.

The default question that Nslookup asks a DNS server is: “What is the IP address for the host name I've typed?” Figure 2 shows an Nslookup command that checks the IP address for TheEssentialExchange.com and the resulting output.

The first two lines of output provide the name and IP address of the NS used by Nslookup for checking on TheEssentialExchange.com. If you don’t specify NS as a parameter on the command line, the Nslookup command finds the NSs it uses based on the configuration of the Internet interface of the requesting computer (that is, the computer where the Nslookup command is executed). In Figure 2, the first DNS server located for the requesting computer has an IP address of 192.168.1.10 and the name win2k3r2ee.essential.local.

Next, Nslookup reports that the answer is non-authoritative, meaning that the NS that the command used isn't an authoritative name server (i.e., it isn’t listed in the zone file as one of the name servers for the zone). When you request DNS information from an authoritative name server, the "Non-authoritative answer" line does not appear.

Finally, the output reports that the domain is valid by listing the domain's name and IP address. Had the domain name been invalid, the response would have looked like the output in Figure 3.

To verify the existence of the MX record for the domain, you use the Nslookup command again, but you ask the DNS server a different question. This time, you want to know the value for all MX resource records.

Figure 4 shows the command you can use and sample output. The output is similar to that in Figure 2, but notice that the Nslookup command includes the string -q=mx. This string tells Nslookup to query the DNS server and return information for all the MX records in the zone. The output contains the name of the domain (TheEssentialExchange.com), the MX weight (10), and the name of the mail exchanger computer (mail.TheEssentialExchange.com).

To verify that the MX server has a valid external IP address, use the string -q=a in the query, as shown in Figure 5.

The string -q=a in the query specifies that you’re looking for a valid external IP address. External IP addresses for MX servers are stored in A records. The significance of the output is that a valid address exists. If there were no valid external IP address, you’d see the error "*** No Address (A) records available for mail.TheEssentialExchange.com."

Last but not least, you can use Nslookup to verify that a reverse DNS lookup entry exists for the MX server's IP address. The Nslookup command in Figure 5 provided the MX server’s IP address, and, in Figure 6, we can use that address as input to another Nslookup command to determine whether a reverse DNS lookup entry is available for that IP address. Note that a forward address record (which is what you access with the -q=a query) and a reverse PTR record (which is what you access with the -q=ptr query) are two completely different records in DNS, and both should exist for a proper configuration.

The reverse DNS record is important because many email servers won’t accept email from a remote SMTP server that doesn’t have a reverse DNS record. This record is one part of a comprehensive anti-spam and authentication message hygiene plan.

You need to verify that you can open an SMTP connection to the MX server. You can do so by using the Telnet command.

C:> telnet mail.TheEssentialExchange.com smtp

If you can open an SMTP connection to the MX server, you'll receive a response similar to that shown in Figure 7. The 220 response is typically a single line of output.

If the connection times out or otherwise fails (indicating that you can't access the remote email server), you’ll see the response to the Telnet command shown in Figure 8.

When all these verification tests succeed, then it’s likely that you’ve configured DNS properly for your domain, and Exchange Server will be happy. Congratulations