Several
other key components lie at the heart of DNS and are necessary for it
to function properly. In addition, you need to fully understand the
functionality of several key components of DNS that are utilized heavily
by Microsoft DNS.
Dynamic DNS
Older versions of DNS relied
on administrators manually updating all the records within a DNS
database. Every time a resource was added or information about a
resource was changed, the DNS database was updated manually, normally
via a simple text editor, to reflect the changes. Dynamic DNS was
developed as a direct response to the increasing administrative overhead
that was required to keep DNS databases functional and up to date. With
Dynamic DNS, clients can automatically update their own records in DNS,
depending on the security settings of the zone.
It is important to note that
only Windows 2000/XP and higher clients support dynamic updates and that
down-level (NT/9x) clients must have DHCP configured properly for them
to be updated in DNS.
The Time to Live Value
The
Time to Live (TTL) value for a RR is the amount of time (in seconds)
that a resolver or name server will keep a cached DNS request before
requesting it again from the original name server. This value helps to
keep the information in the DNS database relevant. Setting TTL levels is
essentially a balancing act between the need for updated information
and the need to reduce DNS query traffic across the network.
If Client1 already requested the IP address of www.microsoft.com,
and the information was returned to the DNS server that showed the IP
address, it would make sense that that IP address would not change often
and could, therefore, be cached for future queries. The next time
another client requests the same information, the local DNS server will
give that client the IP address it received from the original Client1
query as long as the TTL has not expired. This helps to reduce network
traffic and improve DNS query response time.
The TTL for a response is set by
the name server that successfully resolves a query. In other words, you
might have different TTLs set for items in a cache, based on where they
were resolved and the TTL for the particular zone they originated from.
Note
The default TTL for
manually created records in Windows Server 2008 R2 DNS is one hour.
Records created dynamically via Dynamic DNS have a 20-minute default
TTL.
The TTL setting for a zone is modified via the SOA record. The procedure for doing this in Windows Server 2008 R2 is as follows:
1. | Launch Server Manager.
|
2. | Expand the Roles, DNS Server, DNS, server name, and Forward Lookup Zones nodes.
|
3. | Select the zone node.
|
4. | Find the SOA record for the zone and double-click it.
|
5. | Modify the Minimum (Default) TTL entry to match the TTL you want, as shown in Figure 1.
|
6. | Click OK to accept the changes.
|
Performing Secure Updates
One of the main problems
with a Dynamic DNS implementation lies with the security of the update
mechanism. If no security is enforced, nothing will prevent malicious
users from updating a record for a server, for example, to redirect it
to another IP address. This is known as DNS poisoning. For this reason,
dynamic updates are, by default, turned off on new standard zones that
are created in Windows Server 2008 R2. However, with AD-integrated DNS
zones, a mechanism exists that allows clients to perform secure dynamic updates.
Secure updates utilize Kerberos to authenticate computers and ensure
that only those clients that created a record can subsequently update
the same record.
If you’re using DHCP to
provide secure updates on behalf of DHCP clients, one important caveat
is that DHCP servers should not be located on the domain controller, if
possible, because of specific issues in regard to secure updates. The
reason for this recommendation is that all DHCP servers are placed in a
group known as DNSUpdateProxy. Any members of this group do not take
ownership of items that are published in DNS. This group was created
because DHCP servers can dynamically publish updates for clients
automatically, and the clients would need to modify their entries
themselves. Subsequently, the first client to access a newly created
entry would take ownership of that entry. Because domain controllers
create sensitive SRV records and the like, it is not wise to use a
domain controller as a member of this group, and it is subsequently not
wise to have DHCP on domain controllers for this reason. If establishing
DHCP on a domain controller is unavoidable, it is recommended to
disable this functionality by not adding the server into this group.
Exploring Aging and Scavenging for DNS
DNS RRs often become
stale, or no longer relevant, as computers are disconnected from the
network or IP addresses are changed without first notifying the DNS
server. The process of scavenging those records removes them from a
database after their original owners do not update them. Scavenging is
not turned on, by default, but this feature can be enabled in Windows
Server 2008 R2 by following these steps:
1. | |
2. | Expand the Roles, DNS Server, and DNS nodes, and then select the DNS server name.
|
3. | Right-click the server name and choose Properties.
|
4. | Select the Advanced tab.
|
5. | Check the Enable Automatic Scavenging of Stale Records check box.
|
6. | Select a scavenging period, as shown in Figure 2, and click OK to save your changes.
|
Scavenging makes a DNS
database cleaner, but overly aggressive scavenging can also remove
valid entries. Therefore, if you’re using scavenging, it is wise to
strike a balance between a clean database and a valid one.
Examining Root Hints
By default, a DNS
installation includes a listing of Internet-level name servers that can
be used for name resolution of the .com, .net, .uk, and like domain
names on the Internet. When a DNS server cannot resolve a query locally
in its cache or in local zones, it consults the Root Hints list, which
indicates which servers to begin iterative queries with.
The Hints file should be
updated on a regular basis to ensure that the servers listed are still
relevant. This file is located in \%systemroot%\system32\DNS\cache.dns
and can be updated on the Internet at the following address:
ftp://ftp.rs.internic.net/domain/named.cache.
At the time of writing, the
latest root hints file, or root name servers, was dated December 12,
2008. The contents are shown in Listing 10.1. You can see the root server names (such as “A.ROOT-SERVER.NET”) and their A records (such as “192.41.0.4”).
Listing 1. Root Hints File Contents
; This file holds the information on root name servers needed to
; initialize cache of Internet domain name servers
; (e.g. reference this file in the "cache . <file>"
; configuration file of BIND domain name servers).
;
; This file is made available by InterNIC
; under anonymous FTP as
; file /domain/named.cache
; on server FTP.INTERNIC.NET
; -OR- RS.INTERNIC.NET
;
; last update: Dec 12, 2008
; related version of root zone: 2008121200
;
; formerly NS.INTERNIC.NET
;
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
A.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:BA3E::2:30
;
; FORMERLY NS1.ISI.EDU
;
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201
;
; FORMERLY C.PSI.NET
;
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
;
; FORMERLY TERP.UMD.EDU
;
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
;
; FORMERLY NS.NASA.GOV
;
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
;
; FORMERLY NS.ISC.ORG
;
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
F.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2F::F
;
; FORMERLY NS.NIC.DDN.MIL
;
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
;
; FORMERLY AOS.ARL.ARMY.MIL
;
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
H.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:1::803F:235
;
; FORMERLY NIC.NORDU.NET
;
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
;
; OPERATED BY VERISIGN, INC.
;
. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30
J.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:C27::2:30
;
; OPERATED BY RIPE NCC
;
. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
K.ROOT-SERVERS.NET. 3600000 AAAA 2001:7FD::1
;
; OPERATED BY ICANN
;
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 199.7.83.42
L.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:3::42
;
; OPERATED BY WIDE
;
. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
M.ROOT-SERVERS.NET. 3600000 AAAA 2001:DC3::35
; End of File
|
You can see the root hints for a Windows Server 2008 R2 DNS server by doing the following:
1. | Launch Server Manager.
|
2. | Expand the Roles, DNS Server, and DNS nodes, and then select the DNS server name.
|
3. | Right-click the server name and choose Properties.
|
4. | Select the Root Hints tab.
|
The name servers should match those in the root hints file retrieved from the Internic FTP site.
Understanding the Role of Forwarders
Forwarders are name
servers that handle all iterative queries for a name server. In other
words, if a server cannot answer a query from a client resolver, servers
that have forwarders simply forward the request to an upstream
forwarder that will process the iterative queries to the Internet root
name servers. Forwarders are often used in situations in which an
organization utilizes the DNS servers of an Internet service provider
(ISP) to handle all name-resolution traffic. Another common situation
occurs when Active Directory’s DNS servers handle all internal AD DNS
resolution but forward outbound DNS requests to another DNS environment
within an organization, such as a legacy UNIX BIND server.
In conditional forwarding,
queries that are made to a specific domain or set of domains are sent to
a specifically defined forwarder DNS server. This type of scenario is
normally used to define routes that internal domain resolution traffic
will follow. For example, if an organization controls the companyabc.com
domain namespace and the companyxyz.com namespace, it might want
queries between domains to be resolved on local DNS servers, as opposed
to being sent out to the Internet just to be sent back again so that
they are resolved internally.
Forward-only servers are never
meant to do iterative queries, but rather to forward all requests that
cannot be answered locally to a forwarder or set of forwarders. If those
forwarders do not respond, a failure message is generated.
If you plan to use forwarders in a Windows Server 2008 R2 DNS environment, you can establish them by following these steps:
1. | Launch Server Manager.
|
2. | Expand the Roles, DNS Server, and DNS nodes, and then select the DNS server name.
|
3. | Right-click the server name and choose Properties.
|
4. | Select the Forwarders tab.
|
5. | Click Edit to create forwarders.
|
6. | Type
in the IP address of the server or servers that will be forwarders.
Press Enter for each server entered, and they will be validated. Click
OK when you are finished.
|
7. | If
this server will be configured only to forward, and to otherwise fail
if forwarding does not work, uncheck the Use Root Hints If No Forwarders
Are Available check box.
|
8. | Click OK to save the changes.
|
Using WINS for Lookups
In environments
with a significant investment in WINS, the WINS database can be used in
conjunction with DNS to provide for DNS name resolution. If a DNS query
has exhausted all DNS methods of resolving a name, a WINS server can be
queried to provide for resolution. This method creates WINS RRs in DNS
that are established to support this approach.
To enable WINS to assist with DNS lookups, follow these steps:
1. | Launch Server Manager.
|
2. | Expand the Roles, DNS Server, DNS, server name, and Forward Lookup Zones nodes.
|
3. | Select the zone node.
|
4. | Right-click the zone in question and choose Properties.
|
5. | Choose the WINS tab.
|
6. | Check the Use WINS Forward Lookup check box.
|
7. | Enter the IP address of the WINS server(s), click the Add button, and then click OK to save the changes.
|
