Dynamic Update Triggers
The following events
trigger the DHCP Client service to send a dynamic update to the DNS
server:
An IP address is
added, removed, or modified in the Transmission Control
Protocol/Internet Protocol (TCP/IP) properties configuration for any one
of the local computer’s installed network connections.
An IP address lease changes
or renews with the DHCP server for any one of the local computer’s
installed network connections—for example, when the computer is started
or if the Ipconfig /renew command is used.
The Ipconfig /registerdns command
is used on a DNS client computer to manually force a refresh of the
client name registration in DNS.
The DNS
client computer is turned on.
A member server within the zone is promoted to a
domain controller.
Secure Dynamic
Updates
Secure dynamic
updates can be performed only in Active Directory–integrated zones. For
standard zones, the Secure Only option does not appear in the Dynamic
Updates drop-down list box. These updates use the secure Kerberos
authentication protocol to create a secure context and ensure that the
client updating the resource record is the owner of that record.
Note
Only clients
running a version of Windows 2000, Microsoft Windows XP, or Windows
Server 2003 can attempt to send dynamic updates to a DNS server. Dynamic
updates are not available for any version of Windows NT, Windows 95,
Microsoft Windows 98, or Microsoft Windows Millennium Edition (Me).
However, a DNS client computer (such as a DHCP server) can perform
dynamic updates on behalf of other clients if the server is configured
to do so. |
Secure Dynamic
Updates and the DnsUpdateProxy group
When
only secure dynamic updates are allowed in a zone, only the owner of a
record can update that record. (The owner of a record is the computer
that originally registers the record.) This restriction can cause
problems in situations where a DHCP server is being used to register
host (A) resource records on behalf of client computers that cannot
perform dynamic updates. In such cases, the DHCP server becomes the
owner of the record, not the computers themselves. If the downlevel
client computer is later upgraded to Windows 2000 or some other
operating system that is capable of performing dynamic updates, the
computer will not be recognized as the owner and will consequently be
unable to update its own records. A similar problem might arise if a
DHCP server fails that has registered records on behalf of downlevel
clients: none of the clients will be able to have their records updated
by a backup DHCP server.
To
avoid such problems, add to the DnsUpdateProxy security group DHCP
servers that register records on behalf of other computers. Members of
this group are prevented from recording ownership on the resource
records they update in DNS. This procedure consequently loosens security
for these records until they can be registered by the real owner.
Tip
Expect to be tested on DnsUpdateProxy on
the exam. |
Aging
By clicking Aging on
the General tab, you can open the Zone Aging/Scavenging Properties
dialog box, shown in Figure 8. These properties provide a means of finding and clearing
outdated records from the zone database.
Enabling Aging
Aging in DNS refers to the process of placing a
timestamp on a dynamically registered resource record and then tracking
the age of this record. Scavenging refers to the process of deleting outdated
resource records on which timestamps have been placed. Scavenging can
occur only when aging is enabled. Both aging and scavenging are disabled
by default.
To enable aging for a
particular zone, you have to enable this feature both at the zone level
and at the server level. To enable aging at the zone level, in the Zone
Aging/Scavenging Properties dialog box, select the Scavenge Stale
Resource Records check box. To enable aging at the server level, first
open the Server Aging/Scavenging Properties dialog box by right-clicking
the server icon in the DNS console and then clicking Set
Aging/Scavenging For All Zones. Then, in the Server Aging/Scavenging
Properties dialog box, select the Scavenge Stale Resource Records check
box.
After aging is
enabled, a timestamp based on the current server time is placed on all
dynamically registered records in the zone. When the DHCP Client service
or DHCP server later performs a dynamic update of the records, a
timestamp refresh is attempted. Manually created resource records are
assigned a timestamp of 0; this value indicates that they will not be
aged.
Note
When aging
and scavenging are enabled for a zone, zone files cannot be read by
pre-Windows 2000 DNS servers. |
Modifying
no-refresh intervals
The no-refresh
interval is the period after a
timestamp during which a zone or server rejects a timestamp refresh. The
no-refresh feature prevents unnecessary refreshes from being processed
by the server and reduces unnecessary zone transfer traffic. The default
no-refresh interval is seven days.
Modifying
refresh intervals
The refresh interval is the time after the no-refresh interval during
which timestamp refreshes are accepted and resource records are not
scavenged. After the no-refresh and refresh intervals expire, records
can be scavenged from the zone. The default refresh interval is 7 days.
Consequently, when aging is enabled, dynamically registered resource
records can be scavenged after 14 days by default.
Tip
If you modify
the no-refresh or refresh interval, be sure to follow the guideline that
the refresh interval should be equal to or greater than the no-refresh
interval. |
Performing
Scavenging
Scavenging in a zone is performed either
automatically or manually. For scavenging to be performed automatically,
you must enable automatic scavenging of stale resource records on the
Advanced tab of DNS server properties. When this feature is not enabled,
you can perform manual scavenging in a zone by right-clicking the
server icon in the DNS console tree and then selecting Scavenge Stale
Resource Records from the shortcut menu.
Start Of
Authority (SOA) Tab
The Start Of Authority
(SOA) tab, shown in Figure 9,
allows you to configure the SOA resource record for the zone. When a
DNS server loads a zone, it uses the SOA resource record to determine
basic, authoritative information about the zone. These settings also
determine how often zone transfers are performed between primary and
secondary servers.
Serial Number
The Serial Number text
box on the Start Of Authority (SOA) tab contains the revision number of
the zone file. This number increases each time a resource record changes
in the zone or when the value is manually incremented on this tab by
clicking Increment.
When zones are
configured to perform zone transfers, the master server is
intermittently queried for the serial number of the zone. This query is
called the SOA query. If, through the SOA query, the serial number of the master
zone is determined to be equivalent to the local serial number, no
transfer is made. However, if the serial number for the zone at the
master server is greater than that at the requesting secondary server,
the secondary server initiates a transfer.
Primary Server
The Primary Server text
box on the Start Of Authority (SOA) tab contains the full computer name
for the primary DNS server of the zone. This name must end with a
period.
Responsible
Person
When this text box is configured, it contains a
responsible person (RP) resource record of the person responsible for
administering the zone. An RP resource record specifies a domain mailbox
name for the responsible person. The name of the record entered into
this field should always end with a period.
Refresh Interval
The value you configure
in the Refresh Interval field determines how long a secondary DNS server
waits before querying the master server for a zone renewal. When the
refresh interval expires, the secondary DNS server requests a copy of
the current SOA resource record for the zone from its master server
source, which then answers this SOA query. The secondary DNS server then
compares the serial number of the source server’s current SOA resource
record (as indicated in the master’s response) with the serial number of
its own local SOA resource record. If they are different, the secondary
DNS server requests a zone transfer from the primary DNS server. The
default value for this setting is 15 minutes.
Tip
Increasing the refresh interval
decreases zone transfer traffic. |
Retry Interval
The value you
configure in the Retry Interval box determines how long a secondary
server waits before retrying a failed zone transfer. Normally, this time
is less than the refresh interval. The default value is 10 minutes.
Expires After
The value you
configure in the Expires After box determines the length of time that a
secondary server, without any contact with its master server, continues
to answer queries from DNS clients. After this time elapses, the data is
considered unreliable. The default value is 1 day.
Minimum
(Default) TTL
The value you
configure in the Minimum (Default) TTL box determines the default Time
to Live (TTL) that is applied to all resource records in the zone. The
default value is 1 hour.
TTL values are not
relevant for resource records within their authoritative zones. Instead,
the TTL refers to the cache life of a resource record in
nonauthoritative servers. A DNS server that has cached a resource record
from a previous query discards the record when that record’s TTL has
expired.
Tip
If you have
deployed caching-only servers in your network in addition to a primary
server, increasing the minimum TTL can decrease name resolution traffic
between the caching-only servers and the primary server. |
TTL For This
Record
The
value you configure in this text box determines the TTL of the present
SOA resource record. This value overrides the default value setting in
the preceding field.
Once configured in the
DNS console, an SOA resource record is represented textually in the zone
file, as shown in this example:
@IN SOA computer1.domain1.local. hostmaster.domain1.local. (
5099 ; serial number
3600 ; refresh (1 hour)
600 ; retry (10 mins)
86400 ; expire (1 day)
60 ) ; minimum TTL (1 min)
