dns现状分析问题1:有利可图的dns劫持#
要说httpdns为什么会出现，那么，首先，现在的dns解析有什么问题？
dns怎么了？只是你输入一个域名xxx.com，dns服务器递归获取xxx.com后面的ip。似乎对人畜无害。
但是，如果我是负责维护某运营商dns服务器的技术人员，手头缺钱，我可能会想，有没有可能赚点画画的钱？
例如，假设xxx.com的网站非常受欢迎，每天都有很多人访问它，那么我可以这样做。xxx.com进行dns查询，本该返回的ip是1.1.1.1。我呢，就把手里另一个服务器的ip还回去。然后，如果用户以后访问xxx.com，他们将访问我手中的2.2.2.2。我的2.2.2.2服务器充当反向代理，将用户的请求转发给1.1.1.1，然后将1.1.1.1的响应转发回用户。用户不知道它的流量被劫持了，所以必须从我的2.2.2.2进行。似乎没人知道。
这个时候，如果我想赚钱，可以去找一个广告谈合作。谁付费多，我就:在转发1.1.1.1对用户的回应时，加点广告。用户只要打开xxx.com，就会被强制播放广告。我呢，可以等广告商给我送钱。
以上是dns劫持最简单的例子。看完之后，不要觉得我好像可以。首先你得进入运营商公司，掌握相关服务器；其次，现在很多流量都是https域名，https的防篡改功能还是很强的。所以基本上来说，你劫持就劫持，你改变不了我的流量，所以你很难添加广告，所以你还是可以阻止这种广告的。
我搜了一下dns劫持，发现这个行业真的很残酷，很赚钱，适合喜欢提毕业包的程序员找新工作。
dns解析状态的问题2:不准确的调度#
上一篇文章，关于gslb，提到了以下几点:
依靠运营商来帮助我们进行dns解析可能并不可靠。例如，我们需要将xxx.com解析到我们在深圳和北京的两个机房。一般来说，我们期望根据用户所在地区返回最近的地址。比如广东用户会返回深圳xxx.com机房的地址，北京用户会给出北京机房的地址。或者在dns运营商这边，也支持根据用户的运营商路由进行解析。
但是，总的来说，这个分析掌握在别人手里。他要是靠谱就好了。如果他那边的分析不靠谱，那就有大问题了。比如一个广东用户给你一个北京机房的地址，你说用户要卡在你的网站上，体验就完全没用了。
httpdns #的定义
定义#
Dns劫持，发生在dns解析过程中，一般采取udp协议；Dns解析无非是获取xxx.com背后的ip。可以自己开发一个服务，对外提供一个http接口吗？接口的作用是接收一个参数，即要查询的域名，比如xxx.com；再往后，就是xxx.com对应的ip或者ip列表或者ip列表加上每个ip的负载。
Api请求参数#
按理说我们要自己开发这样一个http服务，但是现在各大云厂商也都做了这个功能，我就直接贴他们的一些资料吧:
比如上面云厂商的对外接口是http://203.107.1.33/xx/d,其中203.107.1.33是一个公有ip，就是这个httpdns服务的对外ip。参数主要是两个:主机和ip。host是你要检查的域名，ip是客户端的ip。所以这个接口模拟了dns服务器的dns查询功能。
这里还有两个请求的例子:
示例:http://203.107.1.33/100000/d主机= www.xxx.com
例如:http://203.107.1.33/100000/d主机= www.xxx.com IP = 42.120.74.196
Api响应参数#在云厂商的网站上，还介绍了响应体的格式:
Copy{"host":"www.xxx.com "，" ips":[ "140.205.140.234"]，" IPS V6 ":[" 2400:3200:1300:0:0:0:0:3e "]，" ttl":57，" origin_ttl":120}
可以看到，ips也支持返回多个。假设我们自己实现了这个api，类似于上面的api。在ip端，我们可能会有更多的想法，比如将每个IP的当前状态返回给客户端，客户端可以遵循一些策略，比如选择负载最低的那个；
我觉得云厂商只还ip。毕竟他们不可能对我们的每一个ip都有更多的了解。云厂商的做法大概是:
根据你参数里要查的域名，xxx.com，去dns系统查一下后面的真实ip地址，比如1.1.1.1，2.2.2.2。
根据客户端的ip，判断返回xxx.com的ip是在京还是在深；另外我看到云厂商也支持你写一段代码给你定制你的策略。
回答问题#
主要缺陷#
它只适合有客户端的场景。可以看到，这个方案需要查询httpdns服务，才能得到真实的IP；这需要通过在客户端编码来实现。
这种B/S的场景是没有办法的，浏览器不支持在发起访问前先去httpdns检查真实ip。
httpdns服务为什么直接公开ip#
因为httpdns是为了解决dns劫持的问题，不能自己再设置一层dns。另外，这个ip是必须的，全国的用户都需要足够快的访问这个ip。所以这个ip所在的服务器一般放在BGP机房。BGP机房简单的理解就是各大主流运营商，如中国移动、中国电信、中国铁通、中国网通等。都是直接连到这个机房的。所以各大运营商的用户都可以快速访问这个机房的服务器。
具体的我也不是很懂。我可以这样理解。市场上许多IDC公司都提供数据中心租赁和服务器托管等服务。他们手里的机房也有区别。有一部分可能主要是和电信运营商对接，适合南方用户，北方用户接入慢。有的适合北方用户参观；其他的，就是同时接入很多运营商，各大运营商接入这个机房更快，也就是所谓的BGP机房。
PDHTNS服务如何确保高可用性#
Httpdns服务和我们之前看的云厂商一样，只有一个ip？其实不是的。它部署在该云供应商的许多机房中，具有多个ip。
考虑到服务IP防攻击等安全风险，为了保证服务的可用性，HTTPDNS同时提供多个服务IP。当一个服务IP在非正常情况下不可用时，可以使用其他服务IP重试。上述文件中使用的203.107.1.33是服务IP之一。
HTTPDNS提供Android SDK和iOS SDK。两个平台的SDK已经做了多IP轮换和错误重试的策略。通常情况下，建议开发者直接集成SDK，无需手动调用HTTP API接口。
Httpdns使用http协议进行明文传输，不安全？#然后用https，云厂商也支持。
https://203.107.1.33/{account_id}/d HTTPS服务网址
客户最佳实践#
客户端最好不要依赖这种机制。万一httpdns服务出了问题，我们的app不是完全不能用了吗？这时候可以降级使用传统的dns方案，那就劫持吧。其实概率没那么大；如果传统的dns方案还存在问题，客户端还可以嵌入一些ip，然后选择其中一个嵌入的ip进行访问，这样可以保证高可用性。
云厂商提供了sdk解决方案，也讲解了一些细节。例如，他们通过httpdns获得了一个ip，即1.1.1.1。这时，他们向1.1.1.1发起了一个https服务请求。这时就会出现一个问题:https一般只支持域名访问。这时候用ip访问https服务器就会出现一些问题。
云厂商终究是要赚钱的，这些问题的解决方案都写在他们的文档里。
我觉得我成了一名推销员。其实我说的就是这个httpdns。没有广告费吧？
资料来源:https://www.cnblogs.com/grey-wolf/p/16483121.html
