What Does Cname Mean In Dns Records How Does It Work

The Active Directory is a distributed database. It is used to store information about objects on a network and to permit users to access this information. Active Directory replication is used to synchronize partition replicas among domain controllers in an Active Directory forest. This replication process permits users to access information from wherever they are on the network. When this replication process does not work as designed, users may experience an interruption in the services that rely on information from the Active Directory: domain logon and access to network resources, such as files and printers.

Active Directory replication relies on the Domain Name System (DNS) to resolve names to IP addresses as needed. An Active Directory domain controller typically registers a variety of DNS records with its configured DNS server when its netlogon service starts. DNSLint is a Microsoft Windows utility that runs on Windows 2000-and-later operating systems. Among other uses, it can help you troubleshoot Active Directory replication issues. Specifically, it can help you determine two things: • Whether all DNS servers that are supposed to be authoritative for the root of an Active Directory forest actually have the necessary DNS records to successfully synchronize partition replicas among domain controllers in an Active Directory forest. DNSLint identifies which DNS records are missing from each authoritative DNS server.
• Whether a particular Active Directory domain controller can resolve all of the necessary DNS records to successfully synchronizing partition replicas among domain controllers in an Active Directory forest. DNSLint identifies which DNS records cannot be resolved by the domain controller being tested.
Troubleshooting
If an Active Directory domain controller wants to replicate with another domain controller, it uses DNS to find other domain controllers. This process works as follows: 1. The domain controller initiating the replication (DC1) queries the Active Directory in searching for its configured replication partners. These replication partners are typically defined by the Knowledge Consistency Checker (KCC), but can also be defined manually. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
244368 (http://support.microsoft.com/kb/244368/) How to optimize Active Directory replication in a large network
DC1 knows only the name of the domain controller that it wants to replicate with (DC2). It finds a GUID in the Active Directory that matches the target domain controller's name (DC2). Note that each domain controller in the forest should have its own unique GUID.
2. Now that DC1 knows DC2's GUID, it must find DC2's IP address so that it can connect to it across the network. To do this, DC1 uses DNS. DC1 sends a recursive DNS query to its locally configured DNS server for a CNAME record. The format of this record always matches the following
guid._msdcs.root of Active Directory forest
Where guid is the GUID that DC1 found in the Active Directory, and root of Active Directory forest is the root of the Active Directory forest. For example
91f9b084-4876-4b59-be17-59e74c340221._msdcs.reskit.com
where 91f9b084-4876-4b59-be17-59e74c340221 is a GUID and reskit.com is the root of the Active Directory forest.

DC1's locally configured DNS server should respond to the query for the CNAME with an alias. The alias is another name for the GUID. For example, the GUID 91f9b084-4876-4b59-be17-59e74c340221 is resolved to dc-02.reskit.com.
3. Now that DC1 knows the alias for the GUID, it must resolve the alias to an IP address so that it can connect to DC2 across the network. DC1 sends a recursive DNS query to its locally configured DNS server for a Host (A) record that matches the name of the alias. The DNS server should respond with the IP address that has been mapped to the alias -- for example, 169.254.66.7
4. Now that DC1 knows DC2's IP address, it can connect to DC2 over the network and replicate Active Directory data.
If this process is unsuccessful, Active Directory replication between the domain controllers is also unsuccessful, and data may become inconsistent on the domain controllers. DNSLint can help to determine whether the DNS records used in this process are in place and can be resolved. 1. To determine whether DNS is causing an Active Directory replication problem among domain controllers in an Active Directory forest, run the following command
dnslint /ad 169.254.32.1 /s 169.254.10.22
where the /ad parameter is used to specify an Active Directory domain controller that can be used to find the GUIDs for all the domain controllers in the Active Directory forest. By default, all domain controllers in a forest should have this information. The /s option is required when you use the /ad function. The /s option is used to tell DNSLint the IP address of a DNS server that is authoritative for the _msdcs.forest root zone.

When you run this command, DNSLint first contacts the Active Directory domain controller specified after the /ad switch (169.254.32.1). This command causes DNSLint to query the Active Directory on this domain controller for all the GUIDs in the Active Directory forest. Specifically, it queries the following location in the Active Directory
CN=NTDS Settings, CN=Sites,CN=Configuration,DC=reskit,DC=com
where DC=reskit,DC=com is the root of the Active Directory forest.

This type of Lightweight Directory Access Protocol (LDAP) query requires authentication to the Active Directory. Typically, DNSLint runs under the security context of the user who ran the command. This user's credentials are used to authenticate to the Active Directory during the LDAP bind operation. If the credentials are valid and the user has access to this information in the Active Directory, the bind succeeds and the Active Directory is searched for the GUIDs. If the bind is unsuccessful, the search is not performed and the whole operation is unsuccessful. DNSLint returns an error to the user in these cases.

If a list of GUIDs is returned from the specified domain controller, DNSLint sends a DNS query to the DNS server, specified by using the /s option. In the example provided earlier in this step, DNS queries would be sent to 169.254.10.22. If this DNS server is not authoritative for the _msdcs.root of Active Directory forest, the operation may end without finding any DNS records for the GUIDs found earlier. The /s option must specify the IP address of a DNS server that is authoritative for the _msdcs.root of Active Directory forest subdomain.

In some environments, such as those in which a DNS server that does not accept dynamic updates hosts the root zone, the _msdcs zone has been delegated to a DNS server that is not authoritative for the root of the Active Directory forest. DNSLint checks for this delegation before proceeding with next DNS queries. This step helps to avoid sending DNS queries to DNS servers that should not be tested.

DNSLint tries to discover other DNS servers that are authoritative for the root of Active Directory forest as it processes the DNS queries. After DNSLint has found DNS servers that are authoritative for the root of Active Directory forest, it queries the DNS server (or servers) for the CNAME records that it finds in the Active Directory. As it resolves each CNAME record to an alias, DNSLint also tries to resolve the glue (A) record for each alias. As mentioned earlier in this article, these DNS records are required for Active Directory replication.

DNSLint then creates a report in HTML format (and optionally a text report). The report includes all of the GUIDs found in the Active Directory, the DNS servers found to be authoritative for the root of Active Directory forest, and the results of all the CNAME and glue (A) record queries to those servers. It reports which CNAME records and which glue (A) records were missing on each DNS server. This report can be used to correct any DNS issues that may be causing Active Directory replication problems, such as missing or incorrect DNS records.
2. To determine whether a particular Active Directory domain controller can resolve all of the DNS records needed to successfully synchronize partition replicas among domain controllers in an Active Directory forest, run the following command on the domain controller being tested:
dnslint /ad /s localhost
Because no IP address is specified after the /ad option, 127.0.0.1 is be used. This means that the domain controller will query itself for the list of GUID records. You can specify an alternative domain controller LDAP server if you want. If you specify localhost after the /s option, this tells DNSLint to use the DNS server (or servers) configured on the domain controller that is being tested to resolve the CNAME and glue (A) records used for Active Directory replication. This specification sends recursive DNS queries to the domain controller's locally configured DNS server (or servers) to determine whether the domain controller can resolve the necessary records. This does not mean that all of the local domain controller's DNS servers are checked for these records. The domain controller's DNS server list is managed according to its default behavior. This means that the second DNS server in the list is used only if the first one does not respond. This test only determines whether a domain controller can resolve the DNS records used for Active Directory replication. No specific DNS server is tested.

The report that DNSLint generates can then be used to correct any DNS issues that may cause Active Directory replication problems, such as missing or incorrect DNS records.

The following file is available for download from the Microsoft Download Center:
Download the dnslint.v204.exe package now. (http://download.microsoft.com/download/2/7/2/27252452-e530-4455-846a-dd68fc020e16/dnslint.v204.exe)

For more information about how to download Microsoft Support files, click the following article number to view the article in the Microsoft Knowledge Base:
119591 (http://support.microsoft.com/kb/119591/) How to obtain Microsoft support files from online services
Microsoft scanned this file for viruses. Microsoft used the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help prevent any unauthorized changes to the file.

For more information about the DNSLint utility, click the following article number to view the article in the Microsoft Knowledge Base:
321045 (http://support.microsoft.com/kb/321045/) Description of the DNSLint utility
Back to the top

--------------------------------------------------------------------------------

APPLIES TO
• Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
• Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
• Microsoft Windows Server 2003, Standard Edition (32-bit x86)
• Microsoft Windows Server 2003, 64-Bit Datacenter Edition
• Microsoft Windows Server 2003, Enterprise x64 Edition
• Microsoft Windows XP Home Edition
• Microsoft Windows XP Professional
• Microsoft Windows 2000 Server
• Microsoft Windows Small Business Server 2003 Premium Edition
• Microsoft Windows Small Business Server 2003 Standard Edition
http://support.microsoft.com/kb/321046

http://web.mit.edu/6.033/www/assignments/handson-dns.html
http://www.xreg.co.uk/faq.html
reply or leave comment