这是一个创建于 3657 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
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 。。。
|
Select Language