DNS support edns-client-subnet
https://www.tuicool.com/articles/FV7VRnY
看了2天RFC，终于让DNS支持edns-client-subnet协议，通过google dns resolver的请求，可以获取用户的ip地址。国内很多CDN和DNS提供商都已经实现了，但网上的中文资料比较少，所以在这里分享一下，能力有限，错误之处还请谅解。
问题
CDN使用DNS获取查询IP，根据IP对用户进行地域调度。但这里获取的IP地址是DNS地址，而不是用户真实的IP地址。
大多数情况下，我们假设用户通过会使用离自己网络最近的DNS resolver，CDN调度基本还是准确的。
但也有很多nameserver设置错误，或者用户使用google public dns（nameserver 8.8.8.8/8.8.4.4）或opendns进行DNS resolver
比如：
国内用户设置nameserver 8.8.8.8 (dig xxx.com @8.8.8.8)
我们得到的DNS query IP是74.125.16.208，判断IP属于 美国,,,加利福尼亚州山景市谷歌公司
这个时候，我们的DNS会返回离美国加州最近的CDN节点IP给用户。
国内用户错误的调度到美国节点……
edns-client-subnet
google提交了一份 DNS扩展协议 ，允许DNS resolver传递用户的ip地址给authoritative DNS server.
CDN的DNS支持该协议，就可以获取用户真实的IP地址，进行准确的调度。
OpenDNS和Google Public DNS已经支持了该协议，如果希望他们的query中带有用户IP，需要联系他们添加白名单。提供nameserver的hostname、ip以及可以用来测试解析的域名即可，一般几天就可以搞定。（注：我是晚上22:l00提交的申请，第二天10:00就已经生效了）
实现
一. 支持发送和接收edns-client-subnet的dig
先下载bind， 下载地址
下载edns-client-subnet dig patch， 下载地址
下载上述2个包，将patch打进bind，编译出dig进行测试：
./digwww.baidu.com @8.8.8.8 +client=104.119.200.200
; «» DiG 9.7.3 «» www.baidu.com @8.8.8.8 +client=104.119.200.200
;; global options: +cmd
;; Gotanswer:
;; -»HEADER«- opcode: QUERY, status: NOERROR, id: 1068
;; flags: qrrdra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPTPSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; CLIENT-SUBNET: 104.119.200.200/32/0
;; QUESTIONSECTION:
;www.baidu.com. IN A
;; ANSWERSECTION:
www.baidu.com. 1030 IN CNAME www.a.shifen.com.
www.a.shifen.com. 130 IN A 220.181.112.143
www.a.shifen.com. 130 IN A 220.181.111.148
;; Querytime: 42 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: WedJun 26 14:38:13 2013
;; MSGSIZE rcvd: 113
注意上面的OPT PSEUDOSECTION ，已经可以发送和接收edns-client-subnet请求了
二. 协议
DNS协议
DNS query会包含header和RR 2部分，这里只介绍我们关注地方，网上可以搜到很多协议的介绍，比如这个http://archercai.blog.sohu.com/60779796.html
header会描述本次请求中Questions、Answer RRs、Authority RRs和Additional RRs的数量，RR部分会详细描述每个资源的内容，所有的RR格式是相同的，如下：
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+
| |
/ /
/ NAME /
| |
+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+
| TYPE |
+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+
| CLASS |
+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+
| TTL |
| |
+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+
| RDLENGTH |
+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–|
/ RDATA /
/ /
+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+
个人理解edns-client-subnet是对edns协议的扩展，附加在一个DNS请求的Additional RRs区域，这里 重点描述edns-client-subnet的结构
EDNS协议 Extension mechanisms for DNS (EDNS0）：http://tools.ietf.org/html/draft-ietf-dnsind-edns0-01
EDNS0每个字段的结构和描述如下：
FieldName FieldType Description
——————————————————
NAME domainname empty (rootdomain)
TYPE u_int16_t OPT
CLASS u_int16_t sender’s UDP payload size
TTL u_int32_t extended RCODE and flags
RDLEN u_int16_t describes RDATA
RDATA octet stream {attribute,value} pairs
OPT 的值41，详细的协议值如下：
(A, NS, MD, MF, CNAME, SOA, MB, MG, MR, NULL, WKS, PTR, HINFO, MINFO, MX, TXT,
RP, AFSDB) = range(1, 19)
AAAA = 28
SRV = 33
NAPTR = 35
A6 = 38
DNAME = 39
SPF = 99
OPT = 41
RDLENGTH描述RDATAD的长度，edns-client-subnet的详细格式存在RDATA中，如下：
+0 (MSB) +1 (LSB)
+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+
0: | OPTION-CODE |
+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+
2: | OPTION-LENGTH |
+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+
4: | FAMILY |
+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+
6: | SOURCENETMASK | SCOPENETMASK |
+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+
7: | ADDRESS… /
+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+—+
OPTION-CODE： 2个字节
OPTION-LENGTH： 2个字节，描述它之后的内容长度(BYTE)
FAMILY： 2个字节，1表示ipv4, 2表示ipv6
ADDRESS： 实际存放IP地址的地方，ipv4长度为4，google发送过来的长度一般为3，隐藏了ip地址最后一位
三. 开发
完成前2个步骤，就可以开搞了，逻辑很简单：
判断dns query是否包含Additional RRs，读取NAME部分
读取10个字节(byte)，判断TYPE是否为41，rdlength > 8
如果rdlength > 8，再读取8个字节，对应OPTION-CODE(2)–>OPTION-LENGTH(2)–>FAMILY(2)–>SOURCE NETMASK(1)–>SCOPE NETMASK(1)
读取剩下的address，长度 rdlength – 8 或者 option-length – 4都行
注：读取到的地址长度为4，可以用socket.inet_ntoa变成ip地址，如果不够4个字节，需要后面补\x00
获取到的IP地址就可以用来进行判断调度了
respond时也需要增加一个Additional RRs区域，直接把请求的Additional内容发过去就可以( 如果支持source netmask，将请求中的source netmask复制到scope netmask中 ，OpenDNS要求必须支持scope netmask)
四. 抓包
发包
发送dns query请求时，可以看到Questions:1, Additional RRs: 1
Additional RRs中，type: 41(OPT), rdlength: 12 (google发过来的包，长度为11，没有IP地址最后一位)
12 – OPTION-CODE(2) – OPTION-LENGTH(2) – FAMILY(2) – SOURCE NETMASK(1) – SCOPE NETMASK(1) = 4，IPV4 地址的大小
回包
发送dns query请求时，可以看到Questions:1, Answer RRs:1, Additional RRs: 1
https://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-01
https://blog.51cto.com/369369/812889
网络通讯大部分是基于TCP/IP的，而TCP/IP是基于IP地址的，所以计算机在网络上进行通讯时只能识别如“202.96.134.133”之类的IP地址，而不能认识域名。我们无法记住10个以上IP地址的网站，所以我们访问网站时，更多的是在浏览器地址栏中输入域名，就能看到所需要的页面，这是因为有一个叫“DNS服务器”的计算机自动把我们的域名“翻译”成了相应的IP地址，然后调出IP地址所对应的网页。
什么是DNS？
DNS( Domain Name System)是“域名系统”的英文缩写，是一种组织成域层次结构的计算机和网络服务命名系统，它用于TCP/IP网络，它所提供的服务是用来将主机名和域名转换为IP地址的工作。DNS就是这样的一位“翻译官”，它的基本工作原理可用下图来表示。
DNS域名称
域名系统作为一个层次结构和分布式数据库，包含各种类型的数据，包括主机名和域名。DNS数据库中的名称形成一个分层树状结构称为域命名空间。域名包含单个标签分隔点，例如：im.qq.com。
完全限定的域名 (FQDN) 唯一地标识在 DNS 分层树中的主机的位置，通过指定的路径中点分隔从根引用的主机的名称列表。 下图显示与主机称为 im 内 qq.com DNS 树的示例。 主机的 FQDN 是 im.qq.com。
DNS 域的名称层次结构
DNS域名称空间的组织方式
按其功能命名空间中用来描述 DNS 域名称的五个类别的介绍详见下表中，以及与每个名称类型的示例。
DNS 和 Internet 域
互联网域名系统由名称注册机构负责维护分配由组织和国家/地区的顶级域在 Internet 上进行管理。 这些域名按照国际标准 3166。 一些很多现有缩写，保留以供组织中，以及两个字母和三个字母的国家/地区使用的缩写使用下表所示。一些常见的DNS域名称如下图：
资源记录
DNS 数据库中包含的资源记录 (RR)。 每个 RR 标识数据库中的特定资源。我们在建立DNS服务器时，经常会用到SOA,NS,A之类的记录，在维护DNS服务器时，会用到MX，CNAME记录。
常见的RR见下图：
Dns服务的工作过程
当 DNS 客户机需要查询程序中使用的名称时，它会查询本地DNS 服务器来解析该名称。客户机发送的每条查询消息都包括3条信息，以指定服务器应回答的问题。
● 指定的 DNS 域名，表示为完全合格的域名 (FQDN) 。
● 指定的查询类型，它可根据类型指定资源记录，或作为查询操作的专门类型。
● DNS域名的指定类别。
对于DNS 服务器，它始终应指定为 Internet 类别。例如，指定的名称可以是计算机的完全合格的域名，如im.qq.com，并且指定的查询类型用于通过该名称搜索地址资源记录。
DNS 查询以各种不同的方式进行解析。客户机有时也可通过使用从以前查询获得的缓存信息就地应答查询。DNS 服务器可使用其自身的资源记录信息缓存来应答查询，也可代表请求客户机来查询或联系其他 DNS 服务器，以完全解析该名称，并随后将应答返回至客户机。这个过程称为递归。
另外，客户机自己也可尝试联系其他的 DNS 服务器来解析名称。如果客户机这么做，它会使用基于服务器应答的独立和附加的查询，该过程称作迭代，即DNS服务器之间的交互查询就是迭代查询。
DNS 查询的过程如下图所示。
1、在浏览器中输入www.qq.com域名，操作系统会先检查自己本地的hosts文件是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析。
2、如果hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，如果有，直接返回，完成域名解析。
3、如果hosts与本地DNS解析器缓存都没有相应的网址映射关系，首先会找TCP/ip参数中设置的首选DNS服务器，在此我们叫它本地DNS服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。
4、如果要查询的域名，不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析，此解析不具有权威性。
5、如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后，如果自己无法解析，它就会找一个管理.com域的下一级DNS服务器地址(qq.com)给本地DNS服务器。当本地DNS服务器收到这个地址后，就会找qq.com域服务器，重复上面的动作，进行查询，直至找到www.qq.com主机。
6、如果用的是转发模式，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把转请求转至上上级，以此循环。不管是本地DNS服务器用是是转发，还是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。
从客户端到本地DNS服务器是属于递归查询，而DNS服务器之间就是的交互查询就是迭代查询。
附录：
本地DNS配置转发与未配置转发数据包分析
新建一DNS，具体怎么建我这里就不再描述了，见我的上一篇博文《在Win2003中安装bind【部署智能DNS】》
1、DNS服务器不设转发
在192.168.145.228服务器上安装上wireshark软件，并打开它，设置数据包为UDP过滤，在192.168.145.12客户机上用nslookup命令查询一下www.sohu.com，马上可以看到本地DNS服务器直接查全球13台根域中的某几台，然后一步步解析，通过递代的方式，直到找到www.sohu.com对应的IP为220.181.118.87。
本地DNS服务器得到www.sohu.com的IP后，它把这个IP返回给192.168.145.12客户机，完成解析。
2、DNS服务器设置转发
因www.sohu.com域名在第一步的验证中使用过，有缓存，为了不受上步实验干扰，我们在客户机上192.168.145.12上nslookup www.baidu.com。从图上看，本地DNS把请求转发至192.168.133.10服务器，133.10服务器把得到的IP返回给本地DNS，然后本地DNS再把IP告诉DNS客户机，完成解析。
流量劫持的方式主要分为两种，域名劫持和数据劫持。
域名劫持是针对传统DNS解析的常见劫持方式。用户在浏览器输入网址，即发出一个HTTP请求，首先需要进行域名解析，得到业务服务器的IP地址。使用传统DNS解析时，会通过当地网络运营商提供的Local DNS解析得到结果。域名劫持，即是在请求Local DNS解析域名时出现问题，目标域名被恶意地解析到其他IP地址，造成用户无法正常使用服务。
d05c0f993448ff4171115efec266f62964a30546
传统DNS解析流程
解决域名劫持的一个办法就是绕开Local DNS，通过一个可信的源头来解析域名，解析方式不需要拘泥于DNS协议，也可以通过HTTP的方式。两年前，手机淘宝等APP也曾遇到这一问题，随后在做底层网络优化时，通过使用自己定制的HTTPDNS，一个安全可信的域名解析方案，解决了域名劫持问题。
HTTPDNS技术也准备通过阿里云平台开放给广大开发者使用，当前这款产品正在公测中，将于2016年3月29日提供商业化服务。到时，阿里云上的移动开发者也能自主选择，将需要防劫持的域名进行保护。
数据劫持基本针对明文传输的内容发生。用户发起HTTP请求，服务器返回页面内容时，经过中间的运营商网络，页面内容被篡改或加塞内容，强行插入弹窗或者广告。
行业内解决的办法即是对内容进行HTTPS加密，实现密文传输，彻底避免劫持问题。MD5校验同样能起到防止数据劫持的作用，MD5校验是指内容返回前，应用层对返回的数据进行校验，生成校验值；同时，内容接收方接收到内容后，也对内容进行校验，同样生成校验值，将这两个校验值进行比对，倘若一致，则可以判断数据无劫持。但相比HTTPS加密，MD5校验存在一定风险，劫持方技术能力强则有可能在篡改内容后替换校验值，导致接收方判断错误。
使用HTTPS加密，已经成为了互联网行业的大势所趋。今年双11，阿里的淘宝、天猫、聚划算等电商平台也都全面实现了HTTPS加密访问，全站改造投入巨大，但有效防止了资源被劫持，保障了用户的收发信息安全。未来，这一技术将不仅限于电商平台，还将通过阿里云对外输出，赋能更多的中小互联网企业，降低他们的创业成本，在更安全的移动互联网环境中得到发展。
https://yq.aliyun.com/articles/8656?spm=5176.7947101.220063.10.QVZtBz
https://www.aliyun.com/product/httpdns?spm=a2c4e.11153940.0.0.5a4c4564AJX0oN
但凡使用域名来给用户提供服务的互联网企业，都或多或少地无法避免在有中国特色的互联网环境中遭遇到各种域名被缓存、用户跨网访问缓慢等问题。那么对于腾讯这样的域名数量在10万级别的互联网公司来讲，域名解析异常的情况到底有多严重呢？每天腾讯的分布式域名解析监测系统在不停地对全国所有的重点LocalDNS进行探测，腾讯域名在全国各地的日解析异常量是已经超过了80万条。这给腾讯的业务带来了巨大的损失。为此腾讯建立了专业的团队与各个运营商进行了深度沟通，但是由于各种原因，处理效率及效果均不能达到腾讯各业务部门的需求。除了和运营商进行沟通，有没有一种技术上的方案，能从根源上解决域名解析异常及用户访问跨网的问题呢？
一、问题根源：
要解决问题，我们得先得了解下现在国内各ISP的LocalDNS的基本情况。国内运营商LocalDNS造成的用户访问异常可以归为下三类：
1、域名缓存：
域名缓存很好理解，就是LocalDNS缓存了腾讯的域名的解析结果，不向腾讯权威DNS发起递归，示意图如下：
HttpDNS
为何LocalDNS要把域名解析结果进行缓存呢？原因有以下几个：
（1）保证用户访问流量在本网内消化：国内的各互联网接入运营商的带宽资源、网间结算费用、IDC机房分布、网内ICP资源分布等存在较大差异。为了保证网内用户的访问质量，同时减少跨网结算，运营商在网内搭建了内容缓存服务器，通过把域名强行指向内容缓存服务器的IP地址，就实现了把本地本网流量完全留在了本地的目的。
（2）推送广告：有部分LocalDNS会把部分域名解析结果的所指向的内容缓存，并替换成第三方广告联盟的广告。
这种类型的行为就是我们常说的域名缓存，域名缓存会导致用户产生以下的访问异常：
A、仅对80端口的http服务做了缓存，如果域名是通过https协议或其它端口提供服务的，用户访问就会出现失败。比如支付服务、游戏通过指定端口连接connect server服务等。
B、缓存服务器的运维水平参差不齐，时有出现缓存服务器故障导致用户访问异常的问题。
2、解析转发：
除了域名缓存以外，运营商的LocalDNS还存在解析转发的现象。解析转发是指运营商自身不进行域名递归解析，而是把域名解析请求转发到其它运营商的递归DNS上的行为。正常的LocalDNS递归解析过程是这样的：HttpDNS
HttpDNS
而部分小运营商为了节省资源，就直接将解析请求转发到了其它运营的递归LocalDNS上去了：
HttpDNS
这样的直接后果就是腾讯权威DNS收到的域名解析请求的来源IP就成了其它运营商的IP，最终导致用户流量被导向了错误的IDC，用户访问变慢。
3、LocalDNS递归出口NAT：
LocalDNS递归出口NAT指的是运营商的LocalDNS按照标准的DNS协议进行递归，但是因为在网络上存在多出口且配置了目标路由NAT，结果导致LocalDNS最终进行递归解析的时候的出口IP就有概率不为本网的IP地址：
HttpDNS
这样的直接后果就是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
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服务
http://www.ttlsa.com/web/httpdns-detailed-service/
https://support.dnspod.cn/Kb/showarticle/tsid/216/
https://www.dnspod.cn/
https://www.aliyun.com/product/httpdns?spm=5176.100239.blogcont26413.17.QIg2hk
https://cloud.tencent.com/product/hd
