Other DNS Components


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, 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 in order for them to be updated in DNS. There are, however, security issues associated with this functionality that will be detailed in subsequent sections of this chapter and will be described further in Chapter 10, "DHCP/WINS/Domain Controllers."

The Time to Live Value

The Time to Live (TTL) value for a server 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.

In the example from the "Iterative Queries" section, if Client1 already requested the IP 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 may 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.

The TTL setting for a zone is modified via the SOA record. The procedure for doing this in Windows Server 2003 is as follows:

1.

Open the DNS MMC snap-in (Start, Administrative Tools, DNS).

2.

Navigate to DNS\<Servername>\Forward Lookup Zones\<Zonename>.

3.

Find the SOA record for the zone and double-click it.

4.

Modify the Minimum (Default) TTL entry to match the TTL you want, as shown in Figure 9.15.

Figure 9.15. Changing the TTL.


5.

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 their own IP address. For this reason, dynamic updates are, by default, turned off on new standard zones that are created in Windows Server 2003. However, with AD-integrated DNS zones, a mechanism exists that will allow clients to perform secure dynamic updates. Secure updates utilize Kerberos to authenticate users 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, 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 often 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.

Aging and Scavenging

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 2003 by following these steps:

1.

Open the DNS MMC snap-in (Start, Administrative Tools, DNS).

2.

Right-click the server name and choose Properties.

3.

Select the Advanced tab.

4.

Check the Enable Automatic Scavenging of Stale Records box.

5.

Select a scavenging period, as shown in Figure 9.16, and click OK to save your changes.

Figure 9.16. Turning on scavenging.


Scavenging makes a DNS database cleaner, but aggressive scavenging can also remove valid entries. It is therefore wise, if you're using scavenging, to strike a balance between a clean database and a valid one.

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 


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 do the iterative queries to the Internet root name servers. Forwarders are used often in situations in which an organization utilizes the DNS servers of an 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 may 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 2003 DNS environment, you can establish them by following these steps:

1.

Open the DNS MMC snap-in (Start, Administrative Tools, DNS).

2.

Right-click the server name and choose Properties.

3.

Select the Forwarders tab.

4.

In the DNS Domain box, determine whether conditional forwarders will be established. If so, add them by clicking the New button.

5.

Add the IP address of the forwarders into the Selected Domain's Forwarder IP Address List box, as shown in Figure 9.17.

6.

If this server will be configured only to forward, and to otherwise fail if forwarding does not work, check the Do Not Use Recursion for This Domain box.

7.

Click OK to save the changes.

Figure 9.17. Setting up forwarders.


Using WINS for Lookups

In environments with a significant investment in WINS lookups, 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 several WINS RRs in DNS that are established to support this approach.

To enable WINS to assist with DNS lookups, follow these steps:

1.

Open the DNS MMC snap-in (Start, Administrative Tools, DNS).

2.

Navigate to DNS\<Servername>\Forward Lookup Zones.

3.

Right-click the zone in question and choose Properties.

4.

Choose the WINS tab.

5.

Check the Use WINS Forward Lookup box.

6.

Enter the IP address of the WINS Server(s), click Add, and then click OK to save the changes.




Microsoft Windows Server 2003 Unleashed(c) R2 Edition
Microsoft Windows Server 2003 Unleashed (R2 Edition)
ISBN: 0672328984
EAN: 2147483647
Year: 2006
Pages: 499

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net