从 public DNS 服务器识别设备

Identify device from public DNS server

我以前有过从辅助 DNS 服务器获取客户端 IP 的案例(参见

现在我想通过从 public DNS 服务器识别本地网络中的设备来升级这个案例,简单模型是:

device <-> gateway <-> internet <-> DNS server

具体来说,我想获取有关网络上设备的更多信息,以具体识别每个设备,而不仅仅是拥有一个 IP 地址(代表网络上的一组设备,通过 NAT)。

我计划开发跨平台(移动、桌面...)应用程序以安装在我的设备上,但我立即看到的两个问题是

谢谢!

过去,Android 上的 DNS 代理应用程序通常依赖 VPN API,例如 Intra and Nebulo where they turn all Do53 request into encrypted request (or just forward them wholesale if it's only to change Do53 server on mobile connection) while leaving the rest of the traffic untouched. DNSCloak for iOS takes the same approach. There is a DNS proxy provider API for iOS but it can only run on devices enrolled in MDM, which kinda make it useless for the general public. On Windows, this pretend-VPN approach is used by NextDNS to cover the OS, though it's not exactly necessary, most desktop OSes allows changing the Do53 address regardless of the network being used, so just a regular proxy app 侦听端口 53 并配置 OS 以将请求定向到本地主机有效。

今天,Android and iOS 都支持本地加密 DNS,macOS 使用与 iOS 相同的配置文件,Windows 支持即将推出。这意味着,如果应用程序使用标准 DNS 从 OS 解析 API,它将由配置的 DoT/DoH 解析。请注意,如果应用程序配置为使用自己的 DoH(我不知道支持自定义 DoT 的主流应用程序),它将忽略 OS 配置。例如,如果 Chrome 设置为使用 Cloudflare DoH,而 OS 设置为使用不同的 DNS 提供商,则 Cloudflare DoH 将用于解析 Chrome.[=22 中的地址=]

好的,很好,您可能会感到困惑,为什么我要在您只想添加有关设备信息的额外负载时提出它,对吧?想想 DoH 和 DoT 需要什么,一个域。如果您购买了一个域,您可以拥有几乎无限的子域,并且如果每个设备(甚至应用程序)都设置为使用自己的子域,那么您就拥有了它,即识别有效载荷。这不需要设置大量的 DNS 条目,A 和 AAAA 都支持通配符条目。因此,您的 Web 服务器应用程序只需记录请求使用的子域,然后记录它们或将它们转换为更容易处理的格式。另一条更简单的路线是路径本身,尽管它仅适用于 DoH。

真的可以吗?它是可扩展的吗?是的,我知道,因为那正是 NextDNS 所做的。每个用户帐户可以有多个配置。这些配置中的每一个(表示为六位十六进制,足以容纳一千六百万个配置)都有自己的 DoT 子域和 DoH 路径,此外,设备(或应用程序)可以在它们之上包含自己的标识字符串。

因此,例如,如果一个人在 NextDNS 中有一个名为 abcdef 的配置,并且他们将 phone 设置为使用 phone-abcdef.dns.nextdns.io 作为 DoT 解析器,tablet-abcdef.dns.nextdns.io 作为他们的平板电脑中的 DoT 解析器,dns.nextdns.io/abcdef/phone-chrome,他们可以在他们的日志中看到由原始设备分开的请求,甚至是应用程序,无论请求来自哪里,无论是家庭连接、移动数据、办公室、TOR,等等

对于您的情况,最简单的解决方案是告诉您的用户下载 Intra/Nebulo 如果他们使用的是古老的 Android 9(大约 a quarter of the market) or guide them on how to use the OS built-in support to use your own DNS provider. You can even see the NextDNS example by creating a temporary config then scroll down to the Setup Guide. If you're expecting to sell to the general public from this endeavor, you're going against a very experienced player, but if this is just for a small organization, sure, go on, even a rudimentary PHP page 可以提取和处理 DoH payload,我不明白为什么它不能提取额外的路径信息然后将其登录到数据库中。

这里有一个非常粗略的例子来说明它是如何工作的(我相信 NextDNS、Cloudflare Teams 等使用更优化的逻辑):

  • 用户注册一个账号,然后创建至少一个配置
  • 此配置定义了 category/list 被阻止的内容、使用的功能等,可能只是一个数据库行,在详细表中列出了几个附加行。 DB 不一定是 SQL,因此它可能只是一个 NoSQL 条目。重要的是每个用户配置只需要非常小的存储空间。请注意,NextDNS 不允许任意第三方列表,仅允许预选列表。
  • 收到DoH/DoT请求后,服务器匹配来自DoH/DoT的domain/path的配置,并加载使用的自定义,解析请求的域,比方说example.com
  • example.com 做任何需要的事情,如果它不在配置的重写 rule/blacklist/custom 阻止列表中,则只将 DNS 负载发送到 upstream/recursive 解析器。一些 rules/configuration 可能需要对解析器输出进行额外处理(修改 TTL,如果该域是本月才注册的,如果它解析为本地地址,则阻止该域等)
  • 记录原始 IP and/or 设备标识字符串和采取的操作
  • Return查询结果

因此,并不是所有的 DNS 负载都被发送到 upstream/recursive 解析器,即使是那些发送到解析器的负载也可能仍会被 NXDOMAIN(或预定义的结果)替换。黑名单很可能针对所有用户进行了优化,oisd 列表可以像 isBlocked("oisd","example.com") 这样的方法调用来实现。由于大多数用户将主要访问来自非常有限的组的站点,因此可以缓存每个阻止列表的结果,并且该缓存在所有用户之间重复使用(毕竟,结果只是简单的是或否,没有隐私风险)。