DNS is one of the most mission-critical
components used by today’s Windows networks. DNS name resolution is a
process that translates computer names to IP addresses and vice versa.
In this section, we will explore what DNS is and how it works. It is
important to understand how to set up, configure, and manage DNS before
deploying a Windows Server 2008 R2 network. If the DNS services break,
so does your network. We will then discuss designing and then deploying
DNS services. We will finish our DNS discussion by exploring how to
administer and troubleshoot Windows Server 2008 R2 DNS services.
Overview of name resolution and DNS
Before setting up and configuring DNS, it is
important to understand how name resolution works and why it is needed
by Windows networks. Like most other network services covered in this
chapter, you need to understand what is going on “under the covers” to
really grasp how the service works and why it is important.
DNS at a basic level is performing one main function,
resolving names to IP addresses. Earlier in this chapter, you learned
that computers use TCP/IP to communicate and that each computer is given
a unique IP address. For computer A to talk to computer B, computer A
must know the IP address of computer B. IP-based communication poses a
small problem to humans. How do you remember all of those IP addresses?
Think about having to remember the IP address of your 20 favorite Web
sites on the Internet (remember all computers, even Web servers hosting
Web sites, require IP address-based communication). Luckily, this is
where DNS helps. DNS allows us to remember a name known as a Fully
Qualified Domain Name (FQDN) instead of the IP address of the computer that we are trying to reach. We can reach www.bing.com or www.microsoft.com
by simply typing the Web address, also known as the FQDN. DNS then
translates this FQDN to an IP address. After DNS translates the name to
IP address, your computer connects to that address. So how exactly does
all of this work? The example below will take you through the Windows
name resolution process.
Your computer would like to access the Web site www.bing.com.
Your
computer’s DNS client service sends a name resolution request to the
DNS Server whose IP address is listed in the DNS Servers section of the
computer’s IP configuration. We will refer to this server as the local
DNS Server.
The
local DNS Server receives the request and determines if it should host
the domain name being requested. If it does host the domain, then it
looks up the DNS record and returns it to the client. If it does not
host the domain, the local DNS Server queries a root DNS Server for the
IP address of the .com DNS Server.
Once
the IP of the .com DNS Server is received, the local DNS Server queries
the .com DNS Server for the IP address of the bing.com DNS Server.
The local DNS Server then queries the bing.com DNS Server for the IP address of www.bing.com.
Your client computer then receives the IP address of the www.bing.com server from your local DNS Server. Figure illustrates this process.
DNS zones
DNS Servers host zones which in turn host records
that resolve a name to an IP address. The zone is the authoritative
source for information about the domain name managed by that zone. A DNS
zone is typically the same as the domain name being hosted on the DNS
Server. For example, if the DNS Server will be hosting the domain
syngress.com, then the zone syngress.com must be created on the DNS
Server. There are two Primary zone types that can be set up on a DNS
Server—Forward Lookup Zones and Reverse Lookup Zones.
Forward Lookup Zones
—Forward Lookup Zones allow the DNS Server to resolve queries where the
client sends a name to the DNS Server to request the IP address of the
requested host.
Reverse Lookup Zones
—Reverse DNS zones perform the opposite task as Forward Lookup Zones.
They return the fully qualified domain name (FQDN) of a given IP
address. For example, a client could send the IP
address of 69.163.177.2 to a DNS Server. If the server hosted a reverse
zone that included that IP address, it would return the FQDN for that
address, such as www.syngress.com.
In addition to the standard zone types, DNS zones can be further broken down into the following zone types:
Primary zone (stored in AD) —These zones are stored in AD and replicated via
normal AD replication. This provides an optimized way to replicate the
zones within your corporate network. Primary zones stored in AD follow
the same multimaster rules as other AD services. This means that you can
perform updates on any AD Domain Controller and they will replicate to
the other Domain Controllers.
Primary zone (standard) —Standard Primary zones are stored in a flat file on the DNS Server. The Primary zone is considered the master copy of the zone database file. All updates to the zone must be performed on the Primary zone server.
Secondary zone
—Secondary zones are read-only copies of the Primary zones. Secondary
zones replicate a copy of the zone from the Primary zone server to
provide redundancy. Any updates to the zone must be performed on the
Primary zone server.
Stub zone
—Stub zones are similar to Secondary zones in that they are read-only
copies of the zone database file. Stub zones, however, contain only the
Name Server (NS), Start of Authority (SOA), and host (A) records for the
Name Servers.
|
Create Reverse Lookup Zones
Some applications require the ability to perform
Reverse DNS Lookups. As a best practice, you should set up Reverse
Lookup Zones for IP subnets on your network.
|
Global Naming Zones
Before Windows networks relied so heavily on DNS,
they used the Windows Internet Naming Service (WINS) to provide name
resolution. WINS provides the ability to resolve a NETBIOS name to an IP
address. If you support legacy applications that rely on NETBIOS names,
it is highly possible that you are still supporting WINS on your
network. To help organizations move away from WINS, Microsoft developed
Global Naming Zones (GNZs). GNZs, in Windows Server 2008 R2, allow
companies to decommission WINS while still supporting NETBIOS names.
GNZs require that your domain controllers be at Windows Server 2008 or
later. Windows Server 2003 DCs do not support GNZs.
DNS records
DNS records are the data of DNS zones. Records map
host names to IP addresses and IP addresses to host names. The most
commonly used DNS records are listed below:
A (Host) Record
—A records are standard records that map the FQDN of a host to an IP
address. For example, the syngress.com zone could contain a host record
www that points to the IP address of the Syngress Web site.
CNAME (Alias) Record —CNAME records, also known as aliases, map a host name to an existing A record. For example, a CNAME record could map www.syngress.com to Web server1.syngress.com.
MX (Mail Exchanger) Record —MX
records are used to map a domain name to an A record for mail delivery.
MX records also contain a priority to allow failover to secondary mail
servers in the event that your primary mail server is unavailable. MX
records are crucial to ensure mail flow.
NS (Name Server) Record
—NS records identify all the authoritative DNS servers for a given
zone. The primary DNS Server and the secondary DNS Server should have NS
records in the zone.
SRV (Service) Record
—SRV records provide autodiscovery of TCP/IP resource on the network.
Using SRV records, clients can query the domain for information about a
particular service, such as what server it may reside on. SRV records
are being used by more and more applications to provide autodiscovery
for products such as Exchange Server and Office Communications Server.
PTR (Pointer) Record
—PTR records are Reverse Lookup records that reside in Reverse DNS
zones. PTR records perform the opposite function as A records.
Designing a DNS infrastructure
When creating your DNS design documentation, you will
want to ensure that the infrastructure is highly available and
redundant. As previously mentioned, DNS is one of the most
mission-critical services on your network. As you design your DNS
infrastructure, you will want to consider the following:
Number of physical and logical networks that will need name resolution.
Available WAN bandwidth.
Number of domains or zones you will need to support.
Other non-Windows-based DNS hosts.
Where DNS zones will be stored—AD or DNS flat files?
Integration with WINS servers.
Can GNZs replace WINS?
What types of records will be required?
How many records will be needed?
Will subdomains be required (subdomain.syngress.com)?
Will DNS Forwarding be used?
Number of clients using DNS for name resolution.
Remember that a good DNS design allows quick name
resolution to clients and provides adequate redundancy so that DNS
services remain available in the event of a DNS Server failure. You will want to test your design
thoroughly before deploying to a production network. DNS is no
exception. You need to be able to answer questions such as “Does name
resolution still work efficiently if a DNS Server fails?” and “Is the
DNS response time quick enough to support the number of clients on my
network?” Be sure that you adequately document your DNS design. As your
network grows, you will want to refer the design and make modifications
to support new network segments and increased numbers of clients. Figure 2 depicts a design of a small network.
Deploying DNS
After
designing (and testing) your DNS infrastructure, you are ready to begin
deployment. How you deploy will depend upon how you plan to configure
and support DNS. DNS can be installed just like any other server role,
or if you are planning on using DNS on an AD Domain Controller, it is
installed using the AD dcpromo process.
