冷门域名 dnslookup 时间

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

DNS 参考资料

› List of DNS Record Types

› dig 使用说明

› djbdns

› DNS Parameters

› dnslib for Python

这是一个创建于 3265 天前的主题，其中的信息可能已经有所发展或是发生改变。

在使用的 CloudXns 免费域名解析服务，托管了多个域名，由于目前用户量少，所以域名算是冷门域名。一般冷门域名的解析时间在 1000ms 至 2000ms 是可以理解的。但 CloudXns 技术客服给我答复的好像不一样，说他们家冷门域名解析只需要 300ms 多一点，这一点很赞。

现在问题来了，实际上 dnslookup 的时间远超过这个时间，如下
114.114.115.115 3568ms
223.5.5.5 2182ms
119.29.29.29 1159ms

在跟 CloudXns 技术客服沟通过程中，有个很逗的插曲，他在使用 dig 命令查询过后，然后再进行时间分析给我截图，难道不知道有缓存么？

@CloudXNS

域名

cloudxns

冷门

dnslookup

20 条回复 • 2015-12-14 19:20:44 +08:00

cismous

2015-12-14 10:00:34 +08:00

@CloudXNS 能给出有力的分析，排查一下问题吗

sobigfish

2015-12-14 10:11:58 +08:00 via iPhone

冷门是指 new gtld 么？怎么测试时间

xonze

2015-12-14 10:15:01 +08:00

所谓的冷门域名你是指的很少有 dns 解析请求的，在本地运营商 dns 上没有缓存的域名吧，这个时间应该取决于本地运营商 dns 到授权 dns 的请求时间，这个真是因地而异也同用户本地设置的 dns 服务器 ip 有关， CloudXNS 的授权服务器数量挺多，应该在大部分地区的响应都很快。
这样的测试可以借助一些类似 17 测这类型的第三方工具测试来看更靠谱些，我尝试了一些，很多冷域名在大部分区域都在 1ms 就能返回，甚至不到 1ms 的也有，当然也有超过 1000ms 的地区，当然了这些值也仅供参考，多尝试几个工具来测试对比下会比较客观

CloudXNS

2015-12-14 10:17:51 +08:00

@cismous
1 、并没看出楼主提出了什么需要排查的问题；
2 、妹纸并不懂技术，我得把您的问题和别人转达传递几遍才能回复；
3 、您还是把您的想法跟技术支持深入交流下，或许是大家相互理解的偏差也不一定；

感谢楼主对 CloudXNS 的信任和支持！

jasontse

2015-12-14 10:18:10 +08:00 via Android

你这个查法很逗啊，应该直接查 NS 免去递归过程才是 CloudXNS 的性能。

cismous

2015-12-14 10:23:46 +08:00

@jasontse 见笑了

@xonze 本人在杭州工作，单位使用的电信宽带，路由器设置的阿里云的 dns ，这种情况下，早上上班我访问多个自己的网站，浏览器审查工具 timing 显示的 dnslookup 时间都是在 2000ms 左右。这个时间真的好久。

oott123

2015-12-14 10:24:54 +08:00

域名都不贴……

cismous

2015-12-14 10:28:18 +08:00

刚开始我是觉得贴上域名意义不大，因为都已经有缓存了，现在我把 ttl 值改成了 60 ，会好一些 jiangzuoye.com

@oott123 请指教

cismous

2015-12-14 10:36:00 +08:00

@CloudXNS 需要排查的问题是速度为何这么慢，是因为本地的原因还是因为 CloudXns 方面的原因

oott123

2015-12-14 10:38:10 +08:00

我在我本地机器上执行了下 dig +trace ，结果有点长，我贴在了 https://paste.ee/p/UQRVX 。
从结果来看，你的域名解析并没有什么问题。
dig +trace 命令是从根服务器一路查询下来的（ SEE: http://superuser.com/questions/715632/how-does-dig-trace-actually-work ），中间没有递归服务器，也就不存在你说的缓存 / TTL 问题了。

cismous

2015-12-14 10:45:42 +08:00

@oott123 域名解析是没有问题，而我描述的问题，就是解析时间的问题

oott123

2015-12-14 10:46:59 +08:00

好吧，算我说错了，重来一遍：

我在我本地机器上执行了下 dig +trace ，结果有点长，我贴在了 https://paste.ee/p/UQRVX 。
从结果来看，你的域名解析时间并没有什么问题。
dig +trace 命令是从根服务器一路查询下来的（ SEE: http://superuser.com/questions/715632/how-does-dig-trace-actually-work ），中间没有递归服务器，也就不存在你说的缓存 / TTL 问题了。

oott123

2015-12-14 10:51:10 +08:00

喔，不过不得不说的是， CloudXNS 的权威服务器到你的递归服务器之间这段网络可能造成了延迟。不过相比起来，楼主的网络问题可能性更大……

datocp

2015-12-14 10:51:31 +08:00 via Android

需要排查的是为什么不在网关布暑 dnsmasq ，所有 dns 查询指向网关跟直接指向外部 dns 还是有速度差别的。以前干扰 8.8.8.8 时直接导致延迟很高甚至掉包，当然导致网页打开时常白页，强制所有 udp 53 dnat 通过网关查询，避免用第三方 dns,没错用第三方 dns 甚至没有查询结果，好多年了因为第三方 dns 遇到网络故障多了，习惯用电信 dns 已经不知道第三方 dns 的意义何在。

cismous

2015-12-14 10:59:04 +08:00

@oott123 对网络方面的知识了解只是皮毛，想找出真正的原因，谢谢啦
https://paste.ee/p/BRqAZ 这个是我的结果

jasontse

2015-12-14 11:21:53 +08:00 via iPad

@cismous
查根服务器和 gTLD 的速度好慢，国际网络太渣。

cismous

2015-12-14 11:43:15 +08:00

@jasontse
@oott123
@xonze
@CloudXNS

有关于 dns 介绍全面的资料或者书籍吗，请大家推荐一下，谢谢！

CloudXNS

2015-12-14 13:53:14 +08:00

@cismous
rfc1034
rfc1035
《 dns 与 bind 》

aa45942

2015-12-14 14:52:46 +08:00

我用 AWS 运行 dig +trace jiangzuoye.com 的查询结果

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.39.amzn1 <<>> +trace jiangzuoye.com
;; global options: +cmd
. 518400 IN NS I.ROOT-SERVERS.NET.
...
. 518400 IN NS H.ROOT-SERVERS.NET.
;; Received 228 bytes from 172.16.0.23#53(172.16.0.23) in 923 ms

com. 172800 IN NS a.gtld-servers.net.
...
com. 172800 IN NS m.gtld-servers.net.
;; Received 492 bytes from 199.7.83.42#53(199.7.83.42) in 2199 ms

jiangzuoye.com. 172800 IN NS lv3ns1.ffdns.net.
...
jiangzuoye.com. 172800 IN NS lv3ns4.ffdns.net.
;; Received 189 bytes from 192.31.80.30#53(192.31.80.30) in 866 ms

jiangzuoye.com. 60 IN A 121.43.192.113
jiangzuoye.com. 3600 IN NS lv3ns2.ffdns.net.
...
jiangzuoye.com. 3600 IN NS lv3ns3.ffdns.net.
;; Received 141 bytes from 54.94.216.67#53(54.94.216.67) in 272 ms

mytsing520

2015-12-14 19:20:44 +08:00

从根域名服务器下来要经过顶级域名服务器、域名服务器、域名解析结果，但是， dig 下来的话，根域名服务器、顶级域名服务器就是随机走了（走到欧洲什么的地方也是可能的）， dig 和本地缓存的结果是大相径庭的。