V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
cismous
V2EX  ›  DNS

冷门域名 dnslookup 时间

  •  
  •   cismous · 2015-12-14 09:53:47 +08:00 · 5698 次点击
    这是一个创建于 3249 天前的主题,其中的信息可能已经有所发展或是发生改变。
    在使用的 CloudXns 免费域名解析服务,托管了多个域名,由于目前用户量少,所以域名算是冷门域名。一般冷门域名的解析时间在 1000ms 至 2000ms 是可以理解的。但 CloudXns 技术客服给我答复的好像不一样,说他们家冷门域名解析只需要 300ms 多一点,这一点很赞。

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

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

    @CloudXNS
    20 条回复    2015-12-14 19:20:44 +08:00
    cismous
        1
    cismous  
    OP
       2015-12-14 10:00:34 +08:00
    @CloudXNS 能给出有力的分析,排查一下问题吗
    sobigfish
        2
    sobigfish  
       2015-12-14 10:11:58 +08:00 via iPhone
    冷门是指 new gtld 么? 怎么测试时间
    xonze
        3
    xonze  
       2015-12-14 10:15:01 +08:00   ❤️ 1
    所谓的冷门域名你是指的很少有 dns 解析请求的,在本地运营商 dns 上没有缓存的域名吧,这个时间应该取决于本地运营商 dns 到授权 dns 的请求时间,这个真是因地而异也同用户本地设置的 dns 服务器 ip 有关, CloudXNS 的授权服务器数量挺多,应该在大部分地区的响应都很快。
    这样的测试可以借助一些类似 17 测这类型的第三方工具测试来看更靠谱些,我尝试了一些,很多冷域名在大部分区域都在 1ms 就能返回,甚至不到 1ms 的也有,当然也有超过 1000ms 的地区,当然了这些值也仅供参考,多尝试几个工具来测试对比下会比较客观
    CloudXNS
        4
    CloudXNS  
       2015-12-14 10:17:51 +08:00
    @cismous
    1 、并没看出楼主提出了什么需要排查的问题;
    2 、妹纸并不懂技术,我得把您的问题和别人转达传递几遍才能回复;
    3 、您还是把您的想法跟技术支持深入交流下,或许是大家相互理解的偏差也不一定;

    感谢楼主对 CloudXNS 的信任和支持!
    jasontse
        5
    jasontse  
       2015-12-14 10:18:10 +08:00 via Android   ❤️ 1
    你这个查法很逗啊,应该直接查 NS 免去递归过程才是 CloudXNS 的性能。
    cismous
        6
    cismous  
    OP
       2015-12-14 10:23:46 +08:00
    @jasontse 见笑了

    @xonze 本人在杭州工作,单位使用的电信宽带,路由器设置的阿里云的 dns ,这种情况下,早上上班我访问多个自己的网站,浏览器审查工具 timing 显示的 dnslookup 时间都是在 2000ms 左右。这个时间真的好久。
    oott123
        7
    oott123  
       2015-12-14 10:24:54 +08:00
    域名都不贴……
    cismous
        8
    cismous  
    OP
       2015-12-14 10:28:18 +08:00
    刚开始我是觉得贴上域名意义不大,因为都已经有缓存了,现在我把 ttl 值改成了 60 ,会好一些 jiangzuoye.com

    @oott123 请指教
    cismous
        9
    cismous  
    OP
       2015-12-14 10:36:00 +08:00
    @CloudXNS 需要排查的问题是速度为何这么慢,是因为本地的原因还是因为 CloudXns 方面的原因
    oott123
        10
    oott123  
       2015-12-14 10:38:10 +08:00   ❤️ 1
    我在我本地机器上执行了下 dig +trace ,结果有点长,我贴在了 https://paste.ee/p/UQRVX
    从结果来看,你的域名解析并没有什么问题。
    dig +trace 命令是从根服务器一路查询下来的( SEE: http://superuser.com/questions/715632/how-does-dig-trace-actually-work ),中间没有递归服务器,也就不存在你说的缓存 / TTL 问题了。
    cismous
        11
    cismous  
    OP
       2015-12-14 10:45:42 +08:00
    @oott123 域名解析是没有问题,而我描述的问题,就是解析时间的问题
    oott123
        12
    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
        13
    oott123  
       2015-12-14 10:51:10 +08:00   ❤️ 1
    喔,不过不得不说的是, CloudXNS 的权威服务器到你的递归服务器之间这段网络可能造成了延迟。不过相比起来,楼主的网络问题可能性更大……
    datocp
        14
    datocp  
       2015-12-14 10:51:31 +08:00 via Android   ❤️ 1
    需要排查的是为什么不在网关布暑 dnsmasq ,所有 dns 查询指向网关跟直接指向外部 dns 还是有速度差别的。以前干扰 8.8.8.8 时直接导致延迟很高甚至掉包,当然导致网页打开时常白页,强制所有 udp 53 dnat 通过网关查询,避免用第三方 dns,没错用第三方 dns 甚至没有查询结果,好多年了因为第三方 dns 遇到网络故障多了,习惯用电信 dns 已经不知道第三方 dns 的意义何在。
    cismous
        15
    cismous  
    OP
       2015-12-14 10:59:04 +08:00
    @oott123 对网络方面的知识了解只是皮毛,想找出真正的原因,谢谢啦
    https://paste.ee/p/BRqAZ 这个是我的结果
    jasontse
        16
    jasontse  
       2015-12-14 11:21:53 +08:00 via iPad
    @cismous
    查根服务器和 gTLD 的速度好慢,国际网络太渣。
    cismous
        17
    cismous  
    OP
       2015-12-14 11:43:15 +08:00
    @jasontse
    @oott123
    @xonze
    @CloudXNS

    有关于 dns 介绍全面的资料或者书籍吗,请大家推荐一下,谢谢!
    CloudXNS
        18
    CloudXNS  
       2015-12-14 13:53:14 +08:00   ❤️ 1
    @cismous
    rfc1034
    rfc1035
    《 dns 与 bind 》
    aa45942
        19
    aa45942  
       2015-12-14 14:52:46 +08:00   ❤️ 1
    我用 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
        20
    mytsing520  
       2015-12-14 19:20:44 +08:00
    从根域名服务器下来要经过顶级域名服务器、域名服务器、域名解析结果,但是, dig 下来的话,根域名服务器、顶级域名服务器就是随机走了(走到欧洲什么的地方也是可能的), dig 和本地缓存的结果是大相径庭的。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1241 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 23:20 · PVG 07:20 · LAX 15:20 · JFK 18:20
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.