Select the product you need help with
- Internet Explorer
- Windows Phone
- More products
Description of the DNSLint utility
Article ID: 321045 - View products that this article applies to.
This article was previously published under Q321045
DNSLint is a Microsoft Windows utility that helps you to diagnose common DNS name resolution issues.
The following file is available for download from the Microsoft Download Center:
For additional information about how to download Microsoft Support files, click the following article number to view the article in the Microsoft Knowledge Base:
Download the Dnslint.exe package now.
Collapse this imageExpand this image
119591Microsoft 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 to prevent any unauthorized changes to the file.
(http://support.microsoft.com/kb/119591/ )How to Obtain Microsoft Support Files from Online Services
DNSLint has three functions that verify Domain Name System (DNS) records and generate an HTML report. The three functions are:
dnslint /d domain_name | /ad [LDAP_IP_address] | /ql input_fileYou must specify either /d, /ad, or /ql when you run DNSLint. Other switches are optional.
[/c [smtp,pop,imap]] [/no_open] [/r report_name]
[/t] [/test_tcp] [/s DNS_IP_address] [/v] [/y]
You use the /d switch to request domain name tests. This switch is useful when you troubleshoot lame delegation issues.
Use /c to request connectivity tests on e-mail servers.
Use the /r switch to specify the name of the report file that is created.
Use /y to overwrite an existing report file without being prompted. The /y switch is useful in scripts.
To run DNSLint, you must use one of the three following parameters:
Use the /ad (Active Directory test) switch to test the DNS records responsible for Active Directory forest replication. After the /ad switch, specify the IP address of an LDAP server that is used for this test. Typically, this is an Active Directory domain controller. If DNSLint is running on a domain controller, no IP address is necessary because the default value for this switch is 127.0.0.1.
Use the /ql (query list test) switch to test the DNS records specified in a text input file. Specify the full path and name of the text input file immediately after the switch. Run dnslint /ql autocreate to generate a sample text input file called In-dnslint.txt. This file contains an explanation on the required format. You can use this file as a template to create other input files.
More optional switches
The /v (verbose) switch turns "verbose mode" on. With this switch on, DNSLint will output the steps it is taking to collect data to the screen. You can send this output to a file. For example, dnslint /v /d msn.com.
By default, the name of the report that DNSLint generates is Dnslint.htm. With the /r (report) switch, you can specify the name and location of the report file that DNSLint generates. You can give the report file the same name as the domain name or DNS server that was tested. The ".htm" file name extension is appended to the report name automatically because the report is in HTML format.
By default, DNSLint tries to automatically open the report file after it is generated, by using whatever program is associated with the report file's .htm file. Typically, Microsoft Internet Explorer is associated with the .htm extension. There is no way to change the report format to something other than HTML by using DNSLint.
To define the location to which the report file is written, specify the full path and name of the report file. DNSLint supports both local drives and Universal Naming Convention (UNC) paths. For example, the command dnslint /d msn.com /r c:\reports\reskit creates a report called Reskit.htm in the C:\Reports folder. The command dnslint /d mydom.local /r \\server1\reports\mydom creates a report on the remote system called server1 in the Reports share. The report name is Mydom.htm.
If you specify the /t (text) switch, DNSLint generates a text report and an HTML report. The text report uses the same name as the .htm report except that its file name extension is .txt. The file is created in the same folder as the .htm file. For example, the command dnslint /d msn.com /r c:\reports\reskit /t creates two reports in the C:\Reports folder. One report is called Reskit.htm and the other is called Reskit.txt.
By default, when DNSLint detects that a report file with the same name as the one that it is going to generate already exists in the target folder, DNSLint prompts you to overwrite the file. With the /y option, DNSLint can overwrite an existing report file without prompting you for permission. Both the .htm file and the optional .txt file are overwritten when you use this option.
The command dnslint /y /d msn.com /r c:\reports\reskit /t creates two reports in the C:\Reports folder. One report is called Reskit.htm and the other is called Reskit.txt. Existing report files are overwritten without prompting you.
The /no_open switch prevents DNSLint from automatically opening the report after it is generated. This option is useful when you use DNSLint in scripts when you do not want to review the reports immediately or review the reports from the system that DNSLint was run from. For example, the command dnslint /y /d msn.com /no_open generates a report called Dnslint.htm that overwrites a pre-existing report with the same name, without prompting the user. DNSLint does not automatically open the report when it is completed.
Use the /test_tcp (test TCP port 53) option to request that TCP port 53 be tested when /d is used. Many DNS servers on the Internet today do not accept DNS queries on TCP port 53, to avoid possible attacks on that port. By default, only UDP port 53 is tested when DNSLint is run. Specifying the /test_tcp option will get DNSLint to send a single DNS query by TCP and report whether a response was received.
You can use the /test_tcp option with /d and /ad. However, you cannot use the /test_tcp option with /ql or the /ad /s localhost combination. With the /ql function, TCP port 53 can be tested directly from the input file. The /ad /s localhost function tests whether the locally configured DNS servers can resolve DNS records used for Active Directory Forest replication. You can test TCP port 53 connectivity by using /ad /s ip_addr instead, where ip_addr is the IP address of a DNS server that is authoritative for the _msdcs zone in the root of the Active Directory domain.
dnslint /d microsoft.com /v /test_tcpThe /c (connectivity test) switch requests that DNSLint test well-known e-mail ports on all of the e-mail servers it finds while inspecting DNS servers for the specified domain name. The Simple Mail Transfer Protocol (SMTP), Post Office Protocol (POP version 3), and Internet Message Access Protocol (IMAP version 4) are supported. By default, when the /c switch is specified, DNSLint tries to connect to all three ports on each e-mail server that it finds. That is, TCP port 25 for SMTP, TCP port 110 for POP, and TCP port 143 for IMAP.
DNSLint reports the state that each port is in: "Listening", "Not Listening", or "No Response." If DNSLint finds that a port is Listening, it also returns the response from the port if any is returned. For example, if an SMTP port is listening, it typically returns a response that is consistent with the SMTP protocol specification, such as the following:
220 mailsrv.reskit.com Microsoft ESMTP MAIL Service, Version: 5.0.2195.3705 ready at Mon, 13 May 2002 17:08:36 -0700
When a port is reported as "Not Listening", this indicates that the e-mail server being queried has responded with a TCP packet with the Reset flag set. This indicates that there is no service or program listening on the port.
"No Response" is reported when the target e-mail server does not respond to the connection attempt. Assuming that the target server is operational and running, this indicates that the port is being filtered on the target server or somewhere between the client that is running DNSLint and target server.
The command dnslint /y /v /c /d msn.com generates a report called Dnslint.htm that overwrites a pre-existing report with the same name, without prompting the user. Because the /c option is specified, an extra section is appended to the bottom of the standard DNSLint report:
Network Connectivity TestsNOTES:
E-mail server: smtp-gw-4.msn.com
IP address: 188.8.131.52
220 cpimssmtpa18.msn.com Microsoft ESMTP MAIL Service, Version:
5.0.2195.4905 ready at Tue, 14 May 2002 09:26:06 -0700
POP response: NO RESPONSE (possibly filtered)
IMAP response: NO RESPONSE (possibly filtered)
One or more POP servers did not respond.
One or more IMAP servers did not respond.
When a target e-mail server does not respond to a connection attempt on one of its e-mail ports, DNSLint retries the connection three times. This is standard behavior for a TCP client. Because DNSLint waits for three separate TCP connection attempts to time out before DNSLint indicates that there was "No Response", this process can slow down the completion of the report. To optimize DNSLint operation, you can specify which e-mail port or ports you want to check instead of checking all three all the time.
By default, when the /c option is specified, all three TCP ports (25, 110, 143) are checked. But you can specify which ports to check after the /c option. Specify a comma-delimited list immediately after the /c option. Specify valid ports only: smtp,pop,imap. Any combination of these three ports works. For example, the command dnslint /d reskit.com /c smtp specifies that only the SMTP port (TCP port 25) should be checked.
The command dnslint /d reskit.com /c pop,smtp specifies that only the SMTP port (TCP port 25) and POP port (TCP port 110) should be checked.
The command dnslint /d reskit.com /c imap,pop specifies that only the IMAP port (TCP port 143) and POP port (TCP port 110) should be checked.
You can use the /s (server) switch with the /d and /ad functions. The /s switch has several purposes, but it only takes one type of data, a valid IP address of a DNS server (with one exception).
When you specify /d, the /s option bypasses the InterNIC Whois lookup that DNSLint performs by default. As a result, DNSLint can run tests on private networks and on domain names that are deeper than the second-level domains on the Internet. DNSLint can also test domain names that are not supported by InterNIC. At the time this article was written, InterNIC supported Whois lookups for the following domains: .biz, .com, .coop, .edu, .info, .int, .museum, .net, and .org.
When you use /ad, the /s switch is used to specify the IP address of a DNS server that is authoritative for the subdomain where DNS records used for Active Directory forest replication are registered. Typically, this is the _msdcs subdomain under the root of the Active Directory forest. For example, if the root of the Active Directory forest is called myad.reskit.com, the DNS server that hosts this domain may also be authoritative for the _msdcs.myad.reskit.com zone, where the DNS records used in Active directory replication are registered. Alternatively, the _msdcs.myad.reskit.com zone may be delegated to a different DNS server. However the DNS infrastructure has been designed, the /s option is used to specify a DNS server that is authoritative for the _msdcs.myad.reskit.com zone.
The /s option must specify a valid IP address. The only exception to this rule is the following combination:
dnslint /ad /s localhost"localhost" is not a valid IP address. When you specify this parameter with the /ad /s combination, DNSLint tests the local system's (the system that is running DNSLint) ability to resolve the DNS records that are used for Active Directory forest replication. Recursive DNS queries are sent to the local system's configured DNS server(s) to confirm that the local system can resolve the DNS records used for Active Directory forest replication. This can be useful when troubleshooting Active Directory replication problems on a particular domain controller.
Typically, not all of the local system's configured DNS servers are queried during this process. Default DNS client resolver behavior is observed, so if the DNS server at the top of the local system's DNS Server list does not respond, the next server in the list is used.
For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/261968/ )Explanation of the Server List Management feature in the domain name resolver client
Article ID: 321045 - Last Review: December 3, 2007 - Revision: 11.5