这是一个创建于 3149 天前的主题，其中的信息可能已经有所发展或是发生改变。
解析很准，延迟较低，而且不像 OpenDNS 一样劫持不存在页面，也不像 OneDNS 有各种烦人的强制功能，可以说是国内的 Google Public DNS 。
 |
1
xfspace 2015-09-15 12:49:50 +08:00 via Android
Alidns 呢
|
 |
2
FFLY 2015-09-15 12:58:18 +08:00
AliDNS 已经半死不活了吧……
官网那句“即将支持 edns-client-subnet 技术”已经一年有余了。 阿里不赚钱的产品也就那样了。某种意义上企鹅在不赚钱的产品上要厚道的多。 |
 |
4
vpncup 2015-09-15 13:08:14 +08:00 via iPhone
最好？我倒没觉出来。相比 google dns ，反而解析加载更慢了
|
 |
7
salmon5 2015-09-15 13:26:13 +08:00
|
 |
8
shoaly 2015-09-15 13:31:06 +08:00
我所有的 服务只要阿里云有的 都尽量阿里云了, 偏偏 dns 还是保留了 dnspod , 确实 dnspod 要专业很多
|
 |
10
yexm0 2015-09-15 13:58:01 +08:00 via Android
8.8.8.8 服务器在台湾，我用香港 vpsping 过去都有 30 多 40 的延迟， ping8.8.4.4 延迟倒是个位数。
|
 |
11
lqzhgood 2015-09-15 14:32:29 +08:00  1
@zi 嘎嘎~ 我移动之前也是 ping 8.8.8.8 各种好~ 好得出奇。 我还说移动怎么这么给力了。
转念一想… NMB 被劫持了~~ |
 |
12
wdlth 2015-09-15 14:38:07 +08:00
想起 DNSPod 以前的 zc0 事件……
|
 |
13
d7101120120 2015-09-15 14:51:11 +08:00
我的移动 ping8.8.8.8 丢包不忍直视， 8.8.4.4 延迟大约 30-40 ，目前在用。
|
 |
14
Havee 2015-09-15 14:54:57 +08:00
到你想注销 dnspod 账户的时候，就开始头疼了。
当初注册的时候以为一个邮箱账户就可以了，结果提示你绑 qq ，否则高级功能用不了，提示你帮手机否则高级功能用不了.....然后发现解绑不了，想注销，找不到注销入口，看协议是注销账户需要他们审核同意。 结果找到销售，人家直接说不支持注销，说明协议内容后，直接踢给技术。到技术工单提交 tickets ，发现必须要填写域名。死循环.... 直接电话吧，人家比公务员还牛，永远不通。 对于不支持注销，是否合法 对于 dnspod 这种隐晦提示，是否是恶意误导至账户捆绑，便于大数据收集？ 就售后来说，鹅厂系列的远远比不上阿里系列的。 跟阿里系较真，还能有结果，跟鹅厂较真，感觉对着空气出拳..... |
 |
15
leavic 2015-09-15 15:18:53 +08:00
dnspod>alidns>114
|
 |
16
GuangXiN 2015-09-15 15:20:59 +08:00
dnspod 好像被鹅厂收了
|
 |
17
DearTanker 2015-09-15 15:31:41 +08:00
等你用了 Namecheap 的 freedns 再说。。
|
 |
18
cattyhouse 2015-09-15 16:15:18 +08:00
感覺你們有點混亂，你們是在討論 Pubic DNS 服務（類似 8888 ， 8844 這樣的域名解析服務） ：
https://support.dnspod.cn/Kb/showarticle/tsid/241 還是在討論這個： https://www.dnspod.cn/Products/DNS |
 |
19
fetich 2015-09-15 18:06:37 +08:00
我这儿一用 119.29.29.29 ，立马断网。。。
|
 |
21
rushcheyo OP @cattyhouse 主要是 @Havee 捣乱。
|
 |
22
lovest 2015-09-15 20:41:21 +08:00
我也觉得移动用 119 最舒服了-起码不会乱跑。。其他的都有乱跑电信服务器的问题。
|
 |
23
thought 2015-09-16 00:23:45 +08:00
早就弃用，数据库总是被爆
|
 |
24
Marfal 2015-09-16 01:05:12 +08:00
我感觉还是运营商和 114 的最快最稳定， DNSPOD 的 Public DNS 用了几天会有一段时间解析不了的情况出现。
|
 |
26
Mast 2015-09-16 03:04:11 +08:00
国内最强的目前还是 114 ，虽然他坑爹。
|
 |
27
akw2312 2015-09-16 03:36:11 +08:00
@yexm0 8.8.8.8 天朝過去居然是跑到台灣彰濱機房而不是香港去？
請問一下你是甚麼 ISP...（我這邊深圳電信的機器過去還是跑到 HK 啊..） |------------------------------------------------------------------------------------------| | WinMTR statistics | | Host - % | Sent | Recv | Best | Avrg | Wrst | Last | |------------------------------------------------|------|------|------|------|------|------| | 192.168.1.1 - 0 | 2 | 2 | 0 | 0 | 0 | 0 | | h254.s98.ts.hinet.net - 0 | 2 | 2 | 8 | 9 | 10 | 10 | | pcpc-3302.hinet.net - 0 | 2 | 2 | 9 | 9 | 9 | 9 | | pcpc-3202.hinet.net - 0 | 2 | 2 | 8 | 9 | 10 | 10 | | TPE4-3202.hinet.net - 0 | 2 | 2 | 11 | 13 | 15 | 11 | | tyfo-3012.hinet.net - 0 | 2 | 2 | 10 | 11 | 12 | 12 | | 220.128.9.173 - 0 | 2 | 2 | 10 | 10 | 10 | 10 | | 74.125.49.158 - 0 | 2 | 2 | 9 | 10 | 11 | 9 | | 72.14.233.20 - 0 | 2 | 2 | 14 | 15 | 16 | 14 | | 209.85.251.19 - 0 | 2 | 2 | 15 | 16 | 17 | 15 | | 66.249.94.131 - 0 | 2 | 2 | 15 | 15 | 16 | 15 | | No response from host - 0 | 0 | 0 | 0 | 0 | 0 | 0 | | google-public-dns-a.google.com - 0 | 2 | 2 | 17 | 17 | 17 | 17 | |________________________________________________|______|______|______|______|______|______| WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider 另外我本地 google dns ping 還是略高了點...17ms 啊（ isp 的才 9~10ms |
 |
28
jessynt 2015-09-16 07:41:46 +08:00
正在 Ping 8.8.8.8 具有 32 字节的数据:
来自 8.8.8.8 的回复: 字节=32 时间=132ms TTL=45 来自 8.8.8.8 的回复: 字节=32 时间=130ms TTL=45 请求超时。 请求超时。 |
 |
29
ch3n2k 2015-09-16 08:24:10 +08:00 via iPhone
为什么不自建一个递归 DNS 服务器来解析呢？
|
 |
30
takashiki 2015-09-16 09:07:45 +08:00
我住的地方上海移动，用 dnspod 的会无法访问用百度云加速的站
|
|
31
Havee 2015-09-16 09:11:10 +08:00
|
 |
35
JonyOang 2015-09-16 09:38:11 +08:00
dnspod 比 114 慢多了，使用了一周后的体验
|
 |
37
openbaby 2015-09-16 10:03:21 +08:00
在用 onedns ，感觉 Onedns 访问一些国外网站速度比其他几个 dns 快不少。一些网站被墙掉 css 和 js 后变得面目全非，例如 https://www.virustotal.com http://www.isc.org 等，用 onedns 后能正常显示。
阿里的 dns 发现和国内 cdn 配合不好，一阵跳联通，一阵跳电信…… |
|
38
Havee 2015-09-16 10:09:12 +08:00
|
 |
41
hilarry 2015-09-16 10:18:27 +08:00
之前在用 DNSpod,目前在用 cloudxns ，感觉 cloudxns 弱爆了 线路比较多 节点比较多
|
 |
42
aruisi 2015-09-16 10:37:02 +08:00 1
@kttde 这个就有些错怪 onedns 了，现在的下载站，基本上前面两个下载链接都是假的，下载到的不是百度全家桶就是所谓的 xx 下载器，并不是真正的软件。举个栗子：从这个 pc6 下载站下载 Notepad 吧
http://www.pc6.com/softview/SoftView_43403.html#download 你注意看最前面两个下载链接分别是中国电信下载和中国联通下载（对应的链接是 http://down.xiazai2.net/?/43403/pc6/Notepad2.exe ），点击这两个链接后会被 onedns 拦截。 virustotal 在线分析结果 https://www.virustotal.com/zh-cn/url/8cd2e98d544803e9fb4d221f70df77fec3e9f68f77483901c7bc02db258d8da7/analysis/1442370617/和 https://www.virustotal.com/zh-cn/file/38e53c911df3cfdc8f5bbe0848188627fd8fb4502359f45fe4dd9b5afe96ec9d/analysis/1442349301/十多个杀毒软件报毒。 而真正的下载地址却是下面这些湖北电信下载、广东电信下载这些，其对应的链接是 http://5dx7.pc6.com/ee2/otepad2_x32.zip ，你看和上面的地址完全不同。这时 onedns 却并没有拦截。 同样的，你看 http://www.cr173.com/soft/22839.html 或者 http://www.crsky.com/soft/27230.html 都会发现这样一个现象。。。 |
 |
44
kawaii303 2015-09-16 11:10:23 +08:00
@zi 我家移动 ping 8.8.8.8 是 2ms ，是不是被劫持了，怎么这么快？ ping 8.8.4.4 却超时
|
 |
46
zi 2015-09-16 11:49:15 +08:00 2
@kawaii303 https://www.114dns.com/faq.html
问：如何判断 ISP 劫持而导致您无法使用 114DNS ？ 答：命令行输入 nslookup whether.114dns.com 114.114.114.114 ，如果返回的结果有 127.0.0.X ，说明您的 ISP 劫持了 114DNS ，导致您无法使用 114DNS 的服务。 -------------- 如果 114 都被劫持，那 8888 也逃不掉了，或者随便输入个不存在的域名，看会不会转跳到移动的导航 |
|
47
rushcheyo OP 还是被劫持了，唉。
|
 |
48
johnjiang85 2015-09-16 15:05:34 +08:00
@fetich 所有域名都无法解析，能问下哪个地区哪个运营商吗？我们排查下。
@a33004407 能问下哪个地区哪个运营商，有解析不了的大概时间段吗，或者 ping 域名有结果吗？ @takashiki 能给下百度云加速域名的 ping 结果， nslookup 或者 dig 结果吗，我们查下。 @hilarry 在授权 DNS 的功能上， DNSPod 的免费套餐现在是有点少，最近也已经调整了部分功能开放到免费用户(如国内、国外线路、所有的搜索引擎线路、记录导出功能等），您觉得还有哪些功能是比较需要的，我们可以讨论是否开放到免费用户。 有部分地区的运营商将用户量较大的 DNS IP ，如 8.8.8.8 和 114.114.114.114 的请求全部劫持到运营商递归 DNS 了（如天津联通等），甚至劫持了所有 udp53 请求路由到运营商 DNS （部分地区小运营商），所以会出现部分地区 8.8.8.8 的解析速度超快等现象。 解析速度问题，限于接入节点的部署情况，国内各家公共 DNS 在不同地区不同运营商的表现不同，大体上的规律是江浙 114 、阿里较快，北方百度较快，南方 DNSPod 较快。从全国三大运营商的平均速度来看排名是 DNSPod 、 114 、百度、 ali ，前三个都在 35-40ms ， ali 在 42ms 左右， DNSPod 最快，但是各家差距不大。但是百度的丢包率要略高于其他三家。 8.8.8.8 在国内即使计算运营商劫持的速度和成功率加成，全国三大运营商的平均延时约为 175ms （仅计算能访问 8.8.8.8 成功的节点），丢包率为 50.6%，当然部分地区用 Google Public DNS 质量还是可以的。 |
|
50
rushcheyo OP @johnjiang85 所以有无办法避免 ISP 对 DNS 的劫持？
|
|
51
johnjiang85 2015-09-16 18:25:20 +08:00
@rushcheyo 现在只能发现或有用户投诉的话会进行报障，通过线下商务手段尽量去推动解决。
|
 |
52
konakona 2015-09-16 18:29:53 +08:00
只要不出意外和线路问题， DNSPOD 确实很稳定，用了多年，信赖的小伙伴。
|
 |
53
zd423 2015-09-16 19:06:17 +08:00 via Android
聯通的網絡不行。。。。
|
|
54
zd423 2015-09-16 19:12:34 +08:00 via Android
@johnjiang85 我這裏 ping 的好慢，聯通的，福建這邊區域
|
 |
55
feicheche 2015-09-16 19:18:52 +08:00
被腾讯收了以后不如以前稳定了
|
|
56
fetich 2015-09-16 19:39:14 +08:00
@johnjiang85
是我租住的小区的路由器的锅，我猜的。刚搬进来那会儿， ping 网关都有六七百的延迟，甚至上千。后来貌似更换设备了，稳定在 1ms 左右，偶尔会出现几天连续断网的极端情况。。。这段时间用的是 114 。 DNSPod 推出 DNS 服务那几天，刚巧我租处网不稳定（断网），晚上插拔网线若干次后，人品爆发恢复了，换上 119.29.29.29 ，用了一会儿，感叹号出现了，插拔，又断网。。。若干次，实在是烦人。换上 223.5.5.5 后，稳定时间长点，但也出现过两次断网。 昨晚我又换上了 119.29.29.29 ，到目前为止没有断网，大概是是路由器每个月有那么几天。。。 |
|
57
takashiki 2015-09-16 20:54:45 +08:00
@johnjiang85 我这边现在也好了，具体原因不明
|
 |
60
xiaoc19 2015-09-17 08:50:45 +08:00 via iPad
@johnjiang85 没和 Google DNS 一样的隐私条款，是不是会记录所有记录，并和 QQ ，微信 uid 进行联动，一直有顾忌，问一下
|
 |
61
rekey 2015-09-17 11:05:22 +08:00
用了 dnspod public dns 以后，优酷看不了视频。。。
|
|
62
johnjiang85 2015-09-17 11:18:18 +08:00
@zd423 好的，我们看下福建联通的路由是不是有问题，目前国内有些省份的联通的路由因为联通架构的原因调度的不好。
@fetich @takashiki 好的，如果有问题欢迎随时联系我，如果能记录下一些故障时的 ping 、 dig 或 nslookup 的结果更好。 @xiaoc19 注册协议里是有相关条款的，建议可以详细看一下，简单说就是未来不排除和 qq 、微信进行联动的可能，毕竟是一家公司，当然目前为止还没有做过。 绑定 qq 号问题，只有用户需要使用一些后台由腾讯云或腾讯其他部门提供的附加功能时（如 CDN/CVM/风铃移动建站等）必须要绑定 QQ （因为这些服务都是以 qq 号为依托的)， 关注微信的话目前会推送一些用户在 DNSPod 业务登录、报警等信息，以及一些我们的文章。 DNSPod 对用户信息的保护是做的比较好的，即使是公司主管部门要求查看信息，没有法律依据和正规手续也是不会给他们看的，其他单位和公司就更不可能了，除非得到用户的授权（如之前的开启安全宝等）。 |
|
63
johnjiang85 2015-09-17 11:23:56 +08:00
@zd423 福建联通目前的调度情况是有 83.50%的访问会被调度到上海节点， 10.16%的访问被调度到深圳节点， 6.34%的访问会被调度到天津节点，可以麻烦提供下你那里到 119.29.29.29 的路由信息吗。 windows ： tracert 119.29.29.29
|
|
64
xiaoc19 2015-09-17 11:52:29 +08:00
@johnjiang85 你好，我说的是 Public DNS +，好像没有啥注册协议
|
|
65
johnjiang85 2015-09-17 15:08:04 +08:00
@xiaoc19 当成授权 DNS 了，访问日志记录按国家相关规定至少保留 6 个月，但不会对第三方进行透露。
数据挖掘这块刚上线现在还没有做，但是后期肯定是要做的，比如用户行为分析等，简单的例子就是 qq 空间的广告、广点通移动广告等都是有可能参考这些数据，这是包括 Google 都明确表明在做的。 我们会考虑加个隐私条款，明确我们可能会用这些日志来做什么，并保证不会透露给第三方（国家相关政策要求除外）。 PS1 ：不会额外推广告，而是用户访问的网站原本就有广告，但是可以通过用户行为分析使广告可以投放的更精准。 PS2 ：限于人力原因以及用户量原因，估计短期内（明年年底前）不会做。 |
|
66
johnjiang85 2015-09-17 15:14:25 +08:00
@rekey 能发下地区运营商和视频地址码，我们测试下。我们内部人员基本都是用的 119.29.29.29 ，是可以看优酷视频的。
|
|
67
xiaoc19 2015-09-17 16:11:29 +08:00
@johnjiang85 https://developers.google.com/speed/public-dns/privacy
google 的隐私策略，并不是会用来实现广告的“ Google Public DNS stores two sets of logs: temporary and permanent. The temporary logs store the full IP address of the machine you're using. We have to do this so that we can spot potentially bad things like DDoS attacks and so we can fix problems, such as particular domains not showing up for specific users. We delete these temporary logs within 24 to 48 hours. In the permanent logs, we don't keep personally identifiable information or IP information. We do keep some location information (at the city/metro level ) so that we can conduct debugging, analyze abuse phenomena. After keeping this data for two weeks, we randomly sample a small subset for permanent storage. We don't correlate or combine information from our temporary or permanent logs with any personal information that you have provided Google for other services. Finally, if you're interested in knowing what else we log when you use Google Public DNS, here is the full list of items that are included in our permanent logs: Request domain name, e.g. www.google.com Request type, e.g. A (which stands for IPv4 record ), AAAA (IPv6 record ), NS, MX, TXT, etc. Transport protocol on which the request arrived, i.e. TCP or UDP Client's AS (autonomous system or ISP ), e.g. AS15169 User's geolocation information: i.e. geocode, region ID, city ID, and metro code Response code sent, e.g. SUCCESS, SERVFAIL, NXDOMAIN, etc. Whether the request hit our frontend cache Whether the request hit a cache elsewhere in the system (but not in the frontend ) Absolute arrival time in seconds Total time taken to process the request end-to-end, in seconds Name of the Google machine that processed this request, e.g. machine101 Google target IP to which this request was addressed, e.g. one of our anycast IP addresses (no relation to the user's IP )” |
|
68
zd423 2015-09-17 23:18:21 +08:00 via Android
@johnjiang85 我現在用了 2 天，發現問題，有時候晚上 119.29.29.29 速度很快，有時候白天速度很快，晚上很卡解析 ms 上百，總之一句話，到底哪個才適合，沒穩定？會變化？上的好好的網，突然打開網頁就轉圈，要 19.29.29.29 卡的時候要換 182.254.116.116 ，又變可以了， ping 的時候總之速度是之前反轉過來的。我用的是手機上，路由器設置 dns
|
|
69
rekey 2015-09-18 10:04:35 +08:00
@johnjiang85 北京电信通。是全部优酷视频都不能看，切 114 可以看。
|
 |
70
vpnyihao 2015-09-18 10:50:53 +08:00
@johnjiang85 能否帮忙反映下，江西联通用户使用此 DNS ，竟然打不开好搜主页和华泰证券官网，其他任何 DNS （包括运营商的）都可以打开，无语啦……
|
|
71
johnjiang85 2015-09-18 11:51:46 +08:00
|
|
72
johnjiang85 2015-09-18 12:02:29 +08:00
@xiaoc19 貌似我记混了，重新过了一遍，确实说不会联动。 DNSPod 公共 DNS 不会也无法收集除了用户发过来的 DNS 查询以及应答信息以外的其他任何信息，也就是说获取不到用户的 qq 号或者微信号等相关个人数据。
google 提到和广告相关的就是不存在的域名不会重定向到广告页面(这个 DNSPod 也不会做)，其他没有提到广告等相关内容。 当然如果通过 qq/微信的日志与 Public DNS 的日志进行关联分析，还是可能得到 qq 号 /微信号这些信息的， DNSPod 短期内不会做这些数据挖掘的工作，但是我这里暂时无法承诺以后会不会进行联动。 |
|
73
xiaoc19 2015-09-18 17:47:55 +08:00
@johnjiang85 我说的就是类似日志分析这种，不过基于广电通等等这些业务，早晚应该是会有的，如果这个 DNS 用的人多的话，😄
|
|
74
zd423 2015-09-18 20:24:04 +08:00
@johnjiang85 怎么路由走江西的呢？福建联通走江西？我这里看到的是江西
C:\Users\Administrator>tracert 119.29.29.29 通过最多 30 个跃点跟踪到 119.29.29.29 的路由 1 1 ms 5 ms 6 ms PC201508141944 [192.168.167.1] 2 * * * 请求超时。 3 7 ms * 4 ms 13.135.35.171.adsl-pool.jx.chinaunicom.com [171. 35.135.13] 4 22 ms 4 ms 7 ms 14.135.35.171.adsl-pool.jx.chinaunicom.com [171. 35.135.14] 5 7 ms 6 ms 9 ms 17.135.35.171.adsl-pool.jx.chinaunicom.com [171. 35.135.17] 6 40 ms 27 ms 39 ms 5.135.35.171.adsl-pool.jx.chinaunicom.com [171.3 5.135.5] 7 21 ms 22 ms 22 ms 219.158.13.169 8 21 ms 26 ms 24 ms 219.158.99.146 9 55 ms * 37 ms 139.226.204.10 10 21 ms 20 ms 20 ms 139.226.194.222 11 39 ms 38 ms 36 ms 140.207.73.154 12 * * * 请求超时。 13 * * * 请求超时。 14 * * * 请求超时。 15 * * * 请求超时。 16 40 ms 46 ms 40 ms 119.29.29.29 跟踪完成。 C:\Users\Administrator>tracert 182.254.116.116 通过最多 30 个跃点跟踪到 182.254.116.116 的路由 1 1 ms 1 ms <1 毫秒 PC201508141944 [192.168.167.1] 2 * * * 请求超时。 3 86 ms 4 ms 5 ms 13.135.35.171.adsl-pool.jx.chinaunicom.com [171. 35.135.13] 4 5 ms 5 ms 8 ms 14.135.35.171.adsl-pool.jx.chinaunicom.com [171. 35.135.14] 5 47 ms 4 ms 4 ms 17.135.35.171.adsl-pool.jx.chinaunicom.com [171. 35.135.17] 6 24 ms 21 ms 23 ms 5.135.35.171.adsl-pool.jx.chinaunicom.com [171.3 5.135.5] 7 34 ms 36 ms 33 ms 219.158.17.185 8 59 ms 59 ms 62 ms 219.158.12.86 9 61 ms 55 ms * 112.64.243.58 10 56 ms 56 ms 56 ms 139.226.202.198 11 56 ms 54 ms 55 ms 140.207.73.158 12 * * * 请求超时。 13 * * * 请求超时。 14 * * * 请求超时。 15 * * * 请求超时。 16 56 ms 58 ms 55 ms 182.254.116.116 正在 Ping 182.254.116.116 具有 32 字节的数据: 来自 182.254.116.116 的回复: 字节=32 时间=120ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=55ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=105ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=57ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=57ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=60ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=55ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=56ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=106ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=57ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=55ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=56ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=55ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=55ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=55ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=55ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=58ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=55ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=75ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=55ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=61ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=56ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=59ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=56ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=61ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=55ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=55ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=55ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=55ms TTL=49 来自 182.254.116.116 的回复: 字节=32 时间=55ms TTL=49 正在 Ping 119.29.29.29 具有 32 字节的数据: 来自 119.29.29.29 的回复: 字节=32 时间=41ms TTL=49 来自 119.29.29.29 的回复: 字节=32 时间=40ms TTL=49 来自 119.29.29.29 的回复: 字节=32 时间=61ms TTL=49 来自 119.29.29.29 的回复: 字节=32 时间=40ms TTL=49 来自 119.29.29.29 的回复: 字节=32 时间=42ms TTL=49 来自 119.29.29.29 的回复: 字节=32 时间=40ms TTL=49 来自 119.29.29.29 的回复: 字节=32 时间=70ms TTL=49 来自 119.29.29.29 的回复: 字节=32 时间=133ms TTL=49 来自 119.29.29.29 的回复: 字节=32 时间=148ms TTL=49 来自 119.29.29.29 的回复: 字节=32 时间=40ms TTL=49 来自 119.29.29.29 的回复: 字节=32 时间=40ms TTL=49 来自 119.29.29.29 的回复: 字节=32 时间=42ms TTL=49 来自 119.29.29.29 的回复: 字节=32 时间=43ms TTL=49 来自 119.29.29.29 的回复: 字节=32 时间=56ms TTL=49 来自 119.29.29.29 的回复: 字节=32 时间=43ms TTL=49 来自 119.29.29.29 的回复: 字节=32 时间=40ms TTL=49 来自 119.29.29.29 的回复: 字节=32 时间=47ms TTL=49 来自 119.29.29.29 的回复: 字节=32 时间=41ms TTL=49 |
 |
75
lastczj 2015-09-24 19:42:09 +08:00
@johnjiang85 表示解析 360 安仔和 360 卫士个人中心出现问题， 114 和阿里都没问题。 DNSPOD 还是不给力啊！
|
 |
76
JAYDEN96 2015-09-26 11:50:51 +08:00
PublicDNS.cn - 全国 DNS 服务器 IP 地址汇总
|
|
77
johnjiang85 2015-09-28 14:57:50 +08:00
@lastczj 刚看到，这个问题当时有其他用户投诉 360 搜索解析很慢甚至有时候无法解析的时候，排查了该问题。具体原因如下。
1. 360 授权 DNS 的其中一个节点宕机 2. 360 授权 DNS 的一个 ns 地址只有一个 IP ，没有其他 IP ，目前 DNSPod 后端递归节点的重试机制是优先向同 NS 地址的其他 IP 进行同时发送查询请求重试。 3. DNSPod 公共 DNS 部分后端递归节点未同时向其他 NS 地址的 IP 发送 DNS 查询请求，当该 ns 地址的 IP 失败后才会向其他 NS 的 IP 进行重试。 4. DNSPod 公共 DNS 用户较少，且使用 360 的用户更少，导致后端递归节点在自我学习并排除异常授权 DNS 节点的速度较慢，时间较长。 5. DNSPod 公共 DNS 的缓存是按照用户 IP 缓存的，不会复用其他地区用户解析出的结果。 以上原因综合导致了部分地区解析 360 的域名有问题，在接到用户反馈后，经过人口多次请求该域名重复测试后，加速了后端递归节点通过自我学习排除掉了有问题的授权 DNS 节点，之后恢复正常。 |
|
78
lastczj 2015-09-28 19:22:24 +08:00
@johnjiang85 问题还没有解决啊，到底几时解决啊？谢谢
|
|
79
johnjiang85 2015-09-30 09:43:05 +08:00
@lastczj 能发下 dig/nslookup 和 ping 的测试结果吗，我们测试都是正常的。
|
|
80
lastczj 2015-09-30 19:30:23 +08:00
@johnjiang85 这个我真没办法知道 360 卫士的个人中心的地址，抓包我又不懂，反正我这里是广东那边的！
|
|
81
vpnyihao 2015-10-01 13:25:03 +08:00
@johnjiang85 我这里（江西联通）也是 360 的好搜死活打不开， nslookup 和 ping 都不通；换其他任何 DNS 都是秒开，虽然不常用，但也不能打不开啊。
http://www.haosou.com/ http://www.so.com/ |
|
82
johnjiang85 2015-10-08 17:54:52 +08:00
@vpnyihao 经过联合排查，部分地区无法解析 360 域名的原因已经定位，之后会进行修复。具体原因如下：
1. www.so.com 的解析记录是这样的 www.so.com CNAME so.qh-lb.com so.qh-lb.com A 140.207.202.254 2. www.so.com 的授权 NS 地址是 ns3/4/5/7/8.360safe.com ，该授权 NS 支持 google ecs 协议，可以对我们后端递归发出的带有 ecs 的查询包正常响应。 3. so.qh-lb.com 的授权 NS 地址是 ns2/3/5/6.qh-lb.com ，该授权 NS 不支持 google ecs 协议，对我们后端递归发出的带有 ecs 的查询包返回格式错误（符合 RFC 协议） 4. 我们自研的后端递归对 2,3 单独出现时都可以兼容，可以正常解析。但是当 2 和 3 同时混合出现时，我们的后端递归逻辑有点问题，再收到 format error 后再次重试还是带着用户的 IP 去向 360 的第二级授权请求，结果总是返回 format error ，最终解析超时。 5. 江西联通的递归节点失败后，路由回退到联通默认递归节点 /全网默认递归节点，我们所有的默认节点都是支持 ecs 的递归，同样有该 ecs 的问题，最终还是超时。 6. 部分地区可以解析的原因是我们的后端递归节点并非全部部署的支持 ecs 的自研递归，有部分与其他业务复用的节点使用的是不支持 ecs 的递归程序，可以正常解析。不支持 ecs 的递归只会处理该省份运营商的解析请求，没有递归节点的省份运营商的解析都是调度到邻近省份相同运营商且支持 ecs 的自研递归进行解析的。这里我们在江西联通，联通默认，全网默认的递归节点部署的都是支持 ecs 的递归，最终造成该问题。 7. 其他类似这样的域名也会遇到该问题。 解决方案： 1. 先在三大运营商默认线路各增加两台不支持 ecs 的递归节点，先解决部分地区部分域名无法解析的问题。 2. 我们已经对递归代码中自动探测授权 DNS 是否支持 ecs 的逻辑着手修改，修改验证完成后会灰度上线。 |
|
83
johnjiang85 2015-10-08 18:03:16 +08:00
@lastczj 看 82 楼回复
|
|
84
johnjiang85 2015-10-08 18:18:54 +08:00
 |
|
85
lastczj 2015-10-08 19:02:14 +08:00
@johnjiang85 看起来是解决了我的问题，现在可以正确解析到了。我再用一段时间，看看是否稳定。
|
|
86
lastczj 2015-10-08 19:48:32 +08:00
@johnjiang85 刚才是缓存还没有刷新，导致以为问题解决了。问题还没有解决。
|
|
87
lastczj 2015-10-09 03:06:46 +08:00
@johnjiang85 现在又好像可以了，唉啊，我还是观察一段时间再下定论吧，有问题再 @你。
|
|
88
johnjiang85 2015-10-09 09:48:39 +08:00
|
|
89
johnjiang85 2015-10-09 09:50:39 +08:00
|
|
90
johnjiang85 2015-10-09 11:40:21 +08:00
@lastczj 江西联通的两台节点已经灰度了一台，目前可以解析了，如果没有问题，下午会灰度另一台。
|
|
91
lastczj 2015-10-09 12:54:21 +08:00
@johnjiang85 我这边是广东电信的，希望也能及时得到解决。
|
|
92
johnjiang85 2015-10-09 13:55:40 +08:00
@lastczj 好的，我们把广东电信也提前，预计最晚明天。
|
|
93
johnjiang85 2015-10-09 18:05:17 +08:00
|
|
94
vpnyihao 2015-10-09 21:50:32 +08:00
@johnjiang85 现在 360 可以了
|
|
95
lastczj 2015-10-10 19:29:35 +08:00
@johnjiang85 可以了
|
 |
98
crazyfengs 2015-10-15 16:13:31 +08:00
@fetich 流氓的运营商干的好事。。 dns 是很好的，哎。
|
Select Language