从公共 DNS 服务器识别设备

如何解决从公共 DNS 服务器识别设备

我有从辅助 DNS 服务器获取客户端 IP 的旧案例（请参阅 get client IP from secondary dns server）

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

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

具体来说，我想获得有关网络上设备的更多信息，以具体识别每个设备，而不仅仅是拥有 IP 地址（通过 NAT 表示网络上的一组设备）。

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

• 应用检索设备信息后，如何将设备信息附加到 DNS 数据包中，或者以某种方式在 DNS 服务器上获取设备信息。但这只是应用程序内部的，请阅读下一个
• 假设如果我的应用有上述能力，那么我在我的设备上安装该应用时，所有来自设备的DNS查询都被强制通过我的应用已经安装的DNS，我的想法是可以得到设备的系统权限，因为我最近查了几款手机没有DNS编辑功能

谢谢！

解决方法

过去，Android 上的 DNS 代理应用程序通常依赖于 Intra 和 Nebulo 等 VPN API，它们将所有 Do53 请求转换为加密请求（或者如果只是更改 Do53，则直接转发它们移动连接上的服务器），同时保持其余流量不变。 DNSCloak for iOS 采用相同的方法。 iOS 有一个 DNS 代理提供商 API，但它只能在注册了 MDM 的设备上运行，这使得它对公众毫无用处。在 Windows 上，NextDNS 使用这种假装 VPN 方法来覆盖操作系统，尽管它不是完全必要的，但大多数桌面操作系统允许更改 Do53 地址，而不管使用的网络如何，所以只是一个常规的 {{3} } 侦听端口 53 并配置操作系统以将请求定向到 localhost 工作。

今天，proxy app 和 Android 都支持原生加密 DNS，macOS 使用与 iOS 相同的配置文件，Windows 支持即将推出。这意味着，如果应用程序使用来自操作系统的标准 DNS 解析 API，它将由配置的 DoT/DoH 解析。请注意，如果应用程序配置为使用自己的 DoH（我不知道支持自定义 DoT 的主流应用程序），它将忽略操作系统配置。例如，如果 Chrome 设置为使用 Cloudflare DoH，而操作系统设置为使用不同的 DNS 提供商，则 Cloudflare DoH 将用于解析 Chrome 中的地址。

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

它真的可以工作吗？它可扩展吗？是的，我知道，因为这正是 iOS 所做的。每个用户帐户可以有多个配置。这些配置中的每一个（以六位十六进制表示，足以容纳 1600 万个配置）都有自己的 DoT 子域和 DoH 路径，此外，设备（或应用程序）可以在其顶部包含自己的识别字符串。

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

就您而言，最简单的解决方案是告诉您的用户下载 Intra/Nebulo，如果他们使用的是 Android 9 之前的古老版本（大约 NextDNS），或者指导他们如何使用内置的操作系统支持使用您自己的 DNS 提供商。您甚至可以通过 a quarter of the market 查看 NextDNS 示例，然后向下滚动到设置指南。如果您希望通过这项努力向公众出售产品，那么您将与一位非常有经验的玩家对抗，但如果这只是针对一个小型组织，当然，继续，即使是基本的 creating a temporary config 也可以提取并处理 DoH 负载，我不明白为什么它不能提取额外的路径信息然后将其登录到数据库中。

这是一个非常粗略的例子，说明它的工作原理（我相信 NextDNS、Cloudflare Teams 等使用了更优化的逻辑）：

• 用户注册一个帐户，然后创建至少一个配置
• 这个配置，定义什么类别/列表被阻止，使用什么功能等，可能只是一个单独的数据库行，在详细信息表中列出了几个附加行。 DB 不一定是 SQL，因此它可能只是一个 NoSQL 条目。重要的是每个用户配置只需要非常小的存储空间。请注意，NextDNS 不允许任意第三方列表，只允许预先选择的列表。
• 在收到 DoH/DoT 请求后，服务器匹配来自 DoH/DoT 的域/路径的配置，并加载使用哪个自定义，解析请求的域，例如 example.com
• 对该 example.com 执行任何需要的操作，如果 DNS 负载不在配置的重写规则/黑名单/自定义阻止列表中，则仅将其发送到上游/递归解析器。某些规则/配置可能需要对解析器输出进行额外处理（修改 TTL，如果域在本月刚刚注册，则阻止域，如果解析为本地地址等）
• 记录原始 IP 和/或设备标识字符串以及采取的措施
• 返回查询结果

因此，并非所有 DNS 负载都被发送到上游/递归解析器，即使是这样，也可能仍会被 NXDOMAIN（或预定义的结果）替换。阻止列表很可能针对所有用户进行了优化，PHP page 列表可以实现为像 isBlocked("oisd","example.com") 这样的方法调用。由于大多数用户将主要访问非常有限的群体中的站点，因此可以缓存每个阻止列表的结果，并在所有用户之间重复使用该缓存（毕竟，结果只是是或否，没有隐私风险）。>