dns服务器在做nslookup测试的时候,出现dns timeout 2 seconds的错误解释

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介:
最近同事报障,说是在内网进行nslookup测试时发现:当使用内网DNS服务器192.168.1.1进行解析时,DNS服务器响应非常快,而且没有 任何错误;但当使用DMZ区的服务器51.144.198.99进行测试时,发现总是提示请求超时,然后再返回正确解析。由此怀疑我们正在使用的防火墙在 处理DNS请求时存在问题。 

国内的防火墙产品也确实一点也不争气,在使用过程中总是会出现一些莫名其妙的问题,如在低版本操作系统中支持的功能在高版本中可能就支持不好,有时为了解 决低版本操作系统中的一个Bug而进行防火墙操作系统升级,结果可能会是解决了一个,又新出来一堆!这不,才升级了防火墙,同事就找上门来了,没有办法, 谁让咱用的防火墙厂家不争气呢,人家怀疑咱这里出问题也是正常啊! 

首先查看故障现象,按同事所说进行测试: 

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. (请求超时) 

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 (内网DNS服务器) 



Pinging 192.168.1.1 with 32 bytes of data: 



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

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

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

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



Ping statistics for 192.168.1.1: 

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), 

Approximate round trip times in milli-seconds: 

Minimum = 0ms, Maximum = 0ms, Average = 0ms 



C:/>ping 51.144.198.99  (DMZ区DNS服务器) 



Pinging 51.144.198.99 with 32 bytes of data: 



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

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

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

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



Ping statistics for 51.144.198.99: 

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), 

Approximate round trip times in milli-seconds: 

Minimum = 0ms, Maximum = 0ms, Average = 0ms 



经过ping命令的测试,测试主机到内网DNS服务器、DMZ区DNS服务器响应都很快,所以线路应该没有问题。如果是防火墙策略问题,则nslookup查询时应该完全无响应,而不是在后面又进行了正确解析。 

那么可能是下面的几种原因: 

可能1:DMZ区服务器有问题;经过在DMZ区其它服务器进行nslookup测试,发现DMZ区的DNS服务器响应正常,由此排除了这种可能。 

可能2:防火墙有问题,有可能是高吞吐量时响应有问题。在晚上流量比较小时进行了nslookup测试,发现故障现象仍然存在。看来并不是网络吞吐量引起的防火墙问题。 

难道防火墙存在处理DNS请求时存在问题?不敢这么想!一年前我们发现防火墙存在着FTP问题,结果到现在还没有解决!防火墙厂家的开发人员太有才了!好希望不是防火墙的问题! 

由于在内网进行测试时所使用的主机均为同网段主机,所以尝试更换一台不同网段的主机进行测试,结果竟然―――没有问题! 

OK,只要有机器没有问题,那这个DNS的问题就应该不是防火墙引起的!只要不是防火墙的问题,那就好解决!呵呵,真是怕了防火墙厂家了! 

解决技术问题,如果从表面看不出是什么问题引起的,那么经常用的功能就是Debug,只有从更深层次去查看,才更容易发现问题。那么nslookup工具有没有Debug功能呢?经过简单查看帮助,发现其有两个Debug参数: 

[no]debug - print debugging information(显示一般调试信息) 

[no]d2 - print exhaustive debugging information(显示详细调试信息) 

OK,准备使用d2参数查看两台机器执行Debug时分别做了些什么动作! 



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 

经过对照两台PC机的输出,不难发现,问题就出在PC-A在进行nslookup查询时,多出了一次查询,而且多出的这次查询的对象就是www.netadmin.com.cn.dgic.cn,其最后的后缀(dgic.cn)就是测试机PC-A所在的域名。 

在PC使用Nslookup工具进行域名查询测试时,如果该PC是活动目录中的一台主机,默认情况下该主机除了向DNS服务器递交真正需要查询的域名外,它还向DNS服务器递交“查询的域名+活动目录域后缀”(可能为多个)”这样的请求。 

PC-A是活动目录dgic.cn中的一员,在其向内网DNS服务器进行查询请求时,它会提交两个请求,分别 为:www.netadmin.com.cn.dgic.cn和www.netadmin.com.cn。对于前者,内网DNS服务器 192.168.1.1中含有域dgic.cn,但没有www.netadmin.com.cn.dgic.cn主机记录(A记录),nslookup没 有任何输出;对于后者,其进行一般A记录的查询,并进行正确输出显示。当PC-A使用DMZ区DNS服务器进行nslookup查询时,同样道理,它也会 向其发送两个查询请求,对于www.netadmin.com.cn.dgic.cn,由于DMZ区DNS服务器没有域dgic.cn的记录,于是其向上 层服务器查询,在得不到响应的情况下最终返回查询超时;对于www.netadmin.com.cn这一域名,其可以进行查询得到结果,并最终正常输出。 

PC-B只是工作组中一台主机,所以没有域后缀,这样,当其进行nslookup测试时,无论其使用内网DNS服务器还是DMZ区DNS服务器,其只提交一项域名请求,那就是www.netadmin.com.cn,所以查询结果没有超时现象。 

最终,得出了结论:这并不是一个网络故障,而是nslookup工具的原因。 

那么有没有办法禁止nslookup这种行为呢,办法还是有的。其一是使用nslookup中的search参数;其二就是使用srchlist参数。 

Search参数:启用域名搜索列表。这也是默认设置,也就是在使用nslookup进行域名测试时,nslookup会把主机的域名缀附加到所要请求的域名后面。如果想禁用它,则只需在nslookup环境中,使用set nosearch命令即可禁用。 

Srchlist参数:使用域名搜索列表时所要附加的域名列表。默认情况下其值即主机所在的活动目录。如果想更改,可以在nslookup环境中 使用命令“set srchlist=域名1/域名2/域名3”,如果想禁止nslookup工具附加域名,则只需“set srchlist=”即可。 

下面用nslookup工具的另外一种用法来演示这两个参数的使用,并进而证实我们的结论: 

例一:使用默认设置 

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 



例二:使用“nosearch”参数 

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 



例三:使用“srchlist=”参数 

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 




本文转自 onesthan 51CTO博客,原文链接:http://blog.51cto.com/91xueit/1744866,如需转载请自行联系原作者

相关文章
|
3月前
|
运维 Prometheus 监控
如何在测试环境中保持操作系统、浏览器版本和服务器配置的稳定性和一致性?
如何在测试环境中保持操作系统、浏览器版本和服务器配置的稳定性和一致性?
|
26天前
|
存储 运维 资源调度
阿里云服务器经济型e实例解析:性能、稳定性与兼顾成本
阿里云经济型e云服务器以其高性价比、稳定可靠的性能以及灵活多样的配置选项,成为了众多企业在搭建官网时的首选。那么,阿里云经济型e云服务器究竟怎么样?它是否能够满足企业官网的搭建需求?本文将从性能表现、稳定性与可靠性、成本考虑等多个方面对阿里云经济型e云服务器进行深入剖析,以供大家参考选择。
106 37
|
5天前
|
存储 人工智能 并行计算
2025年阿里云弹性裸金属服务器架构解析与资源配置方案
🚀 核心特性与技术创新:提供100%物理机性能输出,支持NVIDIA A100/V100 GPU直通,无虚拟化层损耗。网络与存储优化,400万PPS吞吐量,ESSD云盘IOPS达100万,RDMA延迟<5μs。全球部署覆盖华北、华东、华南及海外节点,支持跨地域负载均衡。典型应用场景包括AI训练、科学计算等,支持分布式训练和并行计算框架。弹性裸金属服务器+OSS存储+高速网络综合部署,满足高性能计算需求。
|
6天前
|
弹性计算 运维 网络安全
阿里云轻量应用服务器产品解析与搭建个人博客网站教程参考
轻量应用服务器(Simple Application Server)作为阿里云面向单机应用场景推出的云服务器产品,以其一键部署、一站式管理、高性价比等特性,深受个人开发者、中小企业及入门级用户的喜爱。本文将全面解析阿里云轻量应用服务器的产品优势、应用场景、使用须知,以及使用轻量应用服务器搭建个人博客网站的详细教程,帮助用户更好地了解和使用这一产品。
|
26天前
|
安全 网络协议 网络安全
解析HTTP代理服务器不稳定致使掉线的关键原因
随着数字化发展,网络安全和隐私保护成为核心需求。HTTP代理服务器掉线原因主要包括:1. 网络问题,如本地网络不稳定、路由复杂;2. 服务器质量差、IP资源不稳定;3. 用户配置错误、超时或请求频率异常;4. IP失效或协议不兼容。这些问题会影响连接稳定性。
62 8
|
2月前
|
安全 编译器 Linux
深入解析与防范:基于缓冲区溢出的FTP服务器攻击及调用计算器示例
本文深入解析了利用缓冲区溢出漏洞对FTP服务器进行远程攻击的技术,通过分析FreeFlow FTP 1.75版本的漏洞,展示了如何通过构造过长的用户名触发缓冲区溢出并调用计算器(`calc.exe`)。文章详细介绍了攻击原理、关键代码组件及其实现步骤,并提出了有效的防范措施,如输入验证、编译器保护和安全编程语言的选择,以保障系统的安全性。环境搭建基于Windows XP SP3和Kali Linux,使用Metasploit Framework进行攻击演示。请注意,此内容仅用于教育和研究目的。
92 4
|
2月前
|
域名解析 弹性计算 安全
阿里云服务器租用、注册域名、备案及域名解析完整流程参考(图文教程)
对于很多初次建站的用户来说,选购云服务器和注册应及备案和域名解析步骤必须了解的,目前轻量云服务器2核2G68元一年,2核4G4M服务器298元一年,域名注册方面,阿里云推出域名1元购买活动,新用户注册com和cn域名2年首年仅需0元,xyz和top等域名首年仅需1元。对于建站的用户来说,购买完云服务器并注册好域名之后,下一步还需要操作备案和域名绑定。本文为大家展示阿里云服务器的购买流程,域名注册、绑定以及备案的完整流程,全文以图文教程形式为大家展示具体细节及注意事项,以供新手用户参考。
|
2月前
|
存储 监控 调度
云服务器成本优化深度解析与实战案例
本文深入探讨了云服务器成本优化的策略与实践,涵盖基本原则、具体策略及案例分析。基本原则包括以实际需求为导向、动态调整资源、成本控制为核心。具体策略涉及选择合适计费模式、优化资源配置、存储与网络配置、实施资源监控与审计、应用性能优化、利用优惠政策及考虑多云策略。文章还通过电商、制造企业和初创团队的实际案例,展示了云服务器成本优化的有效性,最后展望了未来的发展趋势,包括智能化优化、多云管理和绿色节能。
|
3月前
|
缓存 Ubuntu Linux
Linux环境下测试服务器的DDR5内存性能
通过使用 `memtester`和 `sysbench`等工具,可以有效地测试Linux环境下服务器的DDR5内存性能。这些工具不仅可以评估内存的读写速度,还可以检测内存中的潜在问题,帮助确保系统的稳定性和性能。通过合理配置和使用这些工具,系统管理员可以深入了解服务器内存的性能状况,为系统优化提供数据支持。
105 4
|
3月前
|
存储 机器学习/深度学习 编解码
阿里云服务器计算型c8i实例解析:实例规格性能及使用场景和最新价格参考
计算型c8i实例作为阿里云服务器家族中的重要成员,以其卓越的计算性能、稳定的算力输出、强劲的I/O引擎以及芯片级的安全加固,广泛适用于机器学习推理、数据分析、批量计算、视频编码、游戏服务器前端、高性能科学和工程应用以及Web前端服务器等多种场景。本文将全面介绍阿里云服务器计算型c8i实例,从规格族特性、适用场景、详细规格指标、性能优势、实际应用案例,到最新的活动价格,以供大家参考。

相关产品

  • 云解析DNS
  • 推荐镜像

    更多