网络协议私人订制的DNS服务：需要HTTPDNS 吗？ _HTTPDNS

全球统一的 DNS 是很权威，但是我们都知道“适合自己的，才是最好的” 。很多时候，标准统一化的 DNS 并不能满足我们定制的需求，这个时候就需要 HTTPDNS 了。
然而，我们信任的地址簿也会存在指错路的情况。明明离你 500 米就有个吃饭的地方，非要把你推荐到 5 公里外。为什么会出现这样的情况呢？
还记得吗？由我们发出请求解析 DNS 的时候，首先会连接到运营商本地的 DNS 服务器，由这个服务器帮我们去整棵 “DNS 树” 上进行解析，然后将解析的结果返回给客户端。但是本地的 DNS 服务器，作为一个本地导游，往往会有自己的“小心思” 。
传统 DNS 存在的问题1）域名缓存问题
它可以在本地做一个缓存。也就是说，不是每一个请求，它都会去访问权威 DNS 服务器，而是把访问过一次的结果缓存到本地，当其他人来问的时候，直接返回缓存的内容。
这就相当于导游去过一个饭店，自己记住了地址，当有一个游客问的时候，他就凭记忆回答了，不用再去查地址簿。这样会存在一个问题，游客问的那个饭店如果已经搬走了，然而因为导游没有刷新“记忆缓存”，导致游客白跑一趟。
另外，有的运营商会把一些静态页面，缓存到本运营商的服务器内，这样用户请求的时候，就不用跨运营商进行访问，既加快了速度，也减少了运营商直接流量计算的成本。也就是说，在域名解析的时候，不会将用户导向真正的网站，而是指向这个缓存的服务器。
缓存的问题，很多情况下是看不出问题的，但是当页面更新，用户访问到老的页面，问题就出来了。
再就是本地的缓存，往往使得全局负载均衡失败。上次进行缓存的时候，缓存中的地址不一定是客户此次访问离客户最近的地方，如果把这个地址返回给客户，就会让客户绕远路了。
2）域名转发问题
还记得我们域名解析的过程吗？捂脸是本地域名解析，还是去权威 DNS 服务器中查找，都可以认为是一种外包形式。有了请求，直接转发给其他服务去解析。如果转发的是权威 DNS 服务器还好说，但是如果因为“偷懒”转发给了邻居服务器去解析，就容易产生跨运营商访问的问题。
这就好像，如果 A 运营商的客户，访问自己运营商的 DNS 服务器，A 运营商去权威 DNS 服务器查询的话，会查到客户的 A 运营商的，返回一个部署在 A 运营商的网站地址，这样针对相同运营商的访问，速度就会快很多。
但是如果 A 运营商偷懒，没有转发给权威 DNS ，而是转发给了 B 运营商，让 B 运营商再去权威 DNS 服务器查询，这样就会让权威服务器误认为客户是 B 运营商的，返回一个 B 运营商的服务器地址，导致客户每次都要跨运营商访问，访问速度就会慢下来。
3）出口 NAT 问题
前面了解网关的时候，我们知道，出口的时候，很多机房都会配置 NAT，也就是网络地址转换，使得从这个网关出去的包，都换成新的 IP 地址。
这种情况下，权威 DNS 服务器就没办法通过请求 IP 来判断客户到底是哪个运营商的，很有可能误判运营商，导致跨运营商访问。
4）域名更新问题
本地 DNS 服务器是由不同地区、不同运营商独立部署的。对域名解析缓存的处理上，实现策略也有区别。有的会偷懒，忽略域名解析结构的 TTL 时间限制，在权威 DNS 服务器解析变更的时候，解析结果在全网生效的周期非常漫长。但是有的场景，在 DNS 的切换中，对生效时间要求比较高。
例如双机房部署的是，跨机房的负载均衡和容灾多使用 DNS 来做。当一个机房出问题之后，需要修改权威 DNS，将域名指向新的 IP 地址。但是如果更新太慢，很多用户都会访问一次。
5）解析延迟问题
从 DNS 的查询过程来看，DNS 的查询过程需要递归遍历多个 DNS 服务器，才能获得最终的解析结果，这带来一定的延时，甚至会解析超时。
上面总结了 DNS 的五个问题。问题有了，总得有解决办法，就像因为 HTTP 的安全问题，才火了 HTTPS 协议一样，对应的，也有 HTTPDNS 来解决上述 DNS 出现的问题。
HTTPDNS什么是 HTTPDNS ？其实很简单：

HTTPDNS 是基于 HTTP 协议和域名解析的流量调度解决方案。它不走传统的 DNS 解析，而是自己搭建基于 HTTP 协议的 DNS 服务器集群，分布在多个地点和多个运营商。当客户端需要 DNS 解析的时候，直接通过 HTTP 请求这个服务器集群，得到就近的地址。

这就相当于每家基于 HTTP 协议，自己实现自己的域名解析，做一个自己的地址簿，而不使用统一的地址簿。但是我们知道，域名解析默认都是走 DNS 的，因而使用 HTTPDNS 需要绕过默认的 DNS 路径，也就不能使用默认的客户端。**使用 HTTPDNS 的，往往是手机应用，需要在手机端嵌入支持 HTTPDNS 的客户端 SDK 。