迫于 IPv6 接口标识足足有 64 位，可否用来做一个真正的 DNS 代理？

[Archeb]

想法是这样的。
1、客户端请求 DNS （例如查询 www.google.com ）
2、DNS 服务器获得 www.google.com 的正确解析结果（如 216.58.219.132 ），记下来
3、DNS 服务器返回一个代理服务器的地址给客户端（如 2001:DB8::1234 ）
4、DNS 服务器告诉代理服务器这个转发请求（如 发送到 2001:DB8::1234 这个地址的流量全部转发到 216.58.219.132 ）
5、实现代理效果

因为 IPv4 的地址稀缺，而 v6 地址的丰富性使得这样的用法成为可能？

不知道以上思路有什么缺点，或者其实已经存在这样的应用（感觉应该有），欢迎指出

[squid157]

NAT64 ?

[noe132]

dns 是有缓存的。

[gy911201]

如果是内网，其实 ipv4 都够用，随便找个内网的网段去做就是了……
实话说，其实用不了多少个 IP ………

[Archeb]

@gy911201 就是公网情况下的...几百个吧要的
@squid157 你这么一说感觉确实其实就是 DNS64 （ NAT64 ）
@noe132 缓存应该和这个不相影响吧...

[jessynt]

Surge for Mac 的 enhanced mode

[jessynt]

[0ZXYDDu796nVCFxq]

2. 直接返回那个 v6 地址
5. 实现代理效果

另外，DNS 不是只有 HTTP 在用，这种进不了 RFC 又涉及到基础设施的，改协议没什么价值，没人跟你玩，除非你把上下游都搞定

[iceheart]

1.你对 IPV6 的认知是错的，IPV6 是 128 位的，不是 64 位
2.你对 DNS 服务器一无所知。DNS 只负责解析名字，它不知道，也没法知道你拿解析到的地址去干啥，返回一个代理对它来说就是错误的解析。
3.你对代理的认知也是错的，代理是指建立在某种协议之上的，不存在对所有协议的代理。我的私有协议就是不支持代理，dns 把我的域名解析到一个代理服务器上，这不是搞事情么

[BOYPT]

除了 #8 的纠错，类似的想法早已经是标准 RFC，俗称称作 DNS64+NAT64，是给纯 ipv6 用户访问只有 v4 地址的服务器的。

草案中已经规定，64:ff9b::/96 地址段是用来映射 ipv4 所有地址成为 ipv6 地址，DNS64 服务器对于 AAAA 请求，发现上有的域名没有 AAAA 记录而只有 A 记录，就把 A 记录的地址转换成 64:ff9b::前缀的 v6 地址作为 AAAA 响应返回。网关上自然也是做好了 NAT64 的转换。

[Archeb]

@iceheart 看清楚 我说 64 位是接口标识 前 64 位是网络前缀
返回的是代理服务器的 ip 地址
好好看帖子

[Archeb]

@BOYPT 确实就是 NAT64 的思路,只不过我觉得一样可以代理 ipv6 和支持大部分协议

[Archeb]

@gstqc 不需要也不想其他人跟我配合,自己搭建 dns 和 代理服务器 即可

[goofool]

为啥不直接跟代理服务器连接

[Archeb]

@goofool 只要客户端支持 ipv6 支持修改 dns 就可以用 无需额外客户端软件
未来 v6 普及了就好

[oovveeaarr]

不对呀，这根 NAT64 不是没差嘛，支持协议的事情不是应该代理服务器自己去做的么。
IPv4 一共就 32 位，IPv6 128 位，所以拿出一个 96，就可以完整映射 IPv4 了，剩下的想怎么搞怎么搞。

[gy911201]

@Archeb 放到公网其实有一个问题，就是你鉴权很难去做……
基本上相当于一个 RBQ 了…………

[Tink]

先不说 ipv6，这不就是自建 dns+sniproxy 实现翻墙的变通么？

[missdeer]

同意 17 楼，IPv4 就有机场这么搞了，自建 DNS+SNIProxy

[Archeb]

@missdeer
@Tink

最多说 dns 部分思路相同
ipv6 下可以一一对应

[Archeb]

@gy911201
同样利用 ipv6 地址足够的特点
给每个用户分配单独的 dns 地址
反正也没法批量扫描