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 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 so 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 2012 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 2012 is as follows:
1. Launch Server Manager from a Windows 2012 server with a full GUI.
2. Select the DNS section. The list of servers in the server pool with the DNS role installed will be shown.
3. Right-click the DNS server to configure and select DNS Manager.
4. Select the DNS server name to configure.
5. Select the Forward Lookup Zones node.
6. Select the zone node.
7. Find the SOA record for the zone and double-click it.
8. Modify the Minimum (Default) TTL entry to match the TTL you want, as shown in Figure 1.
7.2.12
Figure 1. Changing the TTL.
9. 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 prevents 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 2012. 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 by extension 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.
