When the DNS server performs the NSLookup test, the DNS timeout 2 seconds error message is displayed.

Source: Internet
Author: User
Tags nameserver nslookup nslookup tool
Recently, my colleague reported that during the NSLookup test on the Intranet, I found that when I used the Intranet DNS server 192.168.1.1 for resolution, the DNS server responded very quickly and did not
Any errors. However, when the DMZ server 51.144.198.99 is used for testing, the system always prompts that the request times out and returns the correct resolution. We suspect that the firewall we are using is
An error occurred while processing DNS requests.

Firewall Products in China do not compete at all, and some inexplicable problems will always occur during use, for example, features supported in earlier operating systems may not be supported in later versions.
If you upgrade the firewall operating system based on a bug in the earlier version of the operating system, the result may be a solution and a bunch of new ones! No, I upgraded the firewall, and my colleagues came to the door. There is no way,
Who makes our firewall manufacturers not angry? people suspect that the problem is normal!

First, check the fault symptom and perform the test as described by colleagues:

C:/> NSLookup

Default Server: DNS. DG

Address: 192.168.1.1

> Www.netadmin.com.cn

Server: DNS. DG

Address: 192.168.1.1

Non-Authoritative Answer:

Name: www.365master.com

Address: 219.141.209.244

Aliases: www.netadmin.com.cn

> Server 51.144.198.99

Default Server: [51.144.198.99]

Address: 51.144.198.99

> Www.netadmin.com.cn

Server: [51.144.198.99]

Address: 51.144.198.99

DNS request timed out. (request timeout)

Timeout was 2 seconds.

Non-Authoritative Answer:

Name: www.365master.com

Address: 219.141.209.244

Aliases: www.netadmin.com.cn

C:/> Ping 192.168.1.1 (intranet DNS server)

Pinging 192.168.1.1 with 32 bytes of data:

Reply from 192.168.1.1: bytes = 32 time <1 ms TTL = 127

Reply from 192.168.1.1: bytes = 32 time <1 ms TTL = 127

Reply from 192.168.1.1: bytes = 32 time <1 ms TTL = 127

Reply from 192.168.1.1: bytes = 32 time <1 ms TTL = 127

Ping statistics for 192.168.1.1:

Packets: Sent = 4, stored ED = 4, lost = 0 (0% loss ),

Approximate round trip times in Milli-seconds:

Minimum = 0 ms, maximum = 0 ms, average = 0 ms

C:/> Ping 51.144.198.99 (DMZ zone DNS server)

Pinging 51.144.198.99 with 32 bytes of data:

Reply from 51.144.198.99: bytes = 32 time <1 ms TTL = 126

Reply from 51.144.198.99: bytes = 32 time <1 ms TTL = 126

Reply from 51.144.198.99: bytes = 32 time <1 ms TTL = 126

Reply from 51.144.198.99: bytes = 32 time <1 ms TTL = 126

Ping statistics for 51.144.198.99:

Packets: Sent = 4, stored ED = 4, lost = 0 (0% loss ),

Approximate round trip times in Milli-seconds:

Minimum = 0 ms, maximum = 0 ms, average = 0 ms

Through the ping command test, the test host to the Intranet DNS server, DMZ area DNS server response is very fast, so the line should be no problem. If it is a firewall policy issue, NSLookup queries should have no response at all, rather than correct parsing later.

This may be due to the following reasons:

Possible 1: There is a problem with the DMZ server. After testing the NSLookup on other DMZ servers, we found that the DNS server in the DMZ zone responded normally, thus eliminating this possibility.

Possible 2: There is a problem with the firewall, and there may be a problem with the response at high throughput. The NSLookup test was conducted at night when the traffic volume was relatively small, and the fault still exists. It does not seem like a firewall problem caused by network throughput.

Is there a problem with the firewall when processing DNS requests? Dare not think so! A year ago, we found that there was an FTP problem in the firewall, and the result has not been resolved yet! Developers from firewall manufacturers are too talented! Hope it's not a firewall problem!

Because all the hosts used for testing on the Intranet are in the same network segment, I tried to replace a host of different network segments for testing. The result turned out to be--No problem!

OK, as long as there is no problem with the machine, the DNS problem should not be caused by the firewall! As long as it is not a firewall problem, it can be solved! Haha, I am afraid of firewall manufacturers!

To solve technical problems, if the problem cannot be seen from the surface, debug is often used. It is easier to discover problems only by looking at them at a deeper level. Does the NSLookup tool have the debug function? After a simple view, we found that there are two debug parameters:

[No] Debug-print debugging information (display General debugging information)

[No] D2-print exhaustive debugging information (display detailed debugging information)

OK. Use the D2 parameter to view the actions performed by the two machines during debugging!

PC-A (Windows XP ):

C:/> NSLookup

Default Server: DNS. DG

Address: 192.168.1.1

> Server 51.144.198.99

Default Server: [51.144.198.99]

Address: 51.144.198.99

> Set D2

> Www.netadmin.com.cn

Server: [51.144.198.99]

Address: 51.144.198.99

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

Sendrequest (), Len 45

Header:

Opcode = query, id = 18, RCODE = noerror

Header flags: Query, want Recursion

Questions = 1, answers = 0, authority records = 0, additional = 0

Questions:

Www.netadmin.com.cn.dgic.cn, type = A, class = in

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

DNS request timed out.

Timeout was 2 seconds.

Timeout (2 secs)

Sendrequest failed

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

Sendrequest (), Len 37

Header:

Opcode = query, id = 19, RCODE = noerror

Header flags: Query, want Recursion

Questions = 1, answers = 0, authority records = 0, additional = 0

Questions:

Www.netadmin.com.cn, type = A, class = in

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

Got answer (84 bytes ):

Header:

Opcode = query, id = 19, RCODE = noerror

Header flags: Response, want recursion, recursion avail.

Questions = 1, answers = 2, authority records = 0, additional = 0

Questions:

Www.netadmin.com.cn, type = A, class = in

Answers:

-> Www.netadmin.com.cn

Type = cname, class = In, dlen = 19

Canonical name = www.365master.com

TTL = 698 (11 mins 38 SECs)

-> Www.365master.com

Type = A, class = In, dlen = 4

Internet address = 219.141.209.244

TTL = 700 (11 mins 40 SECs)

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

Non-Authoritative Answer:

Name: www.365master.com

Address: 219.141.209.244

Aliases: www.netadmin.com.cn

PC-B (Windows 2000 Server ):

C:/> NSLookup

Default Server: DNS. DG

Address: 192.168.1.1

> Server 51.144.198.99

Default Server: [51.144.198.99]

Address: 51.144.198.99

> Set D2

> Www.netadmin.com.cn

Server: [51.144.198.99]

Address: 51.144.198.99

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

Sendrequest (), Len 37

Header:

Opcode = query, id = 5, RCODE = noerror

Header flags: Query, want Recursion

Questions = 1, answers = 0, authority records = 0, additional = 0

Questions:

Www.netadmin.com.cn, type = A, class = in

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

Got answer (132 bytes ):

Header:

Opcode = query, id = 5, RCODE = noerror

Header flags: Response, want recursion, recursion avail.

Questions = 1, answers = 2, authority records = 2, additional = 0

Questions:

Www.netadmin.com.cn, type = A, class = in

Answers:

-> Www.netadmin.com.cn

Type = cname, class = In, dlen = 19

Canonical name = www.365master.com

TTL = 2521 (42 mins 1 sec)

-> Www.365master.com

Type = A, class = In, dlen = 4

Internet address = 219.141.209.244

TTL = 2917 (48 mins 37 SECs)

Authority records:

-> 365master.com

Type = NS, class = In, dlen = 16

Nameserver = dns11.hichina.com

TTL = 2917 (48 mins 37 SECs)

-> 365master.com

Type = NS, class = In, dlen = 8

Nameserver = dns12.hichina.com

TTL = 2917 (48 mins 37 SECs)

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

Non-Authoritative Answer:

Name: www.365master.com

Address: 219.141.209.244

Aliases: www.netadmin.com.cn

After comparing the two PC output, it is not difficult to find that the problem is in the PC-A in NSLookup query, more than a query, and the more of the query object is www.netadmin.com.cn.dgic.cn, its last suffix (dgic.cn) is the testing machine PC-A domain name.

When a PC uses the NSLookup tool to perform a domain name query test, if the PC is a host in the Active Directory, by default, the host not only submits the domain name that actually needs to be queried to the DNS server, it also submits a "domain name to be queried + domain Suffix of the Active Directory" (possibly multiple) to the DNS server.

PC-A is a member of the Active Directory dgic.cn, when it queries the Intranet DNS server, it will submit two requests, respectively
Www.netadmin.com.cn.dgic.cn and www.netadmin.com.cn. For the former, the Intranet DNS Server
192.168.1.1 contains the domain dgic.cn, but there is no host record (a record) for www.netadmin.com.cn.dgic.cn, and NSLookup does not
There is any output; for the latter, it queries the general a record and correctly displays the output. When the PC-A uses the DMZ zone DNS server for NSLookup queries, it also
Send two query requests to www.netadmin.com.cn.dgic.cn. Because the DNS server in the DMZ zone does not have a domain dgic.cn record
When a layer Server Query fails to receive a response, the query times out. For the domain name www.netadmin.com.cn, the query results can be obtained and the query results can be output normally.

PC-B is just a host in the workgroup, so there is no domain suffix, so that when it performs an NSLookup test, whether it uses an intranet DNS server or DMZ zone DNS server, it only submits one domain name request, that is www.netadmin.com.cn, so the query result does not time out.

Finally, it is concluded that this is not a network fault, but a reason for the NSLookup tool.

Is there any way to disable NSLookup. The first is to use the search parameter in NSLookup; the second is to use the srchlist parameter.

Search parameter: Enable Domain name search list. This is also the default setting, that is, when NSLookup is used for domain name testing, NSLookup will append the host domain name suffix to the domain name to be requested. To disable it, you only need to use the set nosearch command in the NSLookup environment.

Srchlist parameter: the list of domain names to be added when the domain name search list is used. By default, the value is the Active Directory of the host. If you want to change it, you can go to the NSLookup Environment
Run the "set srchlist = domain name 1/domain name 2/Domain Name 3" command. to disable the NSLookup tool from attaching a domain name, you only need
Srchlist =.

The following uses another NSLookup tool to demonstrate the use of these two parameters and further confirms our conclusion:

Example 1: use the default settings

C:/> NSLookup www.netadmin.com.cn 51.144.198.99

* ** Can't find server name for address 51.144.198.99: non-existent domain

Server: Unknown

Address: 51.144.198.99

DNS request timed out.

Timeout was 2 seconds.

Non-Authoritative Answer:

Name: www.365master.com

Address: 219.141.209.244

Aliases: www.netadmin.com.cn

Example 2: Use the "nosearch" parameter

C:/> NSLookup-nosearch www.netadmin.com.cn 51.144.198.99

* ** Can't find server name for address 51.144.198.99: non-existent domain

Server: Unknown

Address: 51.144.198.99

Non-Authoritative Answer:

Name: www.365master.com

Address: 219.141.209.244

Aliases: www.netadmin.com.cn

Example 3: Use the "srchlist =" parameter

C:/> NSLookup-srchlist = www.netadmin.com.cn 51.144.198.99

* ** Can't find server name for address 51.144.198.99: non-existent domain

Server: Unknown

Address: 51.144.198.99

Non-Authoritative Answer:

Name: www.365master.com

Address: 219.141.209.244

Aliases: www.netadmin.com.cn

Note:

1. The IP address in this article is a security consideration and the real IP address is not used;

2. All input commands and parameters are in black italic.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.