Fake IP

Fake IP 的定义出自 RFC3089；   此RFC 定义了一种新的将 TCP 连接封装成 SOCKS 协议的方法。

  有了 Fake IP，代理客户端无需进行 DNS 解析。最后不论是浏览器、代理客户端还是远端服务器都不会去和 Fake IP 进行连接，因为在代理客户端这里就已经完成了截获、重新封装。

即使按照域名规则分流，代理客户端都没有进行 DNS 解析的需要。只有在遇到了按照 IP 进行分流的规则时，代理客户端才需要进行一次解析拿到一个 IP 用于判断。即便如此，这个 IP 只用于分流规则的匹配，不会被用于实际的连接。

                Client C       Gateway G     Destination D
               +-----------+     (Server)
               |Application|
           +-->+===========+  +-------------+  +-----------+
      same-+   |*SOCKS Lib*|  |  *Gateway*  |  |Application|
       API +-->+===========+  +=====---=====+  +-----------+
               | Socket DNS|  | Socket  DNS |  | Socket DNS|
               +-----------+  +-------------+  +-----------+
               | [ IPv X ] |  |[IPvX]|(IPvY)|  | ( IPv Y ) |
               +-----------+  +-------------+  +-----------+
               |Network I/F|  | Network I/F |  |Network I/F|
               +-----+-----+  +---+-----+---+  +-----+-----+
                     |            |     |            |
                     +============+     +------------+
                       socksified           normal
                       connection         connection
                      (ctrl)+data          data only
                      
    type C ------ G ------ D
           [IPvX]   (IPvY)
     A      IPv4     IPv4       homogeneous (normal SOCKS)
     B      IPv4     IPv6     * heterogeneous *
     C      IPv6     IPv4     * heterogeneous *
     D      IPv6     IPv6       homogeneous

  RFC3089的大概翻译就是：必须获取目的地IP地址信息才能开始通信，然而，从理论上讲，异构通信不可能获得正确的信息，因为现有的IPv4应用程序无法处理IPv6地址，它只准备了一个4字节的地址空间来存储IP地址信息，不能在其中存储IPv6地址信息。这是由地址长度的差异引起的一个关键问题。为了解决这个问题，在基于SOCKS的IPv6/IPv4网关机制中使用了一种称为“DNS名称解析委派”的功能。该功能涉及将源节点（客户端C）上的DNS名称解析操作委托给中继服务器（网关G）。由于中继服务器是IPv4和IPv6双堆栈节点，因此可以对任何地址族类型的目的地进行DNS名称解析查询，而不会导致任何问题。因此，根本不需要修改现有的DNS机制。

  为了解决之前解释的关键问题，在功能中引入了一个适当的“假IP”地址，并将其用作socksified应用程序的虚拟目标IP地址。*Socks Lib*（位于客户端C）中还引入了一个映射表来管理“假IP”和“FQDN”之间的映射。“假IP”地址用作密钥，用于查找相应的“FQDN”信息。映射表是本地的，独立于其他应用程序或它们的*Socks Lib*s。

  就是给你返回一个假的IP地址，而这个假的IP地址作为key，来反向查找你的域名

1. 手机上某个 app 想发出 https://www.google.com 请求
2. app 发出 www.google.com 的 DNS 查询
3. DNS 请求的 UDP 流量来到 tun2socks，被 tun2socks 交到 Fake DNS 模块
4. Fake DNS 模块选择一个伪造的 IP 地址，比如 244.0.0.3，并把这个地址跟 www.google.com 关联起来
5. Fake DNS 根据 DNS 请求，生成相应的 DNS 答复，并把 244.0.0.3 当作 DNS 结果放进答复中，通过 tun2socks 把这个伪造的 DNS 答复返回给 app
6. app 得到 www.google.com 的 DNS 查询结果是 244.0.0.3
7. app 向 244.0.0.3 发出 HTTP 请求流量
8. HTTP 请求流量来到 tun2socks，tun2socks 向 Fake DNS 模块查询目的地址 244.0.0.3 是否是一个伪造的 IP 地址，如果是，向 Fake DNS 查询这个 IP 所关联的 域名，也即 www.google.com
9. tun2socks 现在已经得到 HTTP 请求流量的域名，把流量以及域名一并交给 代理
10. 代理 有了域名，接下来路由什么的该怎么处理就怎么处理了

  一般的 DNS 请求都是用 UDP 发的，但 DNS 的 UDP 报文的大小会被限制在大概 512 字节，如果某个 DNS 答复很长，超过了这个限制，就不能通过 UDP 来传输了，为此 DNS 规范中提出，对于这种超过限制大小的 DNS 请求，DNS 服务器可以在答复中设置一个 flag（truncated），来告诉客户端这个答复太长，你不能用 UDP 来做这个 DNS 请求，请用 TCP，于是客户端就会用 TCP 来重新请求 DNS。

DNS fallback 正是利用了这一点，在 tun2socks 给过来的 UDP 流量中识别出 DNS 请求，然后伪造一个设置了 truncated flag 的答复返回给客户端，客户端就会转用 TCP 来做 DNS 请求了。

DNS 分别在什么情况下使用 UDP 和 TCP

了解了 TCP 面向字节流而 UDP 面向报文的这个特性之后，在域名解析的时候，也就是客户端向 DNS 服务器查询域名获取 IP 地址的时候，DNS 协议关于 UDP 和 TCP 的选择通常可以分为以下两种情况：

1)若客户端事先知道 DNS 响应报文的长度会大于 512 字节，则应当直接使用 TCP 建立连接

2)若客户端事先不知道 DNS 响应报文的长度，一般会先使用 UDP 协议发送 DNS 查询报文，若 DNS 服务器发现 DNS 响应报文的长度大于 512 字节，则多出来的部分会被 UDP 抛弃(截断 TrunCation)，那么服务器会把这个部分被抛弃的 DNS 报文首部中的 TC 标志位置为 1，以通知客户端该 DNS 报文已经被截断。客户端收到之后会重新发起一次 TCP 请求，从而使得它将来能够从 DNS 服务器收到完整的响应报文。

当然了，在域名解析的时候，一般返回的 DNS 响应报文都不会超过 512 字节，用 UDP 传输即可。事实上，很多 DNS 服务器进行配置的时候，也仅支持 UDP 查询包。

不过，DNS 不仅存在域名解析的过程，还有区域传输的过程，而在进行区域传输的时候 DNS 会强制使用 TCP 协议。

什么是区域传输?

这就不得不提一下主域名服务器和辅助域名服务器。

设置域名服务器时，服务器管理员可以选择将域名服务器指定为主服务器还是辅助服务器(也称为从服务器)。

主域名服务器负责维护一个区域的所有域名信息，是特定的所有信息的权威信息源，数据可以修改。主服务器直接从本地文件获取此信息。只能在主服务器上更改区域的 DNS 记录，然后主服务器才能更新辅助服务器。

当主域名服务器出现故障、关闭或负载过重时，辅助域名服务器作为主域名服务器的备份提供域名解析服务。辅助域名服务器中的区域文件中的数据是从主域名服务器中复制过来的，无法自行修改。

其实就是主从的概念，各位应该也都比较熟悉了。主域名服务器用来写，辅助域名服务器用来读，提供负载均衡的能力，缓解主域名服务器的压力。

  那么所谓区域传输(zone transfer)呢，就是辅助域名服务器与主域名服务器通信，并同步数据信息的过程。

辅域名服务器会定时向主域名服务器进行查询以便了解数据是否有变动。如有变动，则会执行一次区域传输。区域传输使用 TCP 而不是 UDP，因为数据同步传送的数据量比一个 DNS 请求和响应报文的数据量要多得多。

 当前 自家产品dns解析实现差不多把！

原理是：劫持dns解析，不是pa/ia的域名再去本地原来的dns服务器上去解析，是的话直接返回fake的结果， 并且江fake ip 和dns 进行映射。

  可以在eth 物理网卡上看到解析Google1.com的报文，但是看不到google的，因为此时dns劫持进程直接返回fake ip了。后面浏览器访问google.com时，报文直接到198.19.0.0.报文抓到tun0接口；

后续agent 截取tun0 tcp层报文 并且带上198.19.0.0 和dns 域名google.com 封装隧道发送到pop节点四层网管；由4层pop来处理

参考文章如下：

DNS 技术在代理环境中的应用

代理环境中的 DNS 解析行为