Understanding DNS Requirements for Exchange Server 2003

In Active Directory, all client logons and lookups are directed to local domain controllers and GC servers through references to the SRV records in DNS. Each configuration has its DNS and resource requirements. In a member server configuration, Exchange relies on other servers for client authentication and uses DNS to find those servers. In an Active Directory domain controller configuration, on the other hand, the Exchange server also participates in the authentication process for Active Directory.

Exchange 5.5 and E2k3 DNS/WINS Name Resolutions Requirements

Exchange 5.5 and NT4 use different name resolution orders when trying to resolve a name. NT4 relies on the local hostname, HOST, DNS NetBIOS name cache, WINS, B-Cast NetBIOS broadcasts, and the LMHOSTS file for name resolution. Windows 2000 and higher clients , on the other hand, use a significantly different approach for name resolution. Windows 2000 uses hostname resolution first, rather than NetBIOS name resolution techniques. In addition, a local cache is used to reduce network traffic.

Windows NT servers and Exchange 5.5 servers find Exchange 2003 servers via DNS, but name resolution might be slightly slower because of the order previously outlined. Windows 2003 and Exchange rely on DNS, so these servers must be part of a DNS name resolution schema. When older clients and servers are used that do not have DNS as the primary name resolution, it is best to add Windows 2003 servers and Exchange server to the WINS database staticallydirectly to the WINS databaseor dynamicallyadding the WINS server IP address under the TCP/IP configuration section.

TIP

When migrating from Windows NT4, one of the first tasks is to update the DNS server to a version that supports dynamic updates and, most importantly, SRV records.

DNS and SMTP RFC Standards

In 1984, Paul Mockapetris was responsible for designing the first DNS architecture. The result was released as RPC 882 and 883. These were superseded by RFC 1034 (Domain Namesconcepts and facilities) and 1035 (Domain Names implementation and specification) the current specifications of the DNS. RFCs 1034 and 1035 have been improved by many other RFCs, which describe fixes for potential DNS security problems, implementation problems, best practices, and performance improvements to the current standard.

RFC 2821 defines the SMTP, which replaced the earlier versions of RFC 821 and 822.

Virtual SMTP Servers

The SMTP protocol is an essential part of Exchange 2003 and Active Directory. Although Exchange 4.x and 5.x messaging is primarily based on X.400 mail transfer standards, Exchange 2000 and 2003 are native SMTP messaging systems. However, when an Exchange 2000/2003 server has to communicate to an Exchange 5.5 server, it still uses the MTA and x.400 for communication.

A single virtual SMTP server runs by default on all Exchange 2003 servers. In most cases, this is the SMTP server needed for external and internal communications. An administrator might want to install an additional SMTP virtual server for the following reasons:

• To maintain multiple domain namespaces on the same server

• To establish different authentication methods for different users or groups

• To configure different SMTP options to different users

Routing Groups

A routing group is a collection of servers that enjoy a persistent high-bandwidth connection and it's used to organize server communication based on bandwidth constraints. All servers within a routing group communicate with each other directly when transferring mail. This is also known as mesh topology . Reasons for setting up routing groups include the following:

• Low speed or unreliable connection between Exchange servers

• Administrators wanting more control over the message flow within the organization

• Fault tolerance or high availability between routing groups

Exchange messages can be routed from sender to recipient the following ways:

• With sender and recipient located on the same server

• With sender and recipient located in the same routing group

• Between routing groups

• To a server outside the Exchange organization

The preferred method for connecting routing groups in Exchange is via the routing group connector. Routing groups themselves do not use a particular protocol, but will use SMTP for all traffic to and from Exchange 2000/2003 servers and Remote Procedure Calls (RPCs) for Exchange 5.5 servers. Email routing between routing groups is funneled through the bridgehead server, which is fully configurable on a perrouting group basis.

Mixed Environment Mail Routing

Companies with multiple email systems usually use SMTP mail transport between these dissimilar systems. Microsoft Exchange 2003 can connect to any other RFC-compliant SMTP gateway. It also supports authenticated and secure transfer between SMTP gateways.

SMTP Mail Security, Virus Checking, and Proxies

Spamming and security issues are daily concerns for email administrators. As the Internet grows, so too does the amount of spam that mail servers have to confront. Unwanted messages not only can take up a lot of space on mail servers, but can also carry dangerous payloads or viruses. Administrators have to maintain a multilayered defense against spam and viruses.

There are several security areas that have to be addressed:

• Gateway security to control access to the mail server delivering messages to/from the Internet

• Mail database security where messages are stored

• Client mail security where messages are opened and processed

Gateway security is a primary concern for administrators because a misconfigured gateway can become a gateway used by spammers to relay messages. Unauthenticated message relay is the mechanism spammers rely on to deliver their messages. When a server is used for unauthenticated message relay, it not only puts a huge load on server resources, but also might get the server placed on a spam list. Companies relying on spam lists to control their incoming mail traffic refuse mail delivered from servers listed in the database; therefore, controlling who can relay messages through the mail relay gateway is a major concern.

Application-level firewalls allow mail proxying on behalf of the internal mail server. Essentially, mail hosts trying to connect to the local mail server have to talk to the proxy gateway, which is responsible for relaying those messages to the internal server. Going one step further, these proxy gateways can also perform additional functions to check the message they are relaying to the internal host or to control the payload passed along to the internal server.

This configuration is also helpful in stopping dangerous viruses from being spread through email. For example, dangerous scripts could potentially be attached to email, which could execute as soon as the user opens the mail. A safe configuration allows only permitted attachment types to pass through. Even those attachments have to pass virus checking before they are passed to an internal mail server. Figure 7.5 illustrates the schematics of how an application gateway works.

Figure 7.5. Application gateway.

The following process describes how one server contacts another server to send email messages that include virus checking:

1. The sender contacts its SMTP gateway for message delivery.

2. The SMTP gateway looks up the MX record for the recipient domain and establishes communication with it. The application proxy acting as the SMTP server for the recipient's domain receives the message. Before the recipient gateway establishes communication with the sender gateway, it can check whether the sender SMTP gateway is listed on any known spam lists. If the server is not located on any spam lists, communication can resume and the message can be accepted by the proxy server.

3. The application proxy forwards the message for virus checking.

4. After virus checking, the mail is routed back to the application proxy.

5. Mail is delivered to the internal SMTP gateway.

6. The recipient picks up the mail message.

NOTE

Application proxy and virus or spam checking might be done within the same host. In that case, steps 25 are done in one step without having to transfer a message to a separate host.

Third-party products can be used for virus checking not only at the gateway level, but also directly on an Exchange email database. Database level scans can be scheduled to run at night when the load is lower on the server; real-time scans can perform virus checking in real time before any message is written to the database.

The final checkpoint for any multilayered virus protection is on the workstation. The file system and the email system can be protected by the same antivirus product. Messages can be scanned before a user is able to open the message or before a message is sent.

Protecting email communications and message integrity puts a large load on administrators. Threats are best dealt with using a multilayered approach from the client to the server to the gateway. When each step along the way is protected against malicious attacks, the global result is a secure, well-balanced email system.

SMTP Server Scalability and Load Balancing

In a larger environment, administrators might set up more than one SMTP server for inbound and/or outbound mail processing. Windows Server 2003 and Exchange Server 2003 provide a very flexible platform to scale and balance the load of SMTP mail services. DNS and Network Load Balancing (NLB) are key components for these tasks.

Administrators should not forget about hardware failover and scalability. Multi-network interface cards are highly recommended. Two network cards can be teamed together for higher throughput, can be used in failover configuration, or can be load-balanced by using one network card for front-end communication and another for back-end services, such as backup.

Network design can also incorporate fault tolerance by creating redundant network routes and by using technologies that can group devices together for the purpose of load balancing and delivery failover. Load balancing is the process where requests can be spread across multiple devices to keep individual service load at an acceptable level.

Using NLB, Exchange Server SMTP processes can be handed off to a group of servers for processing, or incoming traffic can be handled by a group of servers before it gets routed to an Exchange server. The following example outlines a possible configuration for using NLB in conjunction with Exchange. Figure 7.6 illustrates the layout of the message flow.

Figure 7.6. Message flow with NLB and Exchange Server 2003.

DNS, in this example, has been set up to point to the name of the NLB cluster IP address. Externally, the DNS MX record points to 196.8.10.15 as the mail relay gateway for companyabc.com . Exchange server uses smarthost configuration to send all SMTP messages to the NLB cluster. The NLB cluster is configured in balanced mode where the servers share equal load. Only port 25 traffic is allowed on the cluster servers. This configuration would offload SMTP mail processing from the Exchange servers because all they have to do is to pass the message along to the cluster for delivery. They do not need to contact any outside SMTP gateway to transfer the message. This configuration allows scalability because when the load increases , administrators can add more SMTP gateways to the cluster. This setup also addresses load balancing, because the NLB cluster is smart enough to notice whether one of the cluster nodes has failed or is down for maintenance. An additional ramification of this configuration is that message tracking will not work beyond the Exchange servers.

NOTE

Administrators should not forget about the ramifications of antivirus and spam checking software with NLB. These packages in gateway mode can also be used as the SMTP gateway for an organization. In an NLB clustered mode, an organization would need to purchase three sets of licenses to cover each NLB node.

A less used but possible configuration for SMTP mail load balancing uses DNS to distribute the load between multiple SMTP servers. This configuration, known as DNS round robin , does not provide as robust a message routing environment as the NLB solution.