Microsoft Windows Server 2003 Insider Solutions

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 used heavily by Microsoft DNS.

Dynamic DNS (DDNS)

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 later 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.

Time to Live (TTL)

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 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.

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 by choosing 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 13.17.

    Figure 13.17. Changing the TTL.

  5. Click OK to accept the changes.

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 use 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 because of specific issues in regards to secure updates. The reason for this recommendation is that all DHCP servers are placed in a group known as DNSUpdateProxy. 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.

Категории