A client that makes a query trusts that an authoritative DNS name server gives it the right information. In most environments, this works fine. Users or administrators specify the initial DNS name servers to which DNS queries should be forwarded in a computer's TCP/IP configuration. In some environments where security is a major concern, administrators might be worried about DNS clients getting invalid information from DNS name servers. Here, administrators might want to look at the DNS Security (DNSSEC) protocol. DNSSEC is especially useful for companies that have many branch locations, and DNS information is transferred over the public Internet using zone transfers.

DNSSEC provides authentication of DNS information. Using DNSSEC, you can digitally sign zone files so that they can be authenticated. These digital signatures can be sent to DNS clients as resource records from DNS servers hosting signed zones. The client can then verify that the DNS information sent from the DNS server is authentic.

DNSSEC digital signatures are encrypted using private key encryption on a per-zone basis. In private key encryption, there is a public key and a private key. A zone's public key is used to validate a digital signature. Like the digital signature itself, the public key is stored in a signed zone in the form of a resource record. A zone's private key is not stored in the zone; it is private and used only by the name server to sign the related zone or parts of the zone. The records used with DNSSEC are summarized in Table 26-3.

Windows Server 2003 fully supports DNS dynamic updates. Dynamic updates are used in conjunction with DHCP to allow a client to update its A record if its IP address changes and allow the DHCP server to update the PTR record for the client on the DNS server. DHCP servers can also be configured to update both the A and PTR records on the client's behalf. Dynamic DNS is also supported for IPv6 AAAA records, which allows for dynamic updating of host addresses on systems that use IPv6 and DHCP.

If dynamic updates are enabled, the DNS name server trusts the client to update its own DNS record and trusts the DHCP server to make updates on behalf of the client. There are two types of dynamic updates:

Secure dynamic updates are the default setting for Active Directory–integrated zones. By using secure updates, only clients capable of using secure dynamic updates can update their records. This means clients running Windows 2000 or later can update their own records, but clients running earlier versions of the Windows operating system cannot. DHCP servers can be configured to make updates on behalf of these clients. For more information on this, see the section entitled "Integrating DHCP and DNS".

With standard zones, the default setting is to allow both secure and nonsecure dynamic updates. The reason standard zones are configured for both secure and nonsecure dynamic updates is that this allows clients running Windows 2000 or later as well as earlier versions of Windows to update records dynamically. Although it seems to imply that security is involved, it is in fact not. Here, allowing secure updates simply means that the dynamic update process won't break when a secure update is made. DNS doesn't validate updates and this means dynamic updates are accepted from any client. This creates a significant security vulnerability because updates can be accepted from untrusted sources.

Inside Out: Hidden "gotchas" with secure updates

There are hidden "gotchas" when you use secure dynamic updates that people don't often think about. When a DHCP server creates a record on a DNS server, the DHCP server becomes the owner of the record. If a DHCP server is replaced or its scopes are migrated to another computer, then the server no longer exists and no one else can update the records it created. Thus, any records that the server owns become outdated (stale) and nonupdateable (orphaned).

In addition, if you upgrade a client from a version of Windows earlier than Windows 2000 to Windows 2000 or later, the client's DNS records can become stale and orphaned as well. This happens because DHCP servers update the DNS records for pre–Windows 2000 clients but do not do so for clients using Windows 2000 or later.

The best solution for these hidden "gotchas" is to change ownership of records manually as appropriate after upgrades.

Typically, as part of a standard DNS configuration, you'll configure DNS servers on your internal network to forward queries that they can't resolve to DNS servers outside the organization. Normally, these servers are the name servers for the Internet service provider (ISP) that provides your organization's Internet connection. In this configuration, you know that internal servers forward to designated external servers. However, if those servers don't respond, the internal servers typically will forward requests directly to the root name servers, and this is where security problems can be introduced.

By default, DNS servers include a list of root servers that can be used for name resolution to the top-level domains. This list is maintained in what is called a root hints file. If this file is not updated regularly, your organization's internal name servers could point to invalid root servers, and this leaves a hole in your security that could be exploited. To prevent this, periodically update the root hints file.

On a DNS server that doesn't use Active Directory, the root hints are read from the %SystemRoot%System32DNSCache.dns file. You can obtain an update for this file from ftp://ftp.rs.internic.net/domain/named.cache. To determine whether an update is needed, compare the version information in your current root hints file with that of the published version. Within the root hints file, you'll find a section of comments like this:

;       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.root
;          on server                        FTP.INTERNIC.NET
;
;          last update:                     Nov 5, 2002
;          related version of root zone:    2002110501

Here, the version information is in the last two lines of the comments. If you changed the root hints file, you must stop and then start the DNS Server service so that the root hints file is reloaded. In the DNS console, you can do this by right-clicking the server entry, pointing to All Tasks, and selecting Restart.

On a DNS server that uses Active Directory–integrated zones, the root hints are read from Active Directory and the Registry at startup. You can view and modify the root hints in the DNS console. To do this, right-click the DNS server entry and then select Properties. In the Properties dialog box, select the Root Hints tab. You can then manage each of the individual root hint entries using Add, Edit, or Remove as necessary. To update the entire root hints using a known good DNS server, click Copy From Server, type the IP address of the DNS server, and then click OK. If you suspect the root hints file is corrupted, see Microsoft Knowledge Base article 249868 for details on reloading the file into Active Directory using the %SystemRoot%System32DNSCache.dns file.

Inside Out: Consider whether external root servers should be used

In some instances, you might not want to use a root hint file, or you might want to bypass using root servers. Here are two scenarios to consider:

• If your organization isn't connected to the Internet, your name servers don't need pointers to the public root servers. Instead, you should remove the entries in the Cache.dns file and replace them with NS and A records for the DNS server authoritative for the root domain at your site. For example, if you use a private top-level domain, such as .local, you must set up a root name server for the .local domain, and the Cache.dns file should point to these root name servers. You must then restart the DNS Server service so that the root hints file is reloaded. In the DNS console, you can do this by right-clicking the server entry, pointing to All Tasks, and selecting Restart.

• Making a connection to the root name servers exposes your internal name servers. The internal name server must connect through your organization's firewall to the root name server. While this connection is open and your name server is waiting for a response, there is a potential vulnerability that could be exploited. Here, someone could have set up a fake name server that is waiting for such connections and then could use this server to perform malicious activity on your DNS servers. To prevent this, you can configure forwarding to specific external name servers and tell your name servers not to use the root name servers. You do this by configuring the Do Not Use Recursion For This Domain option when you set up forwarding.

For more information, see the section entitled "Configuring Forwarders and Conditional Forwarding".