1
tvvocold 2014-11-13 09:44:59 +08:00
能不能翻?
|
2
mywaiting 2014-11-13 09:50:24 +08:00
实质上还是要通过DNS query的过程吧。如果是单单针对mobile端,其实可以这样,什么DNS query都不用了:
通过当前的位置自动连接内置的对应地区的服务器IP列表,此IP列表搞成可动态更新形式的,每次连上服务器就会自动更新,这样就不用饶个大弯去请求什么HttpDNS了,完全多此一举。 |
3
est 2014-11-13 09:52:35 +08:00 2
就一个 $ curl http://ip138.com/ 还可以包装那么多东西。哈哈。
|
4
mywaiting 2014-11-13 09:56:44 +08:00
另外腾讯自己怎么不搞个public DNS?我想到的是,在指责别人缓存DNS的时候,为什么自己不用自己庞大的基础设施干点什么?
|
6
tomliu 2014-11-13 09:59:53 +08:00
和我厂的撞名了
|
8
abelyao 2014-11-13 10:03:51 +08:00
首先鹅厂这个思路其实挺好的,支持创新(创意是否原创不知,但至少付出实践应用了值得肯定)。
然后… 这套东西的效果就是今年微信好几次断网么? |
9
millken 2014-11-13 10:11:47 +08:00
对于app类有帮助,对于web则无效。
|
12
wdlth 2014-11-13 10:19:58 +08:00
运营商DNS不支持edns-client-subnet,然后就想出这么个蛋疼的东西……
|
13
iLiberty 2014-11-13 10:24:37 +08:00
http://dns.weixin.qq.com
用的就是这个吧 |
14
mywaiting 2014-11-13 10:34:32 +08:00
@abelyao 那好吧,我没有统计。我混的圈子窄,都是程序员的圈子,不懂QQ用户群。也不是可以想跟你争辩什么,我只是想说腾讯怎么不自己搞个public DNS的吧。至于用不用,这个,我真的不知道。
|
15
zhujinliang 2014-11-13 10:46:11 +08:00
@mywaiting dnspod不已经是腾讯的了么
|
16
zhujinliang 2014-11-13 10:47:07 +08:00
@mywaiting 啊不对。。。不是一回事。。。
|
18
darcy 2014-11-13 10:58:38 +08:00
既然是在移动app里使用,都已经通过http下发ip了,就没必要跟DNS扯上关系了,叫discover server更合适一些。
而且只能自家使用,无法开放成公共的服务,把一个简单的问题复杂化了。 |
19
c0878 2014-11-13 11:03:32 +08:00
很好的方案 不过bgp anycast也就腾讯这种级别能搞定吧 小厂商还是得靠DNS
|
20
zhouzm 2014-11-13 11:08:20 +08:00
|
22
FrankFang128 2014-11-13 11:29:27 +08:00
把域名去掉了……很多东西都依赖域名的呀。
|
24
invite 2014-11-13 11:40:35 +08:00
没看明白,其他应用如何使用这个?要修改所有应用?现在的应用应该直接调用操作系统接口的吧,难道在操作系统和应用之间添加一层适配层?
而且,一个HTTP的DNS请求,比直接DNS请求的流量,增加了多少个百分点?这个流量费用谁来支付? 阅读以后,还发现如下问题: 1、文中提到的BGP AnyCast,不知道这个基于TCP的HTTP协议,如何稳定的使用AnyCast? 2、文中还提到,A、根治域名解析异常:由于绕过了运营商的LocalDNS,用户解析域名的请求通过Http协议直接透传到了腾讯的HttpDNS服务器IP上,用户在客户端的域名解析请求将不会遭受到域名解析异常的困扰。 这个简直是拍脑袋,你HTTP本身的请求怎么发起?难道不需要经过DNS解析?如果需要过运营商解析,人家DNS能劫持,HTTP就不能劫持了? |
25
oott123 2014-11-13 11:43:16 +08:00 via Android
对小厂来说,如何确定 HttpDNS 要访问的 IP 是个麻烦的问题…当然对于腾讯不存在这个问题就是了。
不然我们搞个用其它的方案用来解析 HttpDNS 要访问的 IP ? :P |
26
mornlight 2014-11-13 11:44:39 +08:00
@mywaiting 哪有什么大佬。原文把pulicDNS存在的问题都说了,再扯DNS的事就有些无聊,那些问题不是有个自己的DNS就可以解决掉的。
|
28
blijf 2014-11-13 11:48:07 +08:00
该不该剁手呢 XD |
31
typcn 2014-11-13 11:53:06 +08:00
这种解析我早就想过了,是想逃过某墙检测。HttpDNSProxy 然后给设备用,又想了想这样还很慢,要是 Private DNS 还不如直接建立一个长连接两边 emit
|
35
hitsmaxft 2014-11-13 11:55:22 +08:00
关键字 运营商劫持, 能解决这个就是个大好事.
|
36
abelyao 2014-11-13 11:57:09 +08:00
@blijf 这是要注册 httpdns.org 吗… 貌似有站啊
|
41
hedaode 2014-11-13 12:14:44 +08:00
114DNS的这个HttpDns解析接口貌似访问不了呀! http://114.114.114.114/d?dn=www.google.com
|
44
benjiam 2014-11-13 13:19:17 +08:00
我也没看懂, 用了http 获取 dns,是这样的概念吗? 所有的劫持都存在啊
|
46
crisrock 2014-11-13 16:34:26 +08:00
|
47
benjiam 2014-11-13 17:07:25 +08:00
@zhouzm 用http方式获取了server ip, 这个方案是很早以前 qq空间就说过的。
通过 http访问,获得客户端ip,然后将客户端对应的server ip 返回给客户。 但是只要http结果被缓存了,那么这个问题就还是没有被解决。 |
48
hicdn 2014-11-13 17:14:48 +08:00
@invite 明显没有仔细看文章,第一次的 HTTP 请求是直接连接 IP,这个 IP 做了 BGP anycast,完全用不着 LocalDNS
|
49
BOYPT 2014-11-13 17:19:11 +08:00
@benjiam
用http的方式获取最优服务器IP地址,因为目前的“智能区域DNS”有局限性。 这是在做客户端程序时候的一个解决思路,和现有的操作系统的DNS,或者什么public dns,完全无关的。 |
51
wzxjohn 2014-11-13 17:30:53 +08:00
哈哈哈哈哈哈。。。厂里N久之前的文章发出来被热炒一下。。。
|
53
wzxjohn 2014-11-13 18:30:41 +08:00 via iPhone
@mywaiting 你太天真了,你以为我厂没有自己的公共DNS?现在114的基础设施有一大部分是我厂在运营维护!
然后运营商缓存是绝对无法解决的事情,你把事情看的太简单了。你见过哪个运营商主动给你DHCP推送114.114.114.114么?只要运营商不配合,你建再大的公众DNS都没用。而且,尤其是移动,还会对公众DNS的解析请求进行污染投毒,让你就算用了114也一样得到错误的结果。 |
54
wzxjohn 2014-11-13 18:35:02 +08:00 via iPhone
|
57
benjiam 2014-11-13 20:36:54 +08:00 via iPad
但是如何防止第一次http访问不被ISP缓存呢
|
60
reorx 2014-11-13 21:53:15 +08:00
这个方案手机淘宝很早就在用了,Velocity Conf 上还有过分享,几个月前也和同事自己实现了一套。
|
64
wzxjohn 2014-11-14 08:30:47 +08:00
@invite 我没说反啊。。。我的意思就是因为现在大多数人的DNS都是自动获取的,所以Public DNS用来解决运营商缓存意义不大。
|
65
zhengshuai 2014-11-14 09:10:31 +08:00
HttpDNS大赞,mark之。
|
69
9hills 2014-11-15 18:05:41 +08:00 via iPhone
@invite 文章里有说 anycast 啊,你不会以为google 的8.8.8.8后面只有一台服务器吧。。。
|
71
9hills 2014-11-15 21:54:42 +08:00 via iPhone
@invite udp一台也不行,只有一台机器可用性顶多两个到三个9 话说你还是认为8.8.8.8 后面只有一台?呵呵
|
73
lovejoy 2014-11-16 13:27:48 +08:00
@invite 你在同一个地方连到的后端服务器必然是同一个吧,anycast 难道会随意发到一个后端?这块我不懂,猜测,anycast后面应该不是随机的吧。
|
74
9hills 2014-11-16 13:59:23 +08:00
|
75
9hills 2014-11-16 14:03:28 +08:00
@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." |
76
invite 2014-11-16 16:54:41 +08:00
|
77
9hills 2014-11-16 17:48:13 +08:00 via iPad
|
78
invite 2014-11-17 08:33:29 +08:00
@9hills 跟一个不是搞网络的人说话真的很累。现在不只是单IP的负载均衡问题,而是考虑到运营商的问题,否则上F5啥的谁不会。
|
79
zhicheng 2014-11-20 07:01:04 +08:00
我也是做 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 就是机房遭受核打击都没关系啊,难道微信所有机房的光揽被同时挖断了吗,太巧合了。 |
82
zhicheng 2015-04-01 18:19:12 +08:00
@Viztor 用这种方式防止污染的方法简直是自欺欺人,单纯把 DNS 协议替换成 HTTP 协议,本质上对防止污染没有任何帮助。
|
83
jesse_luo 2015-04-02 03:23:35 +08:00 1
为啥突然被挖坟了……= =
淘宝似乎在2013年也启用类似技术了 |
84
karonl 2015-04-17 19:49:25 +08:00
@jesse_luo 我也突然挖坟了,是因为我看到最近的dnspod https://www.dnspod.cn/httpdns/guide
|
86
stevenc 2016-08-04 20:17:19 +08:00
|
87
stevenc 2016-08-04 20:18:16 +08:00
什么鬼,连续按两次回车就发布了,还没打完。。。
|
88
stevenc 2016-08-04 20:23:50 +08:00
简单说就是:
1 、要求用户更换 DNS 不切实际。 2 、指定 IP 地址访问不切实际。(无法实现分流,要是只有少数几个 IP 地址那倒无所谓) 3 、首次访问先通过 HTTP 返回 IP 地址。(多次一举,这不就是自建 HTTPDNS 吗) HTTPDNS 就相当于是不用改 DNS 的 DNS ,将 DNS 解析结果通过 HTTP 的方式返回。更重要的是,公共 DNS 服务在各地有解析服务,提供的 HTTPDNS 返回的结果不会出现错误递归。 |
89
great2soul 2016-10-03 21:40:42 +08:00
DNS 服务如果做得不好就去做一个更好的 DNS 服务或者督促 DNS 服务商做得更好才是正道吧。这种剑走偏锋的做法不太认同,比如安全性问题。
|
90
zhighest 2016-11-21 13:52:53 +08:00
过段时间要换成 HttpsDNS 。。。
|