DNS Tombstones in Windows 2003 and 2008

When DNS records are deleted from AD integrated zones, they are not immediately tombstoned in the way normal AD object deletions are. Instead, they go through a DNS tombstone process. This includes setting dnsTombstoned=True for the object.

When set to True, the DNS console and tools will ignore the presence of the record. You will still see the objects through LDP/ADSIEDIT/LDIFDE alongside the other DNS records. Each DNS server is hard coded to perform a cleanup process every morning at 2 a.m. to delete any dnsTombstoned=True records that are seven days old or older.

It is at this time that the objects are tombstoned like normal AD deletions (isDeleted=True) and moved to the Deleted Objects container. This is important to know in case someone deletes records, such as enabling scavenging for the first time, and wants to know why they still see the objects in Active Directory. The reason for the seven days of dnsTombstoned=True is to prevent frequent database churn. This is because workstation records may get de-registered or scavenged and then re-created within a short period of time.

Prevent Registration of Certain Domain Controller DNS Records

There are times when you want to restrict a Domain Controller from registering certain resource records in the DNS. One of the scenario is when you have hub - spoke topology, it is preferable that if all domain controllers/global catalogs in a satellite site become unavailable, a client that is searching for a domain controller/global catalog in that site will fail over to a domain controller/global catalog in a central hub and not in another satellite site.
To achieve this behavior, the domain controllers/global catalogs in the satellite offices should not register generic (non-site-specific) domain controller locator DNS records

To restrict the DNS resource records that are updated by NetlLogon

1. Open Registry Editor.
2. In Registry Editor, navigate to the following registry key:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
3. Add the following multistring value (REG_MULTI_SZ) value:
   DnsAvoidRegisterRecords
4. In this value, specify the list of data corresponding to the DNS resource records that should not be registered for this domain controller by the Net Logon service. The following table contains the list of data.

<>

<>

Domain Controller -Specific Records

Mnemonic	Type	DNS Record
LdapIpAddress	A
Ldap	SRV	_ldap._tcp.
DcByGuid	SRV	_ldap._tcp..domains._msdcs.
Kdc	SRV	_kerberos._tcp.dc._msdcs.
Dc	SRV	_ldap._tcp.dc._msdcs.
Rfc1510Kdc	SRV	_kerberos._tcp.
Rfc1510UdpKdc	SRV	_kerberos._udp.
Rfc1510Kpwd	SRV	_kpasswd._tcp.
Rfc1510UdpKpwd	SRV	_kpasswd._udp.

Global Catalog-Specific Records

Mnemonic	Type	DNS Record
Gc	SRV	_ldap._tcp.gc._msdcs.
GcIpAddress	A	gc._msdcs.
GenericGc	SRV	_gc._tcp.

Infrastructure Master & Global Catalog placement

Infrastructure Master (IM) is FSMO role that responsible to updates cross-domain references and phantoms from the global catalog. It is comparing objects of the local domain against objects in other domains of the same forest.

Single domain forest:

In a forest that contains a single Active Directory domain, there are no phantoms. Therefore, the infrastructure master has no work to do. The infrastructure master may be placed on any domain controller in the domain, regardless of whether that domain controller hosts the global catalog or not.

Multidomain forest:

If every domain controller in a domain that is part of a multidomain forest also hosts the global catalog, IM won't ever see any differences, since the global catalog holds a partitial copy of every object in the forest itself. So there are no phantoms or work for the infrastructure master to do.

In this case, the infrastructure master may be put on any domain controller in that domain. In practical terms, most administrators host the global catalog on every domain controller in the forest.

When do you require a Global Catalog?

There are certain time when you would need Global Catalog role available instead of just Domain Controller role.

The following events require a global catalog server:

• Forest-wide searches. The global catalog provides a resource for searching an AD DS forest. Forest-wide searches are identified by the LDAP port that they use. If the search query uses port 3268, the query is sent to a global catalog server.
  
• User logon. In a forest that has more than one domain (multidomain), two conditions require the global catalog during user authentication:
  
  • In a domain that operates at the Windows 2000 native domain functional level or higher, domain controllers must request universal group membership enumeration from a global catalog server.
    
  • When a user principal name (UPN) is used at logon and the forest has more than one domain, a global catalog server is required to resolve the name.
    
• Universal Group Membership Caching: In a forest that has more than one domain, in sites that have domain users but no global catalog server, Universal Group Membership Caching can be used to enable caching of logon credentials so that the global catalog does not have to be contacted for subsequent user logons. This feature eliminates the need to retrieve universal group memberships across a WAN link from a global catalog server in a different site.
  

  Note
  Universal groups are available only in a domain that operates at the Windows 2000 native domain functional level or higher.

• Exchange Address Book lookups. Servers running Microsoft Exchange Server rely on access to the global catalog for address information. Users use global catalog servers to access the global address list (GAL).

Active Directory Replication Terminology - Part II

Automatic Site Coverage:
To ensure that clients can locate a domain controller in the nearest available site, domain controller advertises itself (registers a site-related SRV record in DNS) in any site that does not have a domain controller for that domain and for which its site has the lowest-cost connections. This functionality is commonly known as "automatic site coverage."

To disable automatic site coverage on a domain controller:

1. Click Start, click Run, type regedit, and then click OK.
2. Navigate to the following registry subkey:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
3. Click Edit, point to New, and then click DWORD Value.
4. Type AutoSiteCoverage as the name of the new entry, and then press ENTER.
5. Double-click the new AutoSiteCoverage registry entry.
6. Under Value data, type 0 to disable automatic site coverage or type 1 to enable it.

Automatic Site Link Bridge
By default, all site links are bridged, or transitive. This allows any two sites that are not connected by an explicit site link to communicate directly, through a chain of intermediary site links and sites. One advantage to bridging all site links is that your network is easier to maintain because you do not need to create a site link to describe every possible path between pairs of sites.

Bridge All Site Link
The setting inside AD Sites and Services to enable or disable site link bridges. If you disable site link bridging and you are using File Replication Service (FRS) to replicate DFS replicas, which include the SYSVOL share, the DFS site-costing ability is also disabled.

To turn off automatic site link bridging for KCC operation without hampering the ability of DFS to use Intersite Messaging to calculate the cost matrix. This site option is set by running the command repadmin /siteoptions +W2K3_BRIDGES_REQUIRED. This option is applied to the NTDS Site Settings object (CN=NTDS Site Settings,CN=SiteName,CN=Sites,CN=Configuration,DC=ForestRootDomain). When this method is used to disable automatic site link bridging (as opposed to turning off Bridge all site links), default Intersite Messaging options enable the site-costing calculation to occur for DFS

Site Costed Referall,
Defining the SiteCostedReferrals Registry value on the domain controllers will alter the DFS referrals so that all local domain controllers are listed first, randomly ordered, then the “next best” site’s domain controllers, and then all others. The “next best” logic is based on site link costs where the lower cost is preferred.