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 2010, support for WINS/NetBIOS broadcasts has been done
away with. This makes the importance of DNS in Exchange Server 2010
greater than ever because if DNS is not configured and working properly,
Exchange Server 2010 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 Server 2010 servers.
Domain Name System Defined
The Internet, as well as
most home and business networks, relies 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. 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, non-interconnected 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 Server with the
release of Exchange Server 2010. The proper installation and
configuration of DNS is critical to the successful deployment of
Exchange Server 2010.
