冷门域名 dnslookup 时间

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

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

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

@CloudXNS
5707 次点击
所在节点    DNS
20 条回复
cismous
2015-12-14 10:00:34 +08:00
@CloudXNS 能给出有力的分析,排查一下问题吗
sobigfish
2015-12-14 10:11:58 +08:00
冷门是指 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
你这个查法很逗啊,应该直接查 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
需要排查的是为什么不在网关布暑 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
@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 和本地缓存的结果是大相径庭的。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/243345

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX