With Microsoft Exchange relying on
Active Directory and domain name system (DNS) to function, it is
important for an organization to make sure that critical networking
services are configured and operating properly and that domain
controllers have been deployed and configured to adequately support the
environment. Exchange Server 2013 has removed its reliance on NetBIOS
and Windows Internet Naming Service (WINS) for its networking services
and is now very dependent upon the successful operation of Active
Directory and DNS.
Domain Name System and Its Role in Exchange Server 2013
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.
Even
Lightweight Directory Access Protocol (LDAP) queries for local mailbox
users require the DNS client to be properly configured and functioning
on your Exchange Server 2013 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 the first DNS server in the list in the network
configuration that responds 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
one of 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. Although 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.
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, Windows Server 2003,
and Windows Server 2012 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 Service (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.
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.
Examining DNS Components
As
previously mentioned, name servers, or DNS servers, are systems that
store information about the domain namespace. Name servers can have
either the entire domain namespace or just a portion of the namespace.
When a name server only has a part of the domain namespace, the portion
of the namespace is called a zone.
DNS Zones
There
is a subtle difference between zones and domains. All top-level
domains, and many domains at the second and lower levels, are broken
into zones—smaller, more manageable units by delegation. A zone is the
primary delegation mechanism in DNS over which a particular server can
resolve requests.
A
name server can have authority over more than one zone. Different
portions of the DNS namespace can be divided into zones, each of which
can be hosted on a DNS server or group of servers.
Forward Lookup Zones
A
forward lookup zone is created to do forward lookups on the DNS
database, resolving names to IP addresses and resource information.
Reverse Lookup Zones
A
reverse lookup zone performs the opposite operation as the forward
lookup zone. IP addresses are matched up with a common name in a
reverse lookup zone. This is similar to knowing the phone number but
not knowing the name associated with it. Reverse lookup zones must be
manually created, and do not exist in every implementation. Reverse
lookup zones are primarily populated with Pointer (PTR) records, which
serve to point the reverse lookup query to the appropriate name.
Tip
It is good practice for the Simple
Mail Transfer Protocol (SMTP) mail server to have a record in the
Internet-facing reverse lookup DNS zone. Spam control sites check for
the existence of this record. It is possible to have outbound mail
rejected as spam if the site does not have a PTR record for the Mail
Exchange (MX) entry in the DNS reverse lookup zone.
