1.Domain Name System and Its Role in Exchange Server 2007
For computer systems to communicate with each
other, whether you are talking about a local area network (LAN), a wide
area network (WAN), or the Internet, they must have the ability to
identify one another using some type of name resolution. Several
strategies have been developed over the years, but the most reliable one
to date (and the current industry standard) is the use of a DNS.
Accurate
name resolution is critical in a mail environment as well. For a
message to reach its destination, it might pass through several systems
that need to know where it came from and where it is going.
In the past, Microsoft has continued to support
the Windows Internet Naming Service, commonly known as WINS, as an
alternative way of performing name resolution within an environment.
WINS provided a distributed database for registering and querying
dynamic mappings of NetBIOS names for computers and groups. WINS mapped
these NetBIOS names to IP addresses, and was originally designed to
resolve problems that surrounded NetBIOS name resolution in routed
networks.
However, in Microsoft Exchange Server 2007,
support for WINS/NetBIOS broadcasts has been done away with. This makes
the importance of DNS in Exchange 2007 greater than ever because if DNS
is not configured and working properly, Exchange 2007 will not work at
all.
Even Lightweight Directory Access Protocol (LDAP)
queries for local mailbox users require the DNS client to be properly
configured and functioning on your Exchange 2007 servers.
Domain Name System Defined
The Internet, as well as most home and business
networks, rely on Internet Protocol (IP) addresses to allow computers to
connect to one another. If we had to remember the IP addresses of every
website, server, workstation, and printer that we connect to on a daily
basis, it would be very difficult to accomplish anything!
The domain name system, commonly abbreviated as
DNS, is a hierarchical, distributed database used to resolve, or
translate, domain and host names to IP addresses. Using DNS, users,
computers, and applications that query DNS can specify remote systems by
fully qualified domain names (FQDNs).
DNS is the primary method for name resolution
for the Microsoft Windows Server platforms. DNS is also a requirement
for deploying Active Directory (AD), though Active Directory is not a
requirement for deploying DNS. That being said, in a Microsoft Windows
environment, integrating DNS and Active Directory enables DNS servers to
take advantage of the security, performance, and fault-tolerance
capabilities designed into Active Directory.
Using DNS
DNS is composed of two components: clients and servers. Servers store information about specific components.
When a DNS client needs to contact a host
system, it first attempts to do so by using local resources. The client
first checks its local cache, which is created by saving the results of previous queries. Items in the local cache remain until one of three things occurs:
The Time-to-Live (TTL) period, which is set on each item, expires.
The client runs the ipconfig /flushdns command.
The DNS client is shut down.
Next, the client attempts to resolve the query using the local HOSTS file, which, on Windows systems, is located in the %systemroot%\system32\drivers\etc directory. This file is used to manually map host names to IP addresses, and remains in place even if the system is rebooted.
Finally, if the client is unable to resolve the
query locally, it forwards the request to a DNS server for resolution.
The DNS server attempts to resolve the client’s query as detailed next:
If the query result is found in any of
the zones for which the DNS server is authoritative, the server responds
to the host with an authoritative answer.
If the result is in the zone entries of the DNS server, the server checks its own local cache for the information.
If the DNS server is unable to resolve the
query, it forwards the request to other DNS servers, sending what is
known as a recursive query. The server forwards to other servers that
are listed as “forwarders,” or to a set of servers configured in the DNS
server’s “Root Hints” file.
The DNS query is forwarded through
communications channels on the Internet until it reaches a DNS server
that is listed as being authoritative for the zone listed in the query.
That DNS server then sends back a reply—either an “affirmative,” with
the IP address requested, or a “negative” stating that the host in
question could not be resolved.
Understanding Who Needs DNS
Not all situations require the use of DNS. There
are other name resolution mechanisms that exist besides DNS, some of
which come standard with the operating system (OS) that companies
deploy. While not all scenarios have the requirement of a complex name
resolution structure, DNS makes life easier by managing name servers in a
domain sometimes with little overhead.
In the past, an organization with a standalone,
noninterconnected network could get away with using only host files or
WINS to provide NetBIOS-to-IP address name translation. Some very small
environments could also use broadcast protocols such as NetBEUI to
provide name resolution. In modern networks, however, DNS becomes a
necessity, especially in Active Directory environments.
As
stated before, WINS is no longer used by Exchange with the release of
Exchange 2007. The proper installation and configuration of DNS is
critical to the successful deployment of Exchange 2007.
2. Outlining the Types of DNS Servers
DNS is an integral and necessary part of any
Windows Active Directory implementation. In addition, it has evolved to
be the primary naming service for UNIX operating systems and the
Internet. Because of Microsoft’s decision to make Windows 2000 Server
and Windows Server 2003 Internet-compatible, DNS has replaced WINS as
the default name resolution technology. Microsoft followed Internet
Engineering Task Force (IETF) standards and made its DNS server
compatible with other DNS implementations.
Examining UNIX BIND DNS
Many organizations have significant investment
in UNIX DNS implementations. Microsoft Exchange heavily relies on Active
Directory, and Active Directory heavily relies on DNS. Microsoft Active
Directory can coexist and use third-party DNS implementations as long
as they support active updates and SRV records. In some cases,
organizations choose not to migrate away from the already implemented
UNIX DNS environment; instead, they coexist with Microsoft DNS.
Companies using UNIX DNS for Microsoft AD clients should consider the
following:
The UNIX DNS installation should be at least 8.1.2.
For incremental zone transfers, the UNIX DNS implementation should be at least 8.2.1.
Exploring Third-Party (Checkpoint-Meta IP or Lucent Vital QIP) DNS
Third-party DNS implementations can provide
significant enhancements in enterprise class IP management. They either
provide integrated management of UNIX, Linux, and Microsoft DNS and
Dynamic Host Configuration Protocol (DHCP) servers from a central
location or can be used in place of the previously mentioned
implementations. The most recent versions fully support Dynamic DNS
updates, SRV records, and incremental zone transfer, which should be
considered a necessity if Active Directory uses the third-party DNS
servers.
Examining DNS Compatibility Between DNS Platforms
In theory, DNS clients should be able to query
any DNS server. Active Directory, however, has some unique requirements.
Clients that authenticate to Active Directory look specifically for
server resources, which means that the DNS server has to support SRV
records. In Active Directory, DNS clients can dynamically update the DNS
server with their IP address using Dynamic DNS. It is important to note
that Dynamic DNS is not supported by all DNS implementations.
Note
In
a mixed DNS environment, Microsoft specifically recommends using
Microsoft DNS server as the primary DNS server for clients, with other
DNS servers set up as forwarders or secondary zone servers. This is
because Microsoft clients natively support dynamic registration and
lookups against Microsoft DNS.
