标签归档：dnspod

119.29.29.29Public DNS+ 常见问题

1. Public DNS+简介

Public DNS+是DNSPod推出的公共域名解析服务，服务IP为119.29.29.29，类似于其他公共DNS（如Google的8.8.8.8和114dns的114.114.114.114），可以为全网用户提供域名的公共递归解析服务（区别于DNSPod原有的域名授权解析服务）。

Public DNS+凭借DNSPod多年的域名解析服务经验开发，并依托于腾讯强大的资源优势，旨在为用户提供更加快速、准确、稳定的递归解析服务，且我们不会对任何域名进行恶意劫持。

a) 快速

DNSPod Public DNS+在深圳、上海、天津、香港和北美部署了接入集群，通过BGP Anycast技术，在国内与全国Top 16运营商（电信、联通、移动、教育网、长宽、天威、铁通、电信通、歌华有线、东方有线、杭州华数、方正宽带、广东盈通、中信网络、CNISP、陕西广电）进行了对等互联，并可以无缝扩展，无论用户处于何地都可以就近快速访问DNSPod的公共DNS，最快得到解析结果，提升网络访问体验。

DNSPod公共DNS服务端使用DPDK开发，万兆网络接入，高效的全缓存设计，确保对用户的解析请求作出快速的应答。

b) 准确

DNSPod Public DNS+是目前国内唯一支持谷歌ECS(edns-client-subnet)协议的公共DNS，并可以自动探测域名的授权DNS是否支持ECS协议，使国内用户不必再忍受Google Public DNS的延迟和丢包，一样可以享受到最精准的解析。

如果域名使用的授权DNS支持ECS协议(如DNSPod、万网等)，那么使用Public DNS+的用户无论访问的是我们的哪个接入节点、最终分配到了哪个后端递归节点，我们都可以给用户解析出最准确的结果，真正让用户能够体验到“a faster internet”。

同时我们在国内部署了大量后端递归节点，并在香港、美国和加拿大也部署了后端递归节点，总线路数达到了84条，国内节点和国际节点数都是国内公共DNS中最多的，并将尚未部署递归节点的省份运营商调度到邻近省份的同运营商节点进行解析，保证当域名的授权DNS不支持ECS协议时，使用Public DNS+也能解析到尽可能准确的结果。

c) 稳定

DNSPod Public DNS+使用同一个服务IP 119.29.29.29使用BGP Anycast接入，国内三地进行进群部署容灾，当某地网络出现故障时可以实现秒级自动故障切换到其他可用地区进行解析。

各地接入集群都由四层负载均衡技术的多台服务器组成，可以实时剔除故障服务器，并在服务器恢复后自动加入集群提供解析服务，排除服务器单点故障可能造成的解析服务中断。

DNSPod Public DNS+所有节点均部署了宙斯盾防护设备，宙斯盾防护设备经受过DNSPod无数次被攻击的考验，对DNS攻击防护率达到100%，可以有效保障公共DNS服务的稳定。

d) 安全、无劫持

DNSPod不会对Public DNS+的解析结果进行劫持，让用户远离各种DNS劫持的烦恼。

但在特殊情况下，为了保护我们的用户免受安全威胁，对于确定恶意域名(如病毒、木马、钓鱼网站等)的解析，我们可能会进行解析阻断，但不会对解析结果进行修改。

2. Why DNSPod Public DNS+？

DNSPod作为国内最大的第三方授权DNS服务商，在为大量域名提供授权DNS服务的过程中发现了越来越多的DNS解析问题，如已经依赖授权DNS作为互联网的基础设施，随着互联网规模的持续增长，现有的DNS系统也暴露出了越来越多的问题，如针对DNS的攻击愈演愈烈、运营商的Local DNS存在着大量的DNS劫持、NAT导致解析结果跨网、稳定性不高等，而DNSPod原有的授权DNS服务已经不能完美解决这些问题。

DNSPod在提供授权DNS服务的过程中，积累了大量的DNS解析相关技术和资源，只提供授权DNS服务不能为所有的用户提供更好的服务。

所以我们推出了DNSPod公共DNS：Public DNS+，希望为所有用户解决DNS解析问题，也希望用户对我们的服务进行反馈，以便于我们对产品持续进行改进。

3. 什么用户可以使用Public DNS+？

Public DNS+是DNSPod提供的公共递归DNS服务，只要能够修改DNS配置的用户都可以使用，具体参考接入指南。

4. DNSPod Public DNS+的架构是怎么样的？

DNSPod

Public DNS+在国内三地部署了一级缓存DNS集群节点，每个几点都由多台万兆服务器组成四层负载均衡，统一使用同一个服务IP 119.29.29.29，通过BGP Anycast与全国TOP16的运营商进行对等互联，保证用户接入最近的节点。一级缓存负责接收和应答用户的DNS查询请求，并对未命中缓存的域名转发到二级缓存进行查询。

二级缓存的主要作用是接收一级缓存转发过来的DNS查询请求，并根据用户IP将该请求转发至对应的后端递归节点，接受递归节点的DNS应答返回到一级缓存；二是为多台一级缓存服务器提供缓存服务，减轻后端递归节点的压力，并提升应答速度。

后端递归节点部署在各个省份运营商线路内，当域名的授权DNS支持ECS协议时，可以提供更准确的解析，未部署递归节点的省份运营商会将域名解析请求优先调度到相邻省份相同运营商进行解析。

一级缓存、二级缓存和递归DNS都为自研高性能解析程序，并支持ECS协议，保证用户可以获得快速、准确、稳定的DNS解析服务。

5. Public DNS+的节点是如何分布的？

DNSPod Public DNS+的后端递归节点共有84条线路，覆盖国内主流省份运营商以及部分国外线路。

当Public DNS+接收到用户的DNS请求后，会判断用户所属线路，然后将该查询转发到该线路对应的后端递归节点（如果该省份运营商没有节点时会将请求转发到邻近省份相同运营商的节点），当该次请求失败时，会按照运营商默认线路、国内(或国外)默认线路的顺序依次进行查询转发，直至解析出结果。域名解析结果会按照用户的IP信息进行缓存。

线路具体分布如下所示。

国内线路，80条：

电信线路22条，如下所示：

上海电信

云南电信

北京电信

四川电信

天津电信

安徽电信

山东电信

广东电信

广西电信

江苏电信

江西电信

河南电信

浙江电信

海南电信

湖北电信

湖南电信

甘肃电信

福建电信

重庆电信

陕西电信

黑龙江电信

电信默认线路

联通线路18条，如下所示：

上海联通

北京联通

吉林联通

四川联通

天津联通

山东联通

山西联通

广东联通

江苏联通

河北联通

河南联通

浙江联通

湖南联通

辽宁联通

重庆联通

陕西联通

黑龙江联通

联通默认线路

移动线路25条，如下所示：

上海移动

云南移动

北京移动

吉林移动

四川移动

天津移动

安徽移动

山东移动

山西移动

广东移动

广西移动

新疆移动

江苏移动

江西移动

河北移动

河南移动

浙江移动

湖北移动

湖南移动

福建移动

西藏移动

重庆移动

陕西移动

黑龙江移动

移动默认线路

铁通线路3条，如下所示：

上海铁通

湖北铁通

铁通默认线路

教育网线路4条，如下所示：

上海教育网

浙江教育网

湖北教育网

教育网默认线路

长宽线路4条，如下所示

上海长宽

广东长宽

湖北长宽

长宽默认线路

杭州华数线路2条，如下所示：

浙江

华数默认线路

天威节点1条，为默认节点。

国内全局默认节点1条。

国外线路4条,如下所示：

香港

美国

加拿大

国外默认线路

Comodo Secure DNS（科莫多提供） 8.26.56.26/8.20.247.20，对比114dns、dnspod、阿里DNS

Comodo Secure DNS（科莫多提供） 8.26.56.26/8.20.247.20 查询速度非常快，一点也不输给dnspod的119.29.29.29 114DNS：114.114.114.114 阿里DNS：223.5.5.5

测试一下查询速度，Comodo Secure DNS（科莫多提供） 8.26.56.26/8.20.247.20基本在1毫秒到900毫秒，波动很大，但是定位不够准确，广东电信使用了

# time dig @8.26.56.26 www.weibo.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @8.26.56.26 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16697
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.weibo.com. IN A

;; ANSWER SECTION:
www.weibo.com. 31 IN A 180.149.134.141
www.weibo.com. 31 IN A 180.149.134.142

;; Query time: 1 msec
;; SERVER: 8.26.56.26#53(8.26.56.26)
;; WHEN: Tue Jul 18 17:56:07 2017
;; MSG SIZE rcvd: 63

real 0m0.006s
user 0m0.002s
sys 0m0.002s

# time dig @8.20.247.20 www.weibo.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @8.20.247.20 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4081
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.weibo.com. IN A

;; ANSWER SECTION:
www.weibo.com. 37 IN A 180.149.134.142
www.weibo.com. 37 IN A 180.149.134.141

;; Query time: 2 msec
;; SERVER: 8.20.247.20#53(8.20.247.20)
;; WHEN: Tue Jul 18 17:56:42 2017
;; MSG SIZE rcvd: 63

real 0m0.006s
user 0m0.000s
sys 0m0.004s

# time dig @8.20.247.20 v.qq.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @8.20.247.20 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12273
;; flags: qr rd ra; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;v.qq.com. IN A

;; ANSWER SECTION:
v.qq.com. 527 IN CNAME v.tc.qq.com.
v.tc.qq.com. 1072 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 211 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 128 IN A 58.216.96.21
p21.tcdn.qq.com. 128 IN A 61.155.220.194
p21.tcdn.qq.com. 128 IN A 58.216.96.19
p21.tcdn.qq.com. 128 IN A 58.216.96.18
p21.tcdn.qq.com. 128 IN A 58.216.6.22
p21.tcdn.qq.com. 128 IN A 58.216.96.17
p21.tcdn.qq.com. 128 IN A 221.228.67.166
p21.tcdn.qq.com. 128 IN A 58.216.96.22
p21.tcdn.qq.com. 128 IN A 221.228.67.167
p21.tcdn.qq.com. 128 IN A 221.228.67.146
p21.tcdn.qq.com. 128 IN A 58.216.96.20
p21.tcdn.qq.com. 128 IN A 58.216.6.21
p21.tcdn.qq.com. 128 IN A 58.216.6.20
p21.tcdn.qq.com. 128 IN A 221.228.67.165

;; Query time: 3 msec
;; SERVER: 8.20.247.20#53(8.20.247.20)
;; WHEN: Tue Jul 18 17:58:29 2017
;; MSG SIZE rcvd: 331

real 0m0.007s
user 0m0.002s
sys 0m0.003s

# time dig @8.26.56.26 v.qq.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @8.26.56.26 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2198
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;v.qq.com. IN A

;; ANSWER SECTION:
v.qq.com. 132 IN CNAME v.tc.qq.com.
v.tc.qq.com. 1290 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 439 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 124 IN A 203.205.158.37
p21.tcdn.qq.com. 124 IN A 203.205.158.38

;; Query time: 289 msec
;; SERVER: 8.26.56.26#53(8.26.56.26)
;; WHEN: Tue Jul 18 18:13:52 2017
;; MSG SIZE rcvd: 116

real 0m0.294s
user 0m0.003s
sys 0m0.001s
[root@2 monitor_video]# time dig @8.26.56.26 v.qq.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @8.26.56.26 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1656
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;v.qq.com. IN A

;; ANSWER SECTION:
v.qq.com. 127 IN CNAME v.tc.qq.com.
v.tc.qq.com. 2027 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 434 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 6 IN A 203.205.158.37
p21.tcdn.qq.com. 6 IN A 203.205.158.38

;; Query time: 992 msec
;; SERVER: 8.26.56.26#53(8.26.56.26)
;; WHEN: Tue Jul 18 18:13:57 2017
;; MSG SIZE rcvd: 116

real 0m2.997s
user 0m0.001s
sys 0m0.003s

看看dnspod dns、也就是腾讯DNS，119.29.29.29，定位很准确，返回广东电信ip，查询速度稳定在10几毫秒

# time dig @119.29.29.29 v.qq.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @119.29.29.29 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9766
;; flags: qr rd ra; QUERY: 1, ANSWER: 19, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;v.qq.com. IN A

;; ANSWER SECTION:
v.qq.com. 296 IN CNAME v.tc.qq.com.
v.tc.qq.com. 2309 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 296 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 54 IN A 125.94.49.21
p21.tcdn.qq.com. 54 IN A 119.147.33.30
p21.tcdn.qq.com. 54 IN A 119.147.253.19
p21.tcdn.qq.com. 54 IN A 119.147.33.28
p21.tcdn.qq.com. 54 IN A 119.147.253.28
p21.tcdn.qq.com. 54 IN A 119.147.33.29
p21.tcdn.qq.com. 54 IN A 113.105.73.147
p21.tcdn.qq.com. 54 IN A 119.147.227.20
p21.tcdn.qq.com. 54 IN A 119.147.227.22
p21.tcdn.qq.com. 54 IN A 125.94.49.22
p21.tcdn.qq.com. 54 IN A 125.94.49.18
p21.tcdn.qq.com. 54 IN A 113.107.238.105
p21.tcdn.qq.com. 54 IN A 119.147.33.32
p21.tcdn.qq.com. 54 IN A 119.147.227.21
p21.tcdn.qq.com. 54 IN A 119.147.227.18
p21.tcdn.qq.com. 54 IN A 119.147.227.19

;; Query time: 14 msec
;; SERVER: 119.29.29.29#53(119.29.29.29)
;; WHEN: Tue Jul 18 17:59:58 2017
;; MSG SIZE rcvd: 340

real 0m0.018s
user 0m0.001s
sys 0m0.004s
[root@2 monitor_video]# time dig @119.29.29.29 www.weibo.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @119.29.29.29 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32098
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.weibo.com. IN A

;; ANSWER SECTION:
www.weibo.com. 35 IN A 180.149.134.142
www.weibo.com. 35 IN A 180.149.134.141

;; Query time: 12 msec
;; SERVER: 119.29.29.29#53(119.29.29.29)
;; WHEN: Tue Jul 18 18:00:05 2017
;; MSG SIZE rcvd: 63

real 0m0.016s
user 0m0.000s

看看最早的114DNS，114.114.114.114，返回IP为江苏电信IP不够准确，查询时间也非常快1-2毫秒。

# time dig @114.114.114.114 v.qq.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @114.114.114.114 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8929
;; flags: qr rd ra; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;v.qq.com. IN A

;; ANSWER SECTION:
v.qq.com. 238 IN CNAME v.tc.qq.com.
v.tc.qq.com. 349 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 322 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 32 IN A 58.216.6.20
p21.tcdn.qq.com. 32 IN A 58.216.96.19
p21.tcdn.qq.com. 32 IN A 58.216.96.21
p21.tcdn.qq.com. 32 IN A 221.228.67.165
p21.tcdn.qq.com. 32 IN A 58.216.96.18
p21.tcdn.qq.com. 32 IN A 58.216.96.22
p21.tcdn.qq.com. 32 IN A 61.155.220.194
p21.tcdn.qq.com. 32 IN A 58.216.96.17
p21.tcdn.qq.com. 32 IN A 221.228.67.167
p21.tcdn.qq.com. 32 IN A 58.216.6.22
p21.tcdn.qq.com. 32 IN A 58.216.6.21
p21.tcdn.qq.com. 32 IN A 221.228.67.166
p21.tcdn.qq.com. 32 IN A 221.228.67.146
p21.tcdn.qq.com. 32 IN A 58.216.96.20

;; Query time: 2 msec
;; SERVER: 114.114.114.114#53(114.114.114.114)
;; WHEN: Tue Jul 18 18:01:40 2017
;; MSG SIZE rcvd: 331

real 0m0.006s
user 0m0.004s
sys 0m0.000s
[root@2 monitor_video]# time dig @114.114.114.114 www.weibo.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @114.114.114.114 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13642
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.weibo.com. IN A

;; ANSWER SECTION:
www.weibo.com. 15 IN A 180.149.134.142
www.weibo.com. 15 IN A 180.149.134.141

;; Query time: 1 msec
;; SERVER: 114.114.114.114#53(114.114.114.114)
;; WHEN: Tue Jul 18 18:01:47 2017
;; MSG SIZE rcvd: 63

real 0m0.006s
user 0m0.002s
sys 0m0.002s

最后我们看看阿里DNS，223.5.5.5 223.6.6.6，首先返回ip有时候是湖南电信有时候是江苏电信，不够准确。查询速度10几毫秒，跟腾讯DNS（DNSPod）差不多。

# time dig @223.5.5.5 www.weibo.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @223.5.5.5 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31354
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.weibo.com. IN A

;; ANSWER SECTION:
www.weibo.com. 40 IN A 180.149.134.142
www.weibo.com. 40 IN A 180.149.134.141

;; Query time: 13 msec
;; SERVER: 223.5.5.5#53(223.5.5.5)
;; WHEN: Tue Jul 18 18:03:01 2017
;; MSG SIZE rcvd: 63

real 0m0.018s
user 0m0.004s
sys 0m0.001s
[root@2 monitor_video]# time dig @223.5.5.5 v.qq.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @223.5.5.5 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5022
;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;v.qq.com. IN A

;; ANSWER SECTION:
v.qq.com. 168 IN CNAME v.tc.qq.com.
v.tc.qq.com. 168 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 168 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 168 IN A 218.75.176.141
p21.tcdn.qq.com. 168 IN A 218.75.176.143
p21.tcdn.qq.com. 168 IN A 218.75.176.144
p21.tcdn.qq.com. 168 IN A 218.75.177.23
p21.tcdn.qq.com. 168 IN A 218.75.177.25
p21.tcdn.qq.com. 168 IN A 218.75.177.24
p21.tcdn.qq.com. 168 IN A 218.75.176.142

;; Query time: 6 msec
;; SERVER: 223.5.5.5#53(223.5.5.5)
;; WHEN: Tue Jul 18 18:03:05 2017
;; MSG SIZE rcvd: 196

real 0m0.010s
user 0m0.000s
sys 0m0.004s

小结：dnspod dns（腾讯DNS）119.29.29.29，查询定位很准确返回广东电信ip，查询速度稳定在10几毫秒，阿里dns、114dns都很快但是返回ip不是本省ip，可能是递归查询的ip节点不够多导致不准确。而Comodo Secure DNS（科莫多提供） 8.26.56.26/8.20.247.20 查询速度有时候最快，但是不稳定有时候几百毫秒，返回ip也不够精准同运营商不同省份，还是不稳定，不推荐。

2017公共DNS服务质量评测报告

DNS在平时上网中扮演重要角色，如果不注意的话，可能会导致网速慢、弹窗广告、网址打不开、打开不是自己想要的网站、劫持、墙中墙等一系列问题。针对DNS的问题，今天我们就来总结一下，看看哪个DNS服务器最好用！

注意：本测试仅通过奇云测对服务器进行综合测试，具体使用情况请以用户本地为主。

DNSPod：★★★★★

DNSPod是目前国内第一家支持ECS的公共DNS，可为全网用户提供域名的公共递归解析服务！

DNS 服务器 IP 地址：

首选：119.29.29.29

备选：182.254.116.116

作者点评：查询11毫秒，测试显示Public DNS+国内数据均比114DNS好，强力推荐！

# dig @119.29.29.29 www.weibo.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @119.29.29.29 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25013
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.weibo.com. IN A

;; ANSWER SECTION:
www.weibo.com. 53 IN A 180.149.134.142
www.weibo.com. 53 IN A 180.149.134.141

;; Query time: 11 msec
;; SERVER: 119.29.29.29#53(119.29.29.29)
;; WHEN: Tue Jul 18 17:29:30 2017
;; MSG SIZE rcvd: 63

114DNS：★★★★

国内用户量巨大的DNS，访问速度快，各省都有节点，可同时满足各运营商用户，有效预防劫持。

DNS 服务器 IP 地址：

首选：114.114.114.114

备选：114.114.114.115

作者点评：15毫秒查询反应，虽然测试结果比不上Public DNS+，但是也是非常不错的DNS

# dig @114.114.114.114 www.weibo.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @114.114.114.114 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49841
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.weibo.com. IN A

;; ANSWER SECTION:
www.weibo.com. 30 IN A 180.149.134.142
www.weibo.com. 30 IN A 180.149.134.141

;; Query time: 15 msec
;; SERVER: 114.114.114.114#53(114.114.114.114)
;; WHEN: Tue Jul 18 17:25:31 2017
;; MSG SIZE rcvd: 63

阿里 AliDNS：★★★★

阿里公共DNS是阿里巴巴集团推出的DNS递归解析系统，面向用户提供快速、稳定、智能的免费DNS递归解析服务。

DNS 服务器 IP 地址：

首选：223.5.5.5

备选：223.6.6.6

作者点评：查询12毫秒，排名第三的DNS也不是吹的，只是节点貌似有点少。

# dig @223.5.5.5 www.weibo.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @223.5.5.5 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25617
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.weibo.com. IN A

;; ANSWER SECTION:
www.weibo.com. 15 IN A 180.149.134.141
www.weibo.com. 15 IN A 180.149.134.142

;; Query time: 12 msec
;; SERVER: 223.5.5.5#53(223.5.5.5)
;; WHEN: Tue Jul 18 17:26:12 2017
;; MSG SIZE rcvd: 63

★★★

DNS派是聚流旗下的DNS服务，为个人用户、企业提供各种DNS服务，包括域名解析服务、网站授权解析服务、域名解析服务等

DNS 服务器 IP 地址：

首选（电信/移动/铁通）：101.226.4.6

备选（电信/移动/铁通）：218.30.118.6

首选（联通）：123.125.81.6

备选（联通）：140.207.198.6

作者点评：360出品！测试结果还不错，但是速度需要32毫秒。

# dig @101.226.4.6 www.weibo.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @101.226.4.6 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28341
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.weibo.com. IN A

;; ANSWER SECTION:
www.weibo.com. 60 IN A 180.149.134.141
www.weibo.com. 60 IN A 180.149.134.142

;; Query time: 32 msec
;; SERVER: 101.226.4.6#53(101.226.4.6)
;; WHEN: Tue Jul 18 17:26:36 2017
;; MSG SIZE rcvd: 63

：★★★

百度旗下云解析服务，依托百度一流基础设施和强大技术实力,为用户提供免费的、超越竞品的服务体验。没有套餐区分,安全,稳定,高效

DNS 服务器 IP 地址：

首选：180.76.76.76

作者点评：暂时不知道百度有多少节点。不过应该也不少吧，但是查询速度也要37毫秒。

# dig @180.76.76.76 www.weibo.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @180.76.76.76 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27682
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.weibo.com. IN A

;; ANSWER SECTION:
www.weibo.com. 23 IN A 180.149.134.142
www.weibo.com. 23 IN A 180.149.134.141

;; Query time: 37 msec
;; SERVER: 180.76.76.76#53(180.76.76.76)
;; WHEN: Tue Jul 18 17:32:29 2017
;; MSG SIZE rcvd: 63

CNNIC SDNS：★★★

SDNS是由中国互联网络信息中心(CNNIC)推出的免费解析服务(SecureDNS,简称SDNS)。

DNS 服务器 IP 地址：

首选：1.2.4.8

备选：210.2.4.8

作者点评：作为国家出品的DNS，有待测试……（你敢用吗？反正我不敢）查询速度38毫秒，返回内容太多了，注定也慢。

# dig @1.2.4.8 www.weibo.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @1.2.4.8 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12314
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 6

;; QUESTION SECTION:
;www.weibo.com. IN A

;; ANSWER SECTION:
www.weibo.com. 48 IN A 180.149.134.141
www.weibo.com. 48 IN A 180.149.134.142

;; AUTHORITY SECTION:
weibo.com. 77931 IN NS ns4.sina.com.cn.
weibo.com. 77931 IN NS ns1.sina.com.cn.
weibo.com. 77931 IN NS ns3.sina.com.cn.
weibo.com. 77931 IN NS ns2.sina.com.cn.
weibo.com. 77931 IN NS ns3.sina.com.
weibo.com. 77931 IN NS ns4.sina.com.

;; ADDITIONAL SECTION:
ns1.sina.com.cn. 73312 IN A 202.106.184.166
ns2.sina.com.cn. 66852 IN A 61.172.201.254
ns3.sina.com. 82970 IN A 61.172.201.254
ns3.sina.com.cn. 82970 IN A 123.125.29.99
ns4.sina.com. 73000 IN A 123.125.29.99
ns4.sina.com.cn. 80179 IN A 121.14.1.22

;; Query time: 38 msec
;; SERVER: 1.2.4.8#53(1.2.4.8)
;; WHEN: Tue Jul 18 17:27:38 2017
;; MSG SIZE rcvd: 283

OpenDNS：★★

OpenDNS创建于2006年，长期以来致力于为广大个人用户以及商务企业用户和公共领域提供免费的域名解析服务。

DNS 服务器 IP 地址：

首选：208.67.222.222

备选：208.67.220.220

作者点评：国内节点少，延迟高，解析结果受GFW的影响不一定准确，66毫秒，跟国内比查了几倍速度了。

# dig @208.67.222.222 www.weibo.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @208.67.222.222 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39469
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.weibo.com. IN A

;; ANSWER SECTION:
www.weibo.com. 21 IN A 123.125.104.197

;; Query time: 66 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Tue Jul 18 17:28:07 2017
;; MSG SIZE rcvd: 47

Google DNS：★★

谷歌公共域名解析服务（Google Public DNS）是由谷歌于2009年发布的一项DNS服务

DNS 服务器 IP 地址：

首选：8.8.8.8

备选：8.8.4.4

作者点评：国内无节点，延迟高，解析结果受GFW的影响不一定准确，300毫秒，直接放弃使用吧。

# dig @8.8.8.8 www.weibo.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> @8.8.8.8 www.weibo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14390
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.weibo.com. IN A

;; ANSWER SECTION:
www.weibo.com. 32 IN A 180.149.134.142
www.weibo.com. 32 IN A 180.149.134.141

;; Query time: 300 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Jul 18 17:28:37 2017
;; MSG SIZE rcvd: 63

最后总结

测试结果受用户地区和DNS提供商的服务器等不同因素影响。建议用户在选择DNS时可以依照本排行，ping不同dns服务商的首选DNS地址，一般是哪个延迟最低用哪个。不同地区我也不好发言。建议不要使用运营商默认的DNS！推荐DNSPodDNS:119.29.29.29/182.254.116.116，114DNS:114.114.114.114/114.114.114.115，阿里DNS：223.5.5.5/223.6.6.6

App域名劫持之DNS高可用 – 开源版HttpDNS方案详解

本文根据冯磊和赵星宇在“高可用架构”微信群所做的HttpDNS智能缓存库原理整理而成，转发请注明来自微信公众号ArchNotes。

冯磊，目前主要从事手机应用平台的构建，任职新浪网技术中国研发中心技术保障部架构师。5+年互联网，移动终端，游戏从业经验。历任软件工程师，高级软件工程师，技术经理。

赵星宇，HttpDNS的合作者。目前就职于新浪微博，从事手机微博的基础架构开发，任android高级研发工程师职位。

HttpDNS是使用HTTP协议向DNS服务器的80端口进行请求，代替传统的DNS协议向DNS服务器的53端口进行请求,绕开了运营商的Local
DNS，从而避免了使用运营商Local DNS造成的劫持和跨网问题。
(具体httpdns是什么？详细阅读见（【鹅厂网事】全局精确流量调度新思路-HttpDNS服务详解）：http://mp.weixin.qq.com/s?__biz=MzA3ODgyNzcwMw==&mid=201837080&idx=1&sn=b2a152b84df1c7dbd294ea66037cf262&scene=2&from=timeline&isappinstalled=0&utm_source=tuicool)

鹅厂往事中提到

那么对于腾讯这样的域名数量在10万级别的互联网公司来讲，域名解析异常的情况到底有多严重呢？每天腾讯的分布式域名解析监测系统在不停地对全国所有的重点LocalDNS进行探测，腾讯域名在全国各地的日解析异常量是已经超过了80万条。这给腾讯的业务带来了巨大的损失。为此腾讯建立了专业的团队与各个运营商进行了深度沟通，但是由于各种原因，处理效率及效果均不能达到腾讯各业务部门的需求。除了和运营商进行沟通，有没有一种技术上的方案，能从根源上解决域名解析异常及用户访问跨网的问题呢？

HttpDNS主要解决三类问题：

LocalDNS劫持
平均访问延迟下降
用户连接失败率下降

LocalDNS劫持:
由于HttpDNS是通过ip直接请求http获取服务器A记录地址，不存在向本地运营商询问domain解析过程，所以从根本避免了劫持问题。
（对于http内容tcp/ip层劫持，可以使用验证因子或者数据加密等方式来保证传输数据的可信度）

平均访问延迟下降: 由于是ip直接访问省掉了一次domain解析过程，（即使系统有缓存速度也会稍快一些‘毫秒级’）通过智能算法排序后找到最快节点进行访问。

用户连接失败率下降:
通过算法降低以往失败率过高的服务器排序，通过时间近期访问过的数据提高服务器排序，通过历史访问成功记录提高服务器排序。如果ip(a)访问错误，在下一次返回ip(b)或者ip(c)
排序后的记录。（LocalDNS很可能在一个ttl时间内（或多个ttl）都是返回记录

HttpDNSLib库组成

HttpDNSLib库主要由三个模块组成，查询模块，缓存模块，评估模块。

查询模块：

检查本地是否有对应的 domain 缓存
如果没有则从本地LocalDNS获取然后从httpdns更新domain记录
有数据则检测是否过期已过期则更新记录返回 LocalDNS 记录，未过期则直接返回缓存层数据。
从HttpDNS 接口查询本次app开启后使用过的domain 记录定时访问，更新内存缓存，数据库缓存等记录

数据模块：

根据SP（或Wifi名）缓存域名信息
更具SP（或Wifi名）缓存服务器ip信息、优先级
记录服务器ip每次请求成功数、错误数
记录服务器ip最后成功访问时间、最后测速
添加内存 -》数据库之间的缓存层

评估模块：

根据本地数据，对一组IP排序
处理用户反馈回来的请求明细，入库
针对用户反馈是失败请求，进行分析上报预警
给HttpDns服务端智能分配A记录提供数据依据

HttpDNS交互流程

HttpDNS交互流程图：

从这张图中可以看出来
整个业务的交互流程，用户向查询模块传入一个URL地址，然后查询模块会检查缓存是否存在，不存在从httpdnsapi接口查询，
然后经过评估模块返回。在用户请求URL过程完毕时，需要将这次请求的结果反馈给 lib库的评估模块由评估模块入库记录本次质量数据。

HttpDns Lib库交互流程：

这张图就更深入的说了下 lib的工作原理。有两条竖线讲图片分为了三个区域，分别是左部分、中间部分和右部分。

左部分是app主线程操作的事情，中间部分是app调用者线程中处理lib库事件逻辑的事情，右面部分是新线程独立处理事件的逻辑。

开始是里客户端调用方，传入一个
url，获取domain信息后由查询模块查询domain记录，查询模块会从内存缓存层查询，内存缓存层没有数据会，查询数据库，如果数据库也没有数据会请求本地
LocalDNS。从三个环节中任何一个环节拿到数据后，
都会进入下一个环节，如果没有拿到数据返回null结束。进入评估模块，根据五个插件进行排序，排序后返回数据给客户端。

lib模块设定定时器，根据ttl过期时间来检查domain是否需要更新。定时器是独立线程，不会影响app主线程。 httpdns
api请求数据，先从自己配置的 httpdns api接口获取数据，如果获取不到会从 dnspod api接口获取如果也获取不到直接从本地
localDNS获取数据，（从本地localDNS获取数据后期会改为发送UDP包封装dns协议从公共dns服务器直接获取，比如114dns等。dns服务器地址可自行设定。
）获取到数据后进入测速模块。测速模块最新版本可以配置两种方式，一种是http空请求。两个http头的交互，类似tcp首保耗时时间原理
，用来测试链路最快。另一种是ping命令，（icmp协议）来尽量最小化流量的消耗，考虑倒可能有的服务器禁ping就使用空http测速即可。
测速后将数据插入本地 cache 即可。

代码结构

工程代码一共有八个主要package包，分别是cache、httpdns、log、model、query、score、speedtest、networktype。

cache包数据缓存层

IDnsCache是该包的对外主要接口。DnsCacheManager
实现该接口，封装了管理该包的所有逻辑调度，ConcurrentHashMap是内存缓存层的介质，当初使用过非线程安全的hashMap遇到了很多线程锁的问题，没有更好的办法自己控制锁管理，就替换成线程安全的concurrenthashmap对象了。DBConstants
设定了数据库名字表名字以及表字段，包含全部sql语句。 DNSCacheDatabaseHelper
用来操作数据库，所有和数据库交互的逻辑都在该类。

networktype包用来监控网络变化和检测当前网络状态

Constants 设定了网络状态的相关常量。 NetworkManager类也是这个包的主入口类所有网络状态的获取都是通过这个类来获取。 NetworkStateReceiver用来注册网络广播来接受网络发生变化的事件。

httpdns包封装了所有HttpDNS api交互请求

IHttpDNS接口定义了该包和外部交互的所有数据格式，HttpDnsManager 实现了IHttpDNS接口。
HttpDnsConfig定义了使用到的常量配置，以及dns api接口的开关，和顺序。
requests包里INetworkRequests接口轻量级的定义了网络请求的实现，
目前使用ApacheHttp实现的该接口，如果用户有需求更换网络实现方式实现INetworkRequests 接口即可。 IJsonParser
接口定义了 httpdns api返回数据解析json的方式，目前使用 android jsonObject实现。
如果需要扩展直接实现该接口即可。

log包实现了记录dnscachelib库记录日志倒文件的工具类

IDnsLog约定了写log和获取log的方法。 HttpDnsLogManager实现该接口，并管理log模块。该模块还有一个写文件的工具类。

model包封装了全部数据交互模型

DomainModel对应数据库domain表， IpModel对应数据库ip表。 HttpDnsPack是获取httpdns api接口数据的模型。 ConnectFailModel用来记录所有异常错误。

query包是查询模块的入口

IQuery定义了该包对外的协议接口。 QueryManager实现该接口封装了所有查询相关操作。

Score包也是前面说的评估模块

IScore定义该包对外实现的接口，ScoreManager实现该接口。 PlugInManager用来管理所有评估插件。所有的评估插件均实现 IPlugIn接口协议，规定输入输出。使用者可以自行添加评估插件。

speedtest包实现测速逻辑

ISpeedtest规定该包对外的接口协议， SpeedtestManager实现ISpeedtest接口。封装了测速相关逻辑，包括空http请求，以及ping命令测速。

另外场景包种有几个类简单介绍下。 DNSCache类是lib的主入口类，用户的所有操作均调用该入口类，该类是单利类直接获取实例调用即可，也是主场景。

由于内部model数据过于复杂，为用户专门封装DomainInfo模型。该类仅返回用户使用的相关数据。

DNSCacheConfig 是httpdns库的全局配置文件，可以直接修改该文件，也可以外部调用方法设置参数。该文件还封装了云端动态更新缓存配置。

代码结构如下图所示：

在编写该库的时候遇到最头疼的问题可能就是多线程同时访问导致遇到的数据异常错误。比如用户访问 api.weibo.cn
域名该域名目前数据库中没有缓存，内存中也没有缓存。在同时有多个请求以来来获取该域名的ip的时候，因为没有数据会去请求api接口获取数据，
导致同时开启多个线程访问数据。解决办法在请求api接口前增加正在请求队列，

任何需要请求数据的domain都先要在该队列检测是否有请求存在如果没有在继续进入后面流程如果有则丢掉本次请求指令。
另外在操作数据库的时候使用了对象锁和 synchronized 方法锁，
导致了程序有锁死的情况，后改成全部使用对象锁就解决了该问题。全程的调试数据也是最头疼的环节，后直接编写测试程序，时时调试所有环节的数据（看到时时数据后发现了很多程序的bug，后都一一解决）。

以上为冯老师的分享，接下来是星宇跟大家分享下项目从研发倒现在所遇到的一些主要问题和大家有疑问的点。

开发过程中，常见的一些问题

1、手机网络从3G 切换到 Wifi下处理了什么？

NetworkStateReceiver类来监听网络是否发生变化，在网络有变化的时候，会刷新
NetworkManager类中的网络环境，在客户端内如果是手机网络可以知道网络类型（2G、3G、4G）也可以知道当前SP（移动、联通、电信），如果是Wifi网络环境可以知道SSID（wifi名字）在刷新网络环境后，会重新查询缓存内是否有当前链路下的最优A记录，如果没有则从LocalDNS获取第一次，然后马上更新httpdns记录。

2、网络发生变化后，返回的A记录还一样么？

数据库中缓存的数据，是根据当前sp来缓存的，也就是说当自身网络环境变化后，返回的a记录是不一样的。手机网络下会根据当前sp来缓存
a记录服务器ip，如果是wifi网络环境下
根据当前ssid来缓存a记录，因为wifi环境下库自己没有办法明确判断出自己的运营商，但相同的ssid不会发生频繁的网络运营商变化。
所以在wifi下请求回来的a记录直接关联ssid名字即可，即使wifi sp发生变化，最多延迟一个ttl时间就更新成最新的a记录了。

3、怎样进行测速？

在从HttpDNS获取回来a记录的时候进行测速，测速的方式有两种：
ping和空的http请求。考虑倒有些服务器不支持ping来进行链路质量评判，可以使用空的http请求，仅仅是两个http头的流量开销，而ping的方式流量开销就更小了。
这个功能可以在库中自己配置。这里的测速其实是模拟首保接收的时间来做的，
同时对于流量控制严格的可以在库中配置测速频繁度，比如一台服务器在5分钟内有过测速记录则不进行测速。

4、域名ttl刚刚过期，库还没有从HttpDNS拉取回来数据怎么办？

ttl过期的前10秒去请求数据，在ttl过期后的10秒内库也认为当前a记录是有效的，会给你直接返回。

5、lib库目前只能使用 dnspod 服务商么？支持dnspod 企业版本么？

目前库可以支持自定义的 HttpDNS api接口，只需要实现IHttpDns接口类即可，在配置了dnspod企业key和id 的时候自动启用企业版本加密传输，支持企业版本。

6、使用这个库会不会降低应用请求网络的访问速度？

从目前的测试数据来看是不会的，HttpDNS库返回a记录的时间平均在5毫秒以内，有时会出现内存缓存中没有该域名记录，数据库中也没有的时候会从LocalDNS获取a记录，时间会稍长一些

一旦从LocalDNS获取后，会缓存倒内存中，在HttpDNS获取数据后会更新内存中得domain记录。
从库中获取a记录会比从LocalDNS获取a记录快一些。
在访问网络的时候由于是使用ip直链，可以起到一些加速效果，lib库获取domainA记录 + ip直接访问服务器耗时小于
直接域名请求服务器。相关数据图片

下面给出一个测试系统的截图

7、lib库里面访问网络使用的是哪个网络库？ json库用的是哪个？

考虑到该库的轻量级，使用的是android系统的org.apache.http.client.HttpClient库访问网络，如果需要切换到工程在使用的网络库可以实现
INetworkRequests 接口即可切换网络库。 json解析使用的也是android系统自带的org.json.JSONObject
如有需求切换json解析库，可直接实现IJsonParser接口即可切换。

8、使用该网络库会给我的app带来多大的体积增加？

目前该lib库没有引用任何外部的库文件。一切本着使用系统自身的api为原则，来保证库的轻量级，和兼容性。目前lib库打包后70多k，代码在5千行左右。测试工程代码在6千行左右。

9、lib库的配置必须要通过修改源代码的方式来进行配置么？

任何参数都可以在库调用方配置，DNSCacheConfig 类是整个库的配置文件。并且支持云端动态更新配置需要实现DNSCacheConfig.ConfigText_API 更新地址。具体配置api接口请参考 dome工程中设置库的方式。

10、缓存domain记录是存储成文件还是数据库，或者android内部的一些存储方式？

lib缓存数据是通过数据库存储的。SQLiteDatabase，具体的表接口和sql语句请参考 DBConstants 类文件。

11、评估模块有什么功能？

评估模块目前由五个插件组成，速度插件、推荐优先级插件、历史成功次数插件、历史错误数插件、最近一次成功时间插件。
每一个a记录服务器ip，都会经过这五个插件进行评估排序后返回给使用者。所有插件评估分值比重可以配置，
根据自己的需求以及不同的使用场景，调整出最合理的权重分配。

下面给出评估模块算法细节图

12、速度插件具体算法？

比如速度插件评分体系，满分100分，那么有3个服务器ip， 1号服务器http请求耗时10毫秒， 2号服务器20毫秒， 3号服务器30毫秒。那么经过插件计算后 1号服务器100分， 2号服务器50分， 3号服务器25分。

13、优先级插件又是什么？

如果是自定义的服务器，可以返回服务器优先级字段，该的字段代表推荐使用该服务器的权重，比如该字段服务端可以和监控系统结合起来，甚至是用来分流。相应的权重值，也会算出来不同的分值。

14、历史成功次数插件是什么？历史错误次数插件是什么？

在当前sp当前链路下，会记录访问过的该服务器ip的成功次数，成功次数越多认为该服务器相对稳定。
会在排序的时候根据权重比值进行影响最终排序结果，该插件权重不建议过高。
同理历史错误插件也是记录当前链路下服务器出过错误的次数，次数越高认为越不稳定。排序尽量靠后。同样该插件权重不建议过高。

15、最后一次成功时间？

如果该服务器在很近的时间内访问过，那么评估系统则认为他链路是通的，则会给一个分值，越接近现在的时间的服务器分值越高。 24小时以前访问的分值为0 。

16、评估插件就这五个吗？

该五个插件属于抛砖引玉，可以自定义插件只需要实现 IPlugIn 接口即可。所有的插件启用和停止都在配置文件中可以修改，以及配置每个插件的权重比。

17、智能评估一定会带来好的效果吗？

首先httpdns返回的a记录已经是经过当前地域和当前sp返回的最优记录结果集，至少不会降低效率。

18、我可以不使用智能评估模块么？

可以的在配置文件中关掉智能评估即可，具体代码参照demo即可。关掉智能评估模块后，会在多个a记录中随机排序返回。

19、该Lib库块兼容性如何？

使用testin兼容性测试测试兼容性结果：99.49%。 Android平台全部由java代码开发，没有使用任何特殊特性，覆盖全部系统版本。

最后附几张测试工程效果图：

模拟了客户端访问http请求，分别标识了每个任务的详细信息。
这个页面全都是数据库相关配置，在代码中可以直接找到具体设置库文件的接口。
数据报表入口，包含全部任务加速效果延迟效果数据记录， lib库耗时走向，每个ip直接访问请求和domain访问请求速度对比，统计了服务器平局速度。
缓存数据标签中包含了当前库的所有状态，能实时的看到内存缓存层的所有数据状态，包括数据库中得所有数据状态。
每秒钟刷新一次。在这里可以清空缓存层数据、数据层数据、已经当前测试工程的数据。在这里你可以清楚的看到 ip 和 domain的对应关系，
以及数据库表中每项的关系。和所有的domain 以及 ip 的状态。

全部代码均已开源 https://github.com/SinaMSRE/HTTPDNSLib ，包括测试工程也开源了设计文档和流程图都在 git 上有。测试工程的 ui psd 貌似也在git上

Q&A

Q1、每次请求url都需要去ping么？

不需要每次都ping的，测试链路是否通畅会在从 httpdns api接口获取数据后，在测试链路是否通畅，每次请求 httpdns api间隔是一个 domain 设置的 ttl时间

ping 直发一个包，最小化的减少流量开销。

检测链路如果配置成 http 空的请求，也是同理在 httpdns api请求结束后，才会检测链路是否畅通。

Q2、前面提到的并发请求，被丢弃的请求是怎么处理的

并发请求是说客户端请求 HttpDNS lib库，同时发 api.weibo.cn 的请求么？

因为去问 HttpDNS api接口的时候，只需要有一个请求去问就可以了，去问 HttpDNS api的时候已经切换到
非客户端主线程，在客户端调用的主线程中如果没有缓存数据就从本地获取 dns 的a记录返回了。所以直接丢弃这个访问 HttpDNS
api的请求即可，不会影响到其他流程逻辑。

Q3、南北网络之间请求有特别处理么？

南方电信，北方网通，运营商ip不一样

首先 HttpDNS 返回的a记录会根据你的出口ip 来从权威的 dns 服务器问出来结果。如果你是南方的ip 肯定给你的a记录
也是南方的， httpdns 返回的记录理论应该是和传统的 dns 返回的 a 记录是一样的。而去问 httpdns 的api 地址是
bgp的机房。所以也是兼容多链路多地域。有遇见过传统 dns 出口可能是电信的，但业务访问的 ip 出口是联通的情况。所以
HttpDNS 访问 a记录也能避免这类一部分错误。

Q4、用dnspod是用的他的接口么？如果dnspod上是配置的是cname，会递归解析出最终的ip缓存下来么？

会的。这个依赖dnspod的返回结果，同时也支持 cname 的返回结果。

比如图片使用 cdn 如果返回的是 cname 结果。那么数据库中记录的也是 cname 结果。通过 cname 家 host 头来访问也是可以的。

Q5、数据库中记录的是cname，还是cname解析出的ip？

数据库中记录的是 cname ，并不是ip 。

因为测试过，从一栋大楼走到另外一个大楼里面访问的最终ip可能都不相同。所以如果返回的是cname 则直接存储cname 。网络环境发生变化，会重新拉取，不会使用缓存的cname 。

Q6、那cname的情况下，httpdns就起不到实际的作用了？

不会的，一般劫持的都是业务的主要域名，而cname域名的劫持相对较少，从我们公司的业务来看啊。而且 dnspod
返回cname 的情况我目前还没看到。都是解析倒ip 。而我们自己做的 httpdns 服务器，第一期目前会解析倒 cname 的节点。
跨域的ip解析还没做会放到二期。

Q7、我们遇到的问题是主域名解析没问题，cname的域名是amazon aws的域名，经常莫名其妙解析不通，怀疑是运营商搞鬼。当时也想自己做这个httpdns，但发现很麻烦，小厂没人力搞这个事情。

有这个可能，我觉得可以把你们的domain放到dnspod里面试下解析出来的是不是cname如果是直接的ip应该没问题。后期我们有计划加上udp直接发送dns协议包到公共的dns服务器节点来获取数据，也支持设置自己家的权威dns服务器。

想与高可用架构微信群内专家继续讨论DNS高可用话题，请关注公众号后，回复“arch”申请进群。

全局精确流量调度新思路-HttpDNS服务详解

小编：对于互联网，域名是访问的第一跳，而这一跳很多时候会“失足”，导致访问错误内容，失败连接等，让我们在互联网上畅游的爽快瞬间消失，而对于这关键的第一跳，鹅厂也在持续深入研究和思考对策，今天小编就邀请了我们负责这块域名解析的好伙伴—廖伟健同学跟我们做一个分享。同时，今天小编也非常希望了解大伙对这块内容的感受，所以今天文中加入了投票功能，希望您投上神圣的一票哦。事不延迟，我们启程！

但凡使用域名来给用户提供服务的互联网企业，都或多或少地无法避免在有中国特色的互联网环境中遭遇到各种域名被缓存、用户跨网访问缓慢等问题。那么对于腾讯这样的域名数量在10万级别的互联网公司来讲，域名解析异常的情况到底有多严重呢？每天腾讯的分布式域名解析监测系统在不停地对全国所有的重点LocalDNS进行探测，腾讯域名在全国各地的日解析异常量是已经超过了80万条。这给腾讯的业务带来了巨大的损失。为此腾讯建立了专业的团队与各个运营商进行了深度沟通，但是由于各种原因，处理效率及效果均不能达到腾讯各业务部门的需求。除了和运营商进行沟通，有没有一种技术上的方案，能从根源上解决域名解析异常及用户访问跨网的问题呢？

一、问题根源：

要解决问题，我们得先得了解下现在国内各ISP的LocalDNS的基本情况。国内运营商LocalDNS造成的用户访问异常可以归为下三类：

1、域名缓存：

域名缓存很好理解，就是LocalDNS缓存了腾讯的域名的解析结果，不向腾讯权威DNS发起递归，示意图如下：

为何LocalDNS要把域名解析结果进行缓存呢？原因有以下几个：

（1）保证用户访问流量在本网内消化：国内的各互联网接入运营商的带宽资源、网间结算费用、IDC机房分布、网内ICP资源分布等存在较大差异。为了保证网内用户的访问质量，同时减少跨网结算，运营商在网内搭建了内容缓存服务器，通过把域名强行指向内容缓存服务器的IP地址，就实现了把本地本网流量完全留在了本地的目的。

（2）推送广告：有部分LocalDNS会把部分域名解析结果的所指向的内容缓存，并替换成第三方广告联盟的广告。

这种类型的行为就是我们常说的域名缓存，域名缓存会导致用户产生以下的访问异常：

A、仅对80端口的http服务做了缓存，如果域名是通过https协议或其它端口提供服务的，用户访问就会出现失败。比如支付服务、游戏通过指定端口连接connect server服务等。

B、缓存服务器的运维水平参差不齐，时有出现缓存服务器故障导致用户访问异常的问题。

2、解析转发：

除了域名缓存以外，运营商的LocalDNS还存在解析转发的现象。解析转发是指运营商自身不进行域名递归解析，而是把域名解析请求转发到其它运营商的递归DNS上的行为。正常的LocalDNS递归解析过程是这样的：

而部分小运营商为了节省资源，就直接将解析请求转发到了其它运营的递归LocalDNS上去了：

这样的直接后果就是腾讯权威DNS收到的域名解析请求的来源IP就成了其它运营商的IP，最终导致用户流量被导向了错误的IDC，用户访问变慢。

3、LocalDNS递归出口NAT：

LocalDNS递归出口NAT指的是运营商的LocalDNS按照标准的DNS协议进行递归，但是因为在网络上存在多出口且配置了目标路由NAT，结果导致LocalDNS最终进行递归解析的时候的出口IP就有概率不为本网的IP地址：

这样的直接后果就是GSLB DNS收到的域名解析请求的来源IP还是成了其它运营商的IP，最终导致用户流量被导向了错误的IDC，用户访问变慢。

二、现有的解决方案及存在的问题：

运营商的LocalDNS解析域名异常，给对用户访问腾讯业务的体验造成了非常大的损害。那么我们是如何处理这些域名解析异常的问题的呢？

1、实时监控+商务推动：

这种方案是目前腾讯的运营团队一直在使用的方案。这种方案就是周期比较长，毕竟通过行政手段来推动运营商来解决这个问题是比较耗时的。另外我们通过大数据分析，得出的结论是Top 3的问题用户均为移动互联网用户。对于这部分用户，我们有什么技术手段可以解决以上的问题呢？

2、绕过自动分配DNS，使用114dns或Google public DNS：

这个方案看上去很美好，114dns是国内最大的中立缓存DNS，而Google又是秉承不作恶理念的互联网工程帝国巨鳄，而且腾讯的权威DNS又支持edns-client-subnet功能，能直接识别使用Google publicDNS解析腾讯域名的用户的IP地址，不会出现流量调度失效。但是问题来了：

（1）如何在用户侧构造域名请求：对于PC端的客户端来说，构造一个标准的DNS请求包并不算什么难事。但在移动端要向一个指定的LocalDNS上发送标准的DNS请求包，而且要兼容各种iOS和android的版本的话，技术上是可行的，只是兼容的成本会很高。

（2）推动用户修改配置极高：如果要推动用户手动修改PC的DNS配置的话，在PC端和手机客户端的WiFI下面还算勉强可行。但是要用户修改在移动互联网环境下的DNS配置，其难度不言而喻。

3、完全抛弃域名，自建connectcenter进行流量调度：

如果要采用这种这种方案的话，首先你就得要拿到一份准确的IP地址库来判断用户的归属，然后再制定个协议搭个connect center来做调度，然后再对接入层做调度改造。这种方案和2种方案一样，不是不能做，只是成本会比较高，尤其对于腾讯这种业务规模如此庞大的公司而言。

三、利用HttpDNS解决用户域名解析异常：

既然上面的方案都存在那么多的问题，那有没有一种调度精准、成本低廉、配置方便的基于域名的流量调度系统呢？答案是肯定的。腾讯公司的GSLB 团队推出了一种全新的域名解析调度系统：HttpDNS。HttpDNS是为移动客户端量身定做的基于Http协议和域名解析的流量调度解决方案，专治LocalDNS解析异常以及流量调度不准。详细介绍如下：

（1）HttpDNS基本原理：

HttpDNS的原理非常简单，主要有两步：

A、客户端直接访问HttpDNS接口，获取业务在域名配置管理系统上配置的访问延迟最优的IP。（基于容灾考虑，还是保留次选使用运营商LocalDNS解析域名的方式）

B、客户端向获取到的IP后就向直接往此IP发送业务协议请求。以Http请求为例，通过在header中指定host字段，向HttpDNS返回的IP发送标准的Http请求即可。

（2）HttpDNS优势：

从原理上来讲，HttpDNS只是将域名解析的协议由DNS协议换成了Http协议，并不复杂。但是这一微小的转换，却带来了无数的收益：

A、根治域名解析异常：由于绕过了运营商的LocalDNS，用户解析域名的请求通过Http协议直接透传到了腾讯的HttpDNS服务器IP上，用户在客户端的域名解析请求将不会遭受到域名解析异常的困扰。

B、调度精准：HttpDNS能直接获取到用户IP，通过结合腾讯自有专利技术生成的IP地址库以及测速系统，可以保证将用户引导的访问最快的IDC节点上。

C、实现成本低廉：接入HttpDNS的业务仅需要对客户端接入层做少量改造，无需用户手机进行root或越狱；而且由于Http协议请求构造非常简单，兼容各版本的移动操作系统更不成问题；另外HttpDNS的后端配置完全复用现有权威DNS配置，管理成本也非常低。总而言之，就是以最小的改造成本，解决了业务遭受域名解析异常的问题，并满足业务精确流量调度的需求。

D、扩展性强：HttpDNS提供可靠的域名解析服务，业务可将自有调度逻辑与HttpDNS返回结果结合，实现更精细化的流量调度。比如指定版本的客户端连接请求的IP地址，指定网络类型的用户连接指定的IP地址等。

当然各位可能会问：用户将首选的域名解析方式切换到了HttpDNS，那么HttpDNS的高可用又是如何保证的呢？另外不同运营商的用户访问到同一个HttpDNS的服务IP，用户的访问延迟如何保证？

为了保证高可用及提升用户体验，HttpDNS通过接入了腾讯公网交换平台的BGP Anycast网络，与全国多个主流运营商建立了BGP互联，保证了这些运营商的用户能够快速地访问到HttpDNS服务；另外HttpDNS在多个数据中心进行了部署，任意一个节点发生故障时均能无缝切换到备份节点，保证用户解析正常。

四、接入效果及未来展望：

当前HttpDNS已在腾讯内部接入了多个业务，覆盖数亿用户，并已持续稳定运行超过一年时间。而接入了HttpDNS的业务在用户访问体验方面都有了非常大的提升。以某个接入HttpDNS的业务为例，该业务仅通过接入HttpDNS，在未做任何其它优化的情况下，用户平均访问延迟下降超过10%，访问失败率下降了超过五分之一，用户访问体验的效果提升非常显著。另外腾讯的HttpDNS服务除了在腾讯内部被广泛使用以外，也受到了业务同行的肯定。国内最大的publicDNS服务商114dns在受到腾讯DNS的启发下，也推出了HttpDNS服务。

在未来的日子里，腾讯GSLB团队将会在腾讯内部进一步推广HttpDNS服务，并将在实际业务的需求下对HttpDNS服务进行升级，如提供更为通用、安全、简单的接入协议，进一步提升接入用户的网络访问体验等等。希望HttpDNS能为各位在解决域名解析异常及全局流量调度失效方面提供一个简单、可行的思路，也欢迎各位业界同行与腾讯一起，就如何进行更精准的全局流量调度方面进行更为深入的讨论！

http://119.29.29.29/

接入文档
https://www.dnspod.cn/httpdns/guide

DEMO
https://www.dnspod.cn/httpdns/demo

腾讯DNSPod公共DNS 119.29.29.29 体验报告

腾讯DNSPod推出新Open DNS服务，公共DNS是119.29.29.29

腾讯DNSPod公共DNS 119.29.29.29 体验报告

上周看到DNSPod官网正式推出了公共DNS服务，并且号称是国内第一家支持ECS协议的公共DNS，于是抓紧时间体验了下。(其实很久之前就听闻DNSPod有搞公共DNS的动作，不知道为什么一直没有正式对外推广，后来看了服务介绍，个人猜测可能就是为了等Google的ECS协议才拖到现在发布吧。)Anyway，随着代表腾讯的DNSPod加入，现在BAT三家的公共DNS服务算是全部集齐!

DNSPod的公共DNS服务(又称“Public DNS+”)IP是119.29.29.29，和他家之前推出的移动解析“D+”是一样的，目测后端应该是同一套架构。(再吐个槽，怎么现在都喜欢在名字后面搞个+号呢?DNSPod之前出了httpdns叫D+，现在搞公共DNS，又叫Public DNS+，是为了响应“互联网+”号召么?)

言归正传!我特意找了国内外几家知名的公共DNS对比测试，它们是：

114dns： 114.114.114.114

阿里： 223.5.5.5.5

百度： 180.76.76.76

360： 101.226.4.6

Google： 8.8.8.8

从宣传资料来看，各家卖点都差不多，基本都是快速、准确、稳定、无劫持等等。下面就以这些方面做考量，用实际数据说话吧。

1、快速

关于DNS的持续测试工具，我简单选用ping测试。通过测试ping来测试延时，也可以反映DNS的解析延时。

1-1 从全国各地的3大运营商进行ping测试，测试结果如下：

如上图，可以清晰地看到Google的公共DNS平均时延极高，达到了174.495ms。果然从大陆访问Google远在台湾的服务器，速度还是太慢了!

1-2 以下是去掉Google后，国内几家公共DNS的延时表现：

DNSPod的公共DNS延时最低，为35ms;其次是百度的38.503ms和114的40.195ms;阿里的公共DNS延时最高，达到了41.246ms，仍需努力呀!

【结论】在国内，本土4家公共DNS的速度远远快于国外的Google。其中DNSPod最快，但与国内其他公共DNS差距不算大。至于360，连Anycast都没有，直接懒测out!

2、准确

如果运营商没有各种劫持和NAT的话，毫无疑问运营商的递归DNS应该是最准确的，但事实往往事与愿违，也是因为这样，我们不得不使用公共DNS，因此公共DNS的准确度，是重要的考虑因素。

理论来讲，如果公共DNS能支持Google的ECS协议，直接把用户的IP信息透传到授权DNS，授权DNS根据用户的IP而不是递归的IP来进行智能解析，这样就可以保证解析的准确度了。但是据了解，目前除了国外的Google和Open DNS支持ECS以外，国内之前的公共DNS都没有支持，DNSPod算是第一家。

个人认为主要原因应该是支持ECS的技术难度太高：需要每个域名、每个线路、每个IP段单独缓存，缓存量实在是太大了，而如果不缓存速度又太慢。技术投入大，而实际收益不高，应该是国内其他公共DNS对ECS望而却步的原因。

2.1 各家公共DNS对ECS协议的支持情况：

经过实际测试发现，DNSPod的公共DNS确实如它宣传的一致，是支持了ECS的!并且支持程度和Google一样，在接入端和后端都支持ECS。这确实是个惊喜!以后终于可以用着国内的公共DNS，享受快速解析的同时也不牺牲解析准确度了。

另外，国内其他4家中，只有阿里的公共DNS在接入端是支持ECS。但说实话，单单在接入端支持ECS对用户解析准确度的提升并没有实质性的帮助，还是和使用用户实际IP一样依赖后端递归DNS的分布情况，只是可以方便用户对解析准确度进行测试而已。所以像Open DNS的接入端都没有支持ECS，只是后端支持。

又有问题来了，当用户解析域名的授权DNS不支持ECS时，只有公共DNS支持ECS也没用啊。这时候怎么办呢?那就只有靠公共DNS的后端节点部署情况来提升解析准确度了。

在更多省份的运营商部署更多的递归DNS节点，就可以根据用户DNS请求中的IP分配到对应的节点去。当某个省份运营商没有递归DNS节点时，只能将请求分配到邻近省份同运营商的递归节点上，解析准确度会受到一定影响。简单来讲，就是“节点越多，解析越准确!”。

从各家公共DNS的官网上看了下后端递归DNS节点的部署情况，发现DNSPod的节点部署竟然也是最多的!

2.1 各家公共DNS节点情况：

如上，在国内几家公共DNS中，DNSPod的公共DNS无论是总结点数还是国外节点数，都比其他家高得多。(百度的节点数没公布，不知道有多少个。Google没有国内节点，测试了下国内用户的DNS查询请求，是路由到了台湾的解析服务器。)

【结论】DNSPod的公共DNS在接入端和后端都支持ECS协议，准确度等同Google，速度又比Google快。另外DNSPod密集的节点部署，进一步保证了解析准确度，Public DNS+确实值得推荐!为良心产品点赞!

3、稳定

因为无法知道各家公共DNS的具体架构，所以我用dig测试和ping测试丢包率来看下各家公共DNS服务的稳定性(未测试360)。

dig测试来看，BAT和114都部署了多个国内接入节点，且每个接入节点都是多台服务器组成的集群，都用同一个IP使用BGP Anycast接入，不管是单服务器故障还是单节点故障，都可以快速切换，稳定性上应该是都有保障的。Google的话，因为国内没有服务器且经常受到防护墙的干扰，稳定性欠佳。

3-1 ping测试的丢包率，各家公共DNS结果如下：

从ping测试的丢包率来看，国内各家公共DNS丢包率都差不多，DNSPod、阿里、114的丢包率都在1%左右，百度丢包略高为2.286%。

Google的结果就惨多了，半夜之后好点在30%左右，白天和上半夜在70%左右，整体丢包率为50%左右，纵是真爱也真心不敢推荐使用。

【结论】 DNSPod、阿里、114和百度4家的公共DNS服务，在稳定性没有看出明显差别，大家都可以放心使用。

4、无劫持

所有公共DNS都宣称自己无劫持，这个功能不太好测试，但是实际使用中确实没发现明显的恶意劫持，就算都过关吧。

以上就是我对市场上几家主流公共DNS服务进行的实际体验报告。最终发现新出的“Public DNS+”(腾讯DNSPod的公共DNS)确实不错，无论速度、准确度、稳定性都可圈可点，与其他家相比都不逊色甚至略强。感兴趣的不妨把DNS改为119.29.29.29试试吧。

腾讯DNSPod推出新Open DNS服务，公共DNS是119.29.29.29

9月7日消息，近日，腾讯旗下DNSPod正式推出了类似google open dns服务，公共域名解析服务Public DNS+，使用同一个服务IP 119.29.29.29，号称安全零劫持。

DNS劫持是一种通过改变指定域名在运营商侧DNS配置的正确解析指向，将该域名的解析结果重定向到劫持IP的劫持行为。DNS劫持类型可大致分为运营商缓存，广告，恶意劫持等类别。

DNSPod推出的Public DNS+服务号称有安全零劫持、准确不丢包、快速无等待、稳定多容灾的优势。

DNSPod建立于2006年3月份，是中国第一大DNS解析服务提供商、第一大域名托管商，2011年8月8日被腾讯收购，收购完成后，DNSPod保持独立运营。

国内外几家知名的公共DNS:

114dns： 114.114.114.114

阿里： 223.5.5.5.5

百度： 180.76.76.76

360： 101.226.4.6

Google： 8.8.8.8

我们就测试一下这些dns dig的速度如何：

360DNS 101.226.4.6 dig测试
# dig @101.226.4.6 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @101.226.4.6 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23722
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com. IN A
;; ANSWER SECTION:
v.qq.com. 331 IN CNAME v.tc.qq.com.
v.tc.qq.com. 3165 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 60 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 161 IN A 119.147.253.22
p21.tcdn.qq.com. 161 IN A 119.147.33.32
p21.tcdn.qq.com. 161 IN A 119.147.253.21
p21.tcdn.qq.com. 161 IN A 119.147.33.28
p21.tcdn.qq.com. 161 IN A 119.147.253.20
p21.tcdn.qq.com. 161 IN A 113.107.238.22
p21.tcdn.qq.com. 161 IN A 119.147.33.29
p21.tcdn.qq.com. 161 IN A 119.147.33.31
p21.tcdn.qq.com. 161 IN A 119.147.33.30
p21.tcdn.qq.com. 161 IN A 59.57.18.147
;; Query time: 31 msec
;; SERVER: 101.226.4.6#53(101.226.4.6)
;; WHEN: Wed Dec 2 11:50:05 2015
;; MSG SIZE rcvd: 244

百度DNSdig测试180.76.76.76
# dig @180.76.76.76 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @180.76.76.76 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54787
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com. IN A
;; ANSWER SECTION:
v.qq.com. 488 IN CNAME v.tc.qq.com.
v.tc.qq.com. 856 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 315 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 319 IN A 119.147.33.30
p21.tcdn.qq.com. 319 IN A 119.147.253.21
p21.tcdn.qq.com. 319 IN A 119.147.33.29
p21.tcdn.qq.com. 319 IN A 119.147.33.28
p21.tcdn.qq.com. 319 IN A 119.147.33.31
p21.tcdn.qq.com. 319 IN A 119.147.253.22
p21.tcdn.qq.com. 319 IN A 59.57.18.147
p21.tcdn.qq.com. 319 IN A 119.147.253.20
p21.tcdn.qq.com. 319 IN A 113.107.238.22
p21.tcdn.qq.com. 319 IN A 119.147.33.32
;; Query time: 38 msec
;; SERVER: 180.76.76.76#53(180.76.76.76)
;; WHEN: Wed Dec 2 11:49:34 2015
;; MSG SIZE rcvd: 244

阿里Open DNS公共DNSdig测试： 223.5.5.5.5
# dig @223.6.6.6 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @223.6.6.6 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55386
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com. IN A
;; ANSWER SECTION:
v.qq.com. 235 IN CNAME v.tc.qq.com.
v.tc.qq.com. 235 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 235 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 235 IN A 119.147.253.20
p21.tcdn.qq.com. 235 IN A 113.107.238.22
p21.tcdn.qq.com. 235 IN A 119.147.33.30
p21.tcdn.qq.com. 235 IN A 59.57.18.147
p21.tcdn.qq.com. 235 IN A 119.147.33.32
p21.tcdn.qq.com. 235 IN A 119.147.33.28
p21.tcdn.qq.com. 235 IN A 119.147.33.29
p21.tcdn.qq.com. 235 IN A 119.147.253.22
p21.tcdn.qq.com. 235 IN A 119.147.253.21
p21.tcdn.qq.com. 235 IN A 119.147.33.31
;; Query time: 5 msec
;; SERVER: 223.6.6.6#53(223.6.6.6)
;; WHEN: Wed Dec 2 11:48:56 2015
;; MSG SIZE rcvd: 244

腾讯Dnspod openDNS 公共DNS dig测试 119.29.29.29
# dig @119.29.29.29 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @119.29.29.29 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63125
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com. IN A
;; ANSWER SECTION:
v.qq.com. 169 IN CNAME v.tc.qq.com.
v.tc.qq.com. 3169 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 169 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 169 IN A 119.147.33.32
p21.tcdn.qq.com. 169 IN A 119.147.253.21
p21.tcdn.qq.com. 169 IN A 113.107.238.22
p21.tcdn.qq.com. 169 IN A 119.147.33.30
p21.tcdn.qq.com. 169 IN A 119.147.33.29
p21.tcdn.qq.com. 169 IN A 59.57.18.147
p21.tcdn.qq.com. 169 IN A 119.147.33.31
p21.tcdn.qq.com. 169 IN A 119.147.33.28
p21.tcdn.qq.com. 169 IN A 119.147.253.20
p21.tcdn.qq.com. 169 IN A 119.147.253.22
;; Query time: 12 msec
;; SERVER: 119.29.29.29#53(119.29.29.29)
;; WHEN: Wed Dec 2 11:47:43 2015
;; MSG SIZE rcvd: 244

114dns公共DNS dig测试： 114.114.114.114
# dig @114.114.114.114 v.qq.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.4 <<>> @114.114.114.114 v.qq.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35456
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;v.qq.com. IN A
;; ANSWER SECTION:
v.qq.com. 172 IN CNAME v.tc.qq.com.
v.tc.qq.com. 2611 IN CNAME v.tcdn.qq.com.
v.tcdn.qq.com. 539 IN CNAME p21.tcdn.qq.com.
p21.tcdn.qq.com. 262 IN A 113.107.238.22
p21.tcdn.qq.com. 262 IN A 119.147.33.30
p21.tcdn.qq.com. 262 IN A 119.147.33.29
p21.tcdn.qq.com. 262 IN A 119.147.33.31
p21.tcdn.qq.com. 262 IN A 119.147.33.32
p21.tcdn.qq.com. 262 IN A 119.147.253.20
p21.tcdn.qq.com. 262 IN A 119.147.33.28
p21.tcdn.qq.com. 262 IN A 119.147.253.22
p21.tcdn.qq.com. 262 IN A 119.147.253.21
p21.tcdn.qq.com. 262 IN A 59.57.18.147
;; Query time: 27 msec
;; SERVER: 114.114.114.114#53(114.114.114.114)
;; WHEN: Wed Dec 2 11:48:44 2015
;; MSG SIZE rcvd: 244

1. Public DNS+简介

a) 快速

b) 准确

c) 稳定

d) 安全、无劫持

2. Why DNSPod Public DNS+？

3. 什么用户可以使用Public DNS+？

4. DNSPod Public DNS+的架构是怎么样的？

5. Public DNS+的节点是如何分布的？

国内线路，80条：

电信线路22条，如下所示：

联通线路18条，如下所示：

移动线路25条，如下所示：

铁通线路3条，如下所示：

教育网线路4条，如下所示：

长宽线路4条，如下所示

杭州华数线路2条，如下所示：

天威节点1条，为默认节点。

国内全局默认节点1条。

国外线路4条,如下所示：

DNSPod：★★★★★

114DNS：★★★★

阿里 AliDNS：★★★★

★★★

CNNIC SDNS：★★★

OpenDNS：★★

Google DNS：★★

最后总结

HttpDNSLib库组成

查询模块：

数据模块：

评估模块：

HttpDNS交互流程

代码结构

cache包数据缓存层

networktype包用来监控网络变化和检测当前网络状态

httpdns包封装了所有HttpDNS api交互请求

log包实现了记录dnscachelib库记录日志倒文件的工具类

model包封装了全部数据交互模型

query包是查询模块的入口

Score包也是前面说的评估模块

speedtest包实现测速逻辑

开发过程中，常见的一些问题

1、手机网络从3G 切换到 Wifi下处理了什么？

2、网络发生变化后，返回的A记录还一样么？

3、怎样进行测速？

4、域名ttl刚刚过期，库还没有从HttpDNS拉取回来数据怎么办？

5、lib库目前只能使用 dnspod 服务商么？ 支持dnspod 企业版本么？

6、使用这个库会不会降低应用请求网络的访问速度？

7、lib库里面访问网络使用的是哪个网络库？ json库用的是哪个？

8、使用该网络库会给我的app带来多大的体积增加？

9、lib库的配置必须要通过修改源代码的方式来进行配置么？

10、缓存domain记录是存储成文件还是数据库，或者android内部的一些存储方式？

11、 评估模块有什么功能？

12、速度插件具体算法？

13、优先级插件又是什么？

14、历史成功次数插件是什么？ 历史错误次数插件是什么？

15、最后一次成功时间？

16、评估插件就这五个吗？

17、智能评估一定会带来好的效果吗？

18、我可以不使用智能评估模块么？

19、该Lib库块兼容性如何？

Q&A

Q1、每次请求url都需要去ping么？

Q2、前面提到的并发请求，被丢弃的请求是怎么处理的

Q3、南北网络之间请求有特别处理么？

Q4、用dnspod是用的他的接口么？如果dnspod上是配置的是cname，会递归解析出最终的ip缓存下来么？

Q5、数据库中记录的是cname，还是cname解析出的ip？

Q6、那cname的情况下，httpdns就起不到实际的作用了？

Q7、我们遇到的问题是主域名解析没问题，cname的域名是amazon aws的域名，经常莫名其妙解析不通，怀疑是运营商搞鬼。当时也想自己做这个httpdns，但发现很麻烦，小厂没人力搞这个事情。

想与高可用架构微信群内专家继续讨论DNS高可用话题，请关注公众号后，回复“arch”申请进群。

一、问题根源：

1、域名缓存：

2、解析转发：

3、LocalDNS递归出口NAT：

二、现有的解决方案及存在的问题：

1、实时监控+商务推动：

2、绕过自动分配DNS，使用114dns或Google public DNS：

3、完全抛弃域名，自建connectcenter进行流量调度：

三、利用HttpDNS解决用户域名解析异常：

5、lib库目前只能使用 dnspod 服务商么？支持dnspod 企业版本么？

11、评估模块有什么功能？

14、历史成功次数插件是什么？历史错误次数插件是什么？