A lot can go wrong with Active Directory if you don't have a correctly configured DNS infrastructure. Not only must your Active Directory namespace be tied to a DNS zone, the zone file must contain a variety of very specific resource records to support forest-wide Active Directory operations. Your weekend gets ruined pretty quickly when a domain controller decides that it can't find its replication partner because of a DNS lookup failure, and your pager goes off as the event log fills with error messages. Or when an Exchange server can no longer find a global catalog server and begins spitting out non-delivery reports to your users.
| SPONSORED BY:
NetIQ
|
![]() |
CIO eBook for Managing and Securing the Enterprise
Need in-depth best practices for systems and security management? Register now for the FREE ebook, "From Chaos to Control: The CIO's Executive Guide to Managing and Securing the Enterprise," brought to you by NetIQ and Realtimepublishers.com. Topics covered include: Top 10 Corporate Manageability Policies; Top 10 Overlooked Vulnerabilities; Top 10 Corporate Security Breaches.
>> Take your enterprise systems and applications from chaos to control now.
|
|
![]() |
|
What you need is a tool that can assess the current DNS configuration of a domain controller or member server, compare it with the required configuration, and make suggestions about how to correct any problems. And when things go wrong, you need a tool that points out the problem quickly. Windows Server 2003 Support Tools has just such a tool. It's called DNSLint. You can use DNSLint to ferret out many common DNS configuration problems, such as:
- A network interface with TCP/IP settings that do not point to an authoritative DNS server for the zone corresponding to the Active Directory domain.
- A DNS zone file that does not contain an alias (CNAME) record with the globally unique identifier (GUID) of each domain controller along with the Host (A) records that act as glue records.
- Lame delegations to child zones where the name servers (NS) specified for the delegation either do not have corresponding glue records or the servers do not respond.
- The DNS zone corresponding to a designated Active Directory domain does not contain the requisite Service Locator (SRV) records, including the _ldap service on TCP port 389, the _kerberos service on TCP and UDP port 88. Global catalog servers must have an SRV record for the _gc service on TCP port 3268.
- The PDC Emulator FSMO role master does not have an SRV record for the _ldap service advertised under _tcp.pdc._msdcs.domain.tld (where tld stands for top level domain, such as .com or .net).
The DNSLint domain report (dnslint /d domain.tld) produces a detailed listing of each DNS server for a specified domain, whether the server responds to a query on UDP port 53, TCP port 53 (option), and whether or not the server reports authoritatively. This information helps you to track down a failed DNS server. The domain report also includes the Mail Exchange (MX) records in the zone to help with troubleshooting SMTP routing problems. A verbose option (/v) shows details about how each DNS server was found.
In addition, you can use DNSLint to determine whether a designated e-mail server listens on the correct port. For example, "dnslint -c servername" tells you whether a server listed in an MX record is or is not listening for SMTP, POP3 and IMAP4 requests. It also shows the SMTP header returned by the server to help in diagnostics.
DNSLint produces an HTML report, then launches Explorer to display the result. The results are color-coded with warnings in amber and errors in red for easy scanning. You can elect to get a text-based report, if you prefer.
You can combine DNSLint with Dcdiag (also in the Support Tools) to perform a suite of DNS-related hygiene checks prior to promoting a server to be a domain controller, or to check the current configuration of a domain controller. The /dcpromo switch for Dcdiag tests to verify that you have the correct DNS configuration for promoting a designated server to be a domain controller in a specified domain. If the configuration is not correct, the output lists any modifications that must be made to the existing DNS infrastructure. For example, if you want to know if server W2K3-S37 can be an additional domain controller in the company.com domain, use the syntax:
dcdiag /s:w2k3-s37 /dcpromo /dnsdomain:company.com /replicadc
DNS problems are the root cause of well over 80% of Active Directory (and by inference, Exchange 2000) problems. By proactively verifying the DNS configuration of your servers and domain controllers, and doing so on a regular basis, you'll increase the reliability of your infrastructure and keep your users and managers happy.
