Tip

DNSLint to the rescue

Bill Boswell, SearchWin2000.com contributor

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.


Bill Boswell Author, Inside Windows Server 2003

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

Requires Free Membership to View

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.


This was first published in June 2003

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.