腾讯的 GSLB 新思路HttpDNS

能不能翻？

实质上还是要通过DNS query的过程吧。如果是单单针对mobile端，其实可以这样，什么DNS query都不用了：

通过当前的位置自动连接内置的对应地区的服务器IP列表，此IP列表搞成可动态更新形式的，每次连上服务器就会自动更新，这样就不用饶个大弯去请求什么HttpDNS了，完全多此一举。

就一个 $ curl http://ip138.com/ 还可以包装那么多东西。哈哈。

另外腾讯自己怎么不搞个public DNS？我想到的是，在指责别人缓存DNS的时候，为什么自己不用自己庞大的基础设施干点什么？

@mywaiting 文章中有说到吧，自己弄个 DNS 当然没问题，问题是怎么让用户都换成你的 Public DNS 呢？

和我厂的撞名了

@est 没这么简单吧，GSLB 还有包括了企鹅内在的调度，所以控制能力要稍强。

首先鹅厂这个思路其实挺好的，支持创新（创意是否原创不知，但至少付出实践应用了值得肯定）。
然后… 这套东西的效果就是今年微信好几次断网么？

对于app类有帮助，对于web则无效。

@abelyao 那我们为什么都换114和Google的？我觉得，好用吧，自然就越来越多的用户吧。这个过程急不来的吧。

@mywaiting 你们换了，不代表所有人都换，对于使用QQ服务的用户群来说，到底有百分之几的人换了，你给个统计？

运营商DNS不支持edns-client-subnet，然后就想出这么个蛋疼的东西……

http://dns.weixin.qq.com
用的就是这个吧

@abelyao 那好吧，我没有统计。我混的圈子窄，都是程序员的圈子，不懂QQ用户群。也不是可以想跟你争辩什么，我只是想说腾讯怎么不自己搞个public DNS的吧。至于用不用，这个，我真的不知道。

@mywaiting dnspod不已经是腾讯的了么

@mywaiting 啊不对。。。不是一回事。。。

@mywaiting 感觉你根本没看懂文章

既然是在移动app里使用，都已经通过http下发ip了，就没必要跟DNS扯上关系了，叫discover server更合适一些。
而且只能自家使用，无法开放成公共的服务，把一个简单的问题复杂化了。

很好的方案 不过bgp anycast也就腾讯这种级别能搞定吧 小厂商还是得靠DNS

@darcy 文章里提了，114 也推出了 HttpDNS

用 http 实现了原来 dns 的一部分目的, 名称和 DNS 带点关系也无妨

@mornlight 好吧，大佬讲我没有看懂那我就是不懂咯.....泪奔.........

把域名去掉了……很多东西都依赖域名的呀。

@zhouzm 嗯，刚去看了，的确提供了一个API；你会在什么情况下使用这种dns http proxy?

没看明白，其他应用如何使用这个？要修改所有应用？现在的应用应该直接调用操作系统接口的吧，难道在操作系统和应用之间添加一层适配层？

而且，一个HTTP的DNS请求，比直接DNS请求的流量，增加了多少个百分点？这个流量费用谁来支付？


阅读以后，还发现如下问题：


1、文中提到的BGP AnyCast，不知道这个基于TCP的HTTP协议，如何稳定的使用AnyCast？

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

这个简直是拍脑袋，你HTTP本身的请求怎么发起？难道不需要经过DNS解析？如果需要过运营商解析，人家DNS能劫持，HTTP就不能劫持了？

对小厂来说，如何确定 HttpDNS 要访问的 IP 是个麻烦的问题…当然对于腾讯不存在这个问题就是了。
不然我们搞个用其它的方案用来解析 HttpDNS 要访问的 IP ？ :P

@mywaiting 哪有什么大佬。原文把pulicDNS存在的问题都说了，再扯DNS的事就有些无聊，那些问题不是有个自己的DNS就可以解决掉的。

@invite 估摸着是做两次dns。第一次由本地解析出他的服务地址，第二次由他的服务来跳转到目标机器。

该不该剁手呢 XD

@invite HTTP请求为什么必须需要经过DNS解析？

@typcn 哦，看来你都直接记住服务器IP地址的。

这种解析我早就想过了，是想逃过某墙检测。HttpDNSProxy 然后给设备用，又想了想这样还很慢，要是 Private DNS 还不如直接建立一个长连接两边 emit

@blijf 要9.19啊？没有优惠码的么？

@invite 为什么不能放一个静态IP地址专门用于获取解析？

@invite 貌似优惠码只能用一次

关键字 运营商劫持, 能解决这个就是个大好事.

@blijf 这是要注册 httpdns.org 吗… 貌似有站啊

@typcn 那你觉得这个静态IP的服务器，得怎么放？就1个节点？那怎么提高访问速度？

@invite bgp + 客户端内置IP列表

@abelyao registered

@blijf 竟然是刚注册的，好样的，到时有免费服务的话记得通知一下

114DNS的这个HttpDns解析接口貌似访问不了呀！ http://114.114.114.114/d?dn=www.google.com

@hedaode 需翻

@typcn BGP ? 基于TCP握手的交互的，能保证数据发送到你那个服务器上？谁给你做TCP会话保持啊？

我也没看懂， 用了http 获取 dns，是这样的概念吗？ 所有的劫持都存在啊

@benjiam http 方式获得 server ip，代替了 dns

https://github.com/yinqiwen/httpdns
是这个东西吗

@zhouzm 用http方式获取了server ip, 这个方案是很早以前 qq空间就说过的。
通过 http访问，获得客户端ip,然后将客户端对应的server ip 返回给客户。

但是只要http结果被缓存了，那么这个问题就还是没有被解决。

@invite 明显没有仔细看文章，第一次的 HTTP 请求是直接连接 IP，这个 IP 做了 BGP anycast，完全用不着 LocalDNS

@benjiam
用http的方式获取最优服务器IP地址，因为目前的“智能区域DNS”有局限性。
这是在做客户端程序时候的一个解决思路，和现有的操作系统的DNS，或者什么public dns，完全无关的。

你们为何这么吊，httpdns的 org,cn,com.cn 域名都在上午被注册了

哈哈哈哈哈哈。。。厂里N久之前的文章发出来被热炒一下。。。

@wzxjohn 是啊。来自大公司内部的技术分享，总是可以开拓思路的。

@mywaiting 你太天真了，你以为我厂没有自己的公共DNS？现在114的基础设施有一大部分是我厂在运营维护！
然后运营商缓存是绝对无法解决的事情，你把事情看的太简单了。你见过哪个运营商主动给你DHCP推送114.114.114.114么？只要运营商不配合，你建再大的公众DNS都没用。而且，尤其是移动，还会对公众DNS的解析请求进行污染投毒，让你就算用了114也一样得到错误的结果。

@abelyao 微信断网跟这有啥关系。。。光纤被挖断你有办法？
@Livid 确实能开拓思路，但是用起来还有一定的问题。其实这套方案最初我记得就是用在移动端，因为移动端的DNS解析真的非常耗时，但是把IP写死就更不科学，所以退而求其次，用这种方式来获得服务端的地址。其实我们还有另一套方案在另一个领域解决类似的问题。。。

@invite DNS是写死IP的。。。你见过系统里填DNS的时候写域名么。。。

@wzxjohn 呵呵

但是如何防止第一次http访问不被ISP缓存呢

@wzxjohn 加油：）

@mywaiting 不明白你在加油什么。。。我在纠正你的错误。。。

这个方案手机淘宝很早就在用了，Velocity Conf 上还有过分享，几个月前也和同事自己实现了一套。

@benjiam DNS Over HTTPS 233

@wzxjohn 你说反了吧，DNS是自动获取的吧，特别手机。你见过几个人的手机，是自己配置DNS的？

@hicdn 你明显没有看我的回复，BGP AnyCast的时候，如何保证TCP数据发往同一个服务器？

@invite 我没说反啊。。。我的意思就是因为现在大多数人的DNS都是自动获取的，所以Public DNS用来解决运营商缓存意义不大。

HttpDNS大赞，mark之。

@reorx 这个方案最关键的一点 是IP库。IP库不准等于白搭

@invite 你在移动，还能把数据发到电信服务器上去？

@hicdn 难道你只在移动部署一个节点？

@invite 文章里有说 anycast 啊，你不会以为google 的8.8.8.8后面只有一台服务器吧。。。

@9hills 哥, 8.8.8.8 UDP的. 一个请求一个应答就够了, TCP需要多个请求......

@invite udp一台也不行，只有一台机器可用性顶多两个到三个9 话说你还是认为8.8.8.8 后面只有一台？呵呵

@9hills 关键不是台数懂了么? 关键是多个TCP请求能指向同一个服务器的问题.

@invite 你在同一个地方连到的后端服务器必然是同一个吧，anycast 难道会随意发到一个后端？这块我不懂，猜测，anycast后面应该不是随机的吧。

@invite Google "TCP anycast"，这个早就有了。。。

另外8.8.8.8 也支持TCP over DNS的。。不还是一个IP？

@lovejoy

@invite
@lovejoy 来篇PDF： https://www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf

人民群众的创造力是无穷的。引用pdf的一句话：

"Stop telling people anycast doesn’t work for
TCP if you haven’t tested it, it just makes us
mad."

@9hills 没有说TCP不行, 得看你怎么运作, 而且很大程度上取决于运营商(当然, 如果你只跟一个运营商保留一条连接, 那么就随你了.). 如果一个方案需要由运营商来决定, 那么这个方案肯定是有缺陷的.
@lovejoy 首先, 你的AS跟其他AS相连, 肯定不会只有一条, 这个情况下, 运营商有可能会通过多条连接发送同一个会话里的不同数据包.

@invite 我不知道你在尝试表达什么，在我看来你第一次回复的疑问全部得到了解答。。。

另外单IP做负载均衡不止Anycast一种方法。。。

@9hills 跟一个不是搞网络的人说话真的很累。现在不只是单IP的负载均衡问题，而是考虑到运营商的问题，否则上F5啥的谁不会。

我也是做 DNS 的，说两句。

TCP 是可以运行在 Anycast 上的。前提是每个 /24 段不能承载过多的业务。节点都比较稳定，不会经常因为负载过高而重新route。这也是为什么 Anycast 大多用在 DNS 和 CDN 这种单纯流量的简单业务上。

我理解原文中的含义大概是，client 本地存储一个 Anycast IP 。在需要解析的时候，向这个 Anycast IP 发送一个带有解析消息的 HTTP 的请求，HTTP 会返回一组解析后的 IP 。

这样肯定可以工作，但我有几个问题。
一，这种方式肯定没有办法在浏览器上运行。但如果是 client ，那为什么不直接向 Anycast IP 发送 DNS 请求？
二，用了 Anycast ，就不需要 IP 库了。
三，最简单的办法，难道不是 301 + subdomain 吗。
四，既然每次请求多发送一次 HTTP 的成本都能承受得起，干脆把 records 的 ttl 设成 10 好了。
五，用了 Anycast 就是机房遭受核打击都没关系啊，难道微信所有机房的光揽被同时挖断了吗，太巧合了。

@invite 用IP发起吖。。

@zhicheng 本身的目的就是为了防止DNS污染，怎么能再去用域名系统呢。。。

@Viztor 用这种方式防止污染的方法简直是自欺欺人，单纯把 DNS 协议替换成 HTTP 协议，本质上对防止污染没有任何帮助。

为啥突然被挖坟了……= =

淘宝似乎在2013年也启用类似技术了

@jesse_luo 我也突然挖坟了，是因为我看到最近的dnspod https://www.dnspod.cn/httpdns/guide

@karonl dnspod就是鹅厂吧

@invite @zhicheng 你们对 HTTPDNS 要解决的问题一无所知，还扯淡！

APP 域名解析主要面临以下几个问题：

1 、解析被劫持。
2 、解析结果不按 TTL 缓存。
3 、解析被错误递归（跨地区甚至跨运营商）。

直接导致解析过慢、出错、无法正确分流等等。

可以考虑的解决方式：

1 、要求用户更换你认为可靠的 DNS 。
不切实际，哪怕腾讯有自己的 119.29.29.29 解析服务也不可能要求每个用户用腾讯产品之后先更换成腾讯的 DNS 地址。

2 、直接使用 IP 地址访问。

3 、 HTTPDNS 可以实现精确流量调度。

什么鬼，连续按两次回车就发布了，还没打完。。。

简单说就是：

1 、要求用户更换 DNS 不切实际。
2 、指定 IP 地址访问不切实际。（无法实现分流，要是只有少数几个 IP 地址那倒无所谓）
3 、首次访问先通过 HTTP 返回 IP 地址。（多次一举，这不就是自建 HTTPDNS 吗）

HTTPDNS 就相当于是不用改 DNS 的 DNS ，将 DNS 解析结果通过 HTTP 的方式返回。更重要的是，公共 DNS 服务在各地有解析服务，提供的 HTTPDNS 返回的结果不会出现错误递归。

DNS 服务如果做得不好就去做一个更好的 DNS 服务或者督促 DNS 服务商做得更好才是正道吧。这种剑走偏锋的做法不太认同，比如安全性问题。

过段时间要换成 HttpsDNS 。。。