DNS CONCEPTS

2007-09-04T00:30:00.001-07:00

2007-06-15T00:22:00.001-07:00

What is "secondary DNS server" and "Secondary DNS zone"?

Purpose of having a "Secondary DNS Server"
http://technet2.microsoft.com/windowsserver/en/library/54572f43-7c5f-4600-b8ff-3c91cf0541ed1033.mspx?mfr=true

2006-11-20T02:21:00.000-08:00

How DNS Scavenging Works?
======================
Please refer to the following for detailed research on aging and scavenging. Below you may find the steps to implement Aging and Scavenging of Stale records from DNS.

1) Go to the properties of the DHCP server and upto the DNS tab. Configure DHCP to update DNS always, for clients which can update dynamically and which cannot.

2) Make the following registry change on the DHCP server.
HKLM\System\CCS\Service\DHCPServer\Parameters\DatabaseCleanupInterval to 60 from the default value of 1440 (1 day).

3) DHCP server needs to be rebooted after the Registry change.

4) After these changes on the DHCP server we need to manually age all records so that there countdown clock starts. Records can be aged by using the command line utility Dnscmd. This utility can be copied to the root from support tools.

--Run the following command to timestamp all records (including manually added records): dnscmd /AgeAllRecords example.com @ /tree /f
--Uncheck "Delete this record when it becomes stale" for records you want to keep.
--Also, the sequence of steps to be followed for configuring Aging and Scavenging on the DNS servers is as follows.
--The DHCP lease should be less than Aging and Scavenging time. It should be the total of half the time of refreshinterverval plus 1. Suppose the refreshinterval is set as 7 days the DHCP lease should be 4 days. Do not forget to restart the DNS service once you enable scavenging.

To set the Aging feature on an individual zone:
1. Right-click the zone, and then click Properties.
2. Click Aging.
3. Click to select the Scavenge Stale Resource Records check box, and then set the interval that you want the Aging feature to use. You need to enable the Aging and Scavenging feature at a server level, and optionally set the Aging feature on zones if you need different aging periods:
1. Open the DNS manager.
2. In the left pane, under the DNS icon, right-click the server name.
3. Click "Set Aging/Scavenging" for all zones.
4. Click to select the "Scavenge Stale Resource Records" check box, and then set the interval that you want the Aging feature to use.

Additional information is as follows:-

Firstly, let me explain that even after configuring Scavenging and 'Aging all records', the records may not get scavenged for No-Refresh Interval + Refresh Interval + Scavenging time days based on the following three parameters.

Record Life Span
The Figure below shows the life span of a scavengeable record.
When a record is created or refreshed on an Active Directory-integrated zone or on a standard primary zone for which scavenging is enabled, a record's timestamp is written.
Because of the addition of the timestamp, a standard primary zone file for which scavenging is enabled has a format slightly different from a standard DNS zone file. This does not cause any problems with zone transfer. However, you cannot copy a standard zone file for which scavenging is enabled to a non-Windows 2000-based DNS server.
The value of the timestamp is the time when the record was created or the record was last refreshed. If the record belongs to an Active Directory-integrated zone, then every time the timestamp is refreshed, the record is replicated to other domain controllers in the domain.
By default, the timestamps of records that are created by any method other than dynamic update are set to zero. A zero value indicates that the timestamp must not be refreshed and the record must not be scavenged. An Administrator can manually enable aging of such records.
After the record is refreshed, it cannot be refreshed again for the period specified by the no-refresh interval. The no-refresh interval, a zone parameter, prevents unnecessary Active Directory replication traffic.
However, the record can still be updated during the no-refresh interval. If a dynamic update request requires record modification, it is considered an update. If it does not require record modifications, it is considered a refresh. Therefore, prerequisite-only updates-updates that include a list of prerequisites but no zone changes-are also considered refreshes.
The no-refresh interval is followed by the refresh interval. After the expiration of the no-refresh interval, the server begins to accept refreshes. The record can be refreshed as long as the current time is greater than the value of the timestamp plus the no-refresh interval. When the server accepts a refresh or an update, the value of the timestamp changes to the current time.
Next, after the expiration of the refresh interval, the server can scavenge the record if it has not been refreshed. The record can be scavenged if the current time is greater than the value of the timestamp plus the value of the no-refresh interval plus the value of the refresh interval. However, the server does not necessarily scavenge the record at that time. The time at which records are scavenged depends on several server parameters.

Scavenging Algorithm
The server can be configured to perform scavenging automatically, using a fixed frequency. In addition, you can manually trigger scavenging on a server to perform immediate scavenging. When scavenging starts, the server attempts to scavenge all primary zones and succeeds if all the following conditions are met:
1) The EnableScavenging parameter is set to 1 on the server.
2) The EnableScavenging parameter is set to 1 on the zone.
3) Dynamic update is enabled on the zone.
4) The zone parameter ScavengingServers is not specified or contains the IP address of this server.
5) The current time is greater than the value of the zone parameter StartScavenging.

The server sets StartScavenging whenever any of the following events occur:
6) Dynamic update is turned on.
7) EnableScavenging is set from 0 to 1 on the zone.
8) The zone is loaded.
9) The zone is resumed.

StartScavenging is equal to the time that one of the preceding events occurs plus the amount of time specified in the refresh interval for the zone. This prevents a problem that can occur if the client is unable to refresh records because the zone isn't available-for example, if the zone is paused or the server is not working. If that happens and the server does not use StartScavenging, the server could scavenge the zone before the client has a chance to update the record.
When the server scavenges a zone, it examines all the records in the zone one by one. If the timestamp is not zero, and the current time is later than the time specified in the timestamp for the record plus the no-refresh and refresh intervals for the zone, it deletes the record. All other records are unaffected by the scavenging procedure.

Configuring Scavenging Parameters
This section discusses issues you must consider when configuring scavenging parameters.
To ensure that no records are deleted before the dynamic update client has time to refresh them, the refresh interval must be greater than the refresh period for each record subjected to scavenging within a zone. Many different services might refresh records at different intervals; for example, Netlogon refreshes records once an hour, cluster servers generally refresh records every 15 to 20 minutes, DHCP servers refresh records at renewal of IP address leases, and Windows 2000-based computers refresh their A and PTR resource records every 24 hours.
Usually, the DHCP service requires the longest refresh interval of all services. If you are using the Windows 2000 DHCP service, you can use the default scavenging and aging values. If you are using another DHCP server, you might need to modify the defaults.
The longer you make the no-refresh and refresh intervals, the longer stale records remain. Therefore, you might want to make those intervals as short as is reasonable. However, if you make the no-refresh interval too short, you might cause unnecessary replication by Active Directory.

2006-10-30T22:58:00.000-08:00

TITLE: AD integrated DNS and record deletion
===========================================

When AD objects are deleted they are tombstoned. It is as if they are gone from AD. However a remnant of the object, the tombstone, persists for replication purposes. Over time the tombstone is removed and the object is truly gone from AD.
So if we are chasing a deleted object to see who/how/when it was deleted we need to look at its tombstone. An authoritative restore will remove the tombstone when the object is restored so we can only look at the tombstone in a domain where the object is deleted.
Finally, DNS objects have their own deletion/tombstone process. Depending on the method of deletion there are two ways to search for the deleted DNS objects as there are two tombstones (dNSTombstoned and isDeleted).
dNSTombstoned: If a record is deleted in the MMC for dnsmgmt.msc the object still exists but dns.exe will no longer load the value. isDeleted: isDeleted is the AD "tombstone" for the deletion of the object from the AD.
Once we determine if the DNS recored is dNSTombstoned or AD tombstoned we then use "repadmin /showmeta
" and this will show us the time/date that each attribute for this object was created, edited, or marked for deletion. This shows the originating source DC of this change. From there we may be able to determine who/what was on that source DC at the time.
Viewing deleted objects in Active Directory (258310)http://support.microsoft.com/default.aspx?scid=KB;EN-US;258310
How does the dnsTombstoned attribute tie in with aging and scavenging? ==============
The DNS service picks up the deletion of DNS records via the dnsTombstoned attribute. The DNS service maintains a copy of the zone in memory for performance. When a DNS server receives inbound AD replication of a dnsTombstoned attribute that is set to TRUE, it deletes that record from the in-memory copy of the zone. In addition the DNS service will no longer load records from AD which have a dnsTombstoned attribute set to TRUE. Once a record’s dnsTombstoned attribute is set to TRUE, it is no longer present from a DNS perspective.
The DNS service checks the zone stored in AD periodically for records with a dnsTombstoned attribute that was set to TRUE greater than 7 days. These records are then deleted from the AD database. At this point the deletion is just like a normal AD object deletion in which the record is marked isDeleted and moved into the deleted objects container.
PROBLEM: DNS record stored in Active Directory is deleted. Instructions are required on how to properly enable auditing to determine what caused the deletion and what type of "deletion" it was.
CAUSE: Depending on the method/API used to delete a record two types of object access types needs to be enabled to catch both scenarios.
RESOLUTION: When a DNS record is deleted using the DNS mmc, it simply changes the DNSTombstoned attribute to TRUE. If a new replacement record is created with the same name, the same tombstoned record simply has its DNSTombstoned attribute changed to FALSE. Thus, the GUID remains the same after "deletions".
If the entire object is deleted, such as with an LDAP delete operation, it is only logged if auditing of object deletions is enabled. If the object is deleted as a normal Active Directory object (such as with an LDAP delete command using interfaces such as ADSIEDIT or LDP) an audit event 566 referencing an access type of DELETE is recorded.
HOWTO: Set up DNS auditing for records that disappear from the zone1.Enable Directory Service Access auditing in your default Domain Policy: - open domain security policy - navigate to Local Policies -> Audit Policy - Define "Audit directory service access" for success and failure - Refresh domain policy on all domain controllers
2. Enable auditing on the zone - open AdsiEdit - Navigate to the location of your DNS zone - Right click the zone to audit and choose properties. - go to the security tab, click the advanced button - select the Auditing tab and click Add - for the user or group, type in Everyone - On the Object tab, select Success and Failure for the following Access types: -- Write All Properties, Read All properties, Delete and Delete Subtree - OK out of the policy and refresh the policy again.
3. When a record is deleted from DNS the following event is logged in the Security
Event log: Event ID: 566
Source: SecurityType: Success
Category: Directory Service Access
Description: Will post a message similar to following:
Object Name: DC=recordname,DC=domain,DC=domain,CN=System,DC=dcname,DC=domain
Properties: Write Property Default property set dnsRecord dNSTombstoned