iPhone 上的 VPN DNS：谁拥有这项设置，决定它在哪里生效

在 iPhone 的 Wi-Fi 设置里填入一个私有解析器地址，它只会工作到手机离开那个网络为止，而那正是 VPN 应当接管的时刻。这是移动 DNS 的第一个陷阱：你输入设置的位置决定了它的作用范围，而范围比大多数人以为的更窄。动手之前，先回答关于部署的三个问题，因为答案决定你该动哪一层控制。请把这一顺序当作设计评审，而不是翻找设置。

输入解析器地址前的三个问题

第一，哪些名字才真正需要特殊处理？像 corp.example 这样的私有区域是一个命名空间，而不是单台主机，答案应当是一个域，而不是一条记录。第二，哪个解析器对它具有权威性，那项服务归谁所有？第三，哪条路径让手机能够到达该解析器：隧道、被路由的 Wi-Fi 网络，还是完全不同的其他方式？

这三者中任何一项没有归属者，就请停下。缺少命名空间、权威来源和可达路径的 DNS 变更只是一种猜测，它在蜂窝网络上的失败方式与在办公室里不同。

Wi-Fi 的 DNS 条目属于那个 Wi-Fi 网络

iOS 上的手动 DNS 配置按网络分别保存。手机与该 SSID 关联时它生效，不关联时便不再生效，这意味着它无法管辖蜂窝流量，也无法描述 VPN 客户端做了什么。为了修好一个在蜂窝网络上失败的 App 去改它，等于改动一条失败路径根本不会读取的设置。

这并不让按网络配置的 DNS 变得无用。对家庭实验室或单一办公 SSID 来说，它是到达内部解析器最简单的方式，而且它对自己的边界是诚实的。

VPN 的 DNS 机制取决于协议与客户端

iOS 上的数据包隧道提供方可以通过 Apple 的 DNS 设置 API 配置 DNS，该接口把解析器地址和域名匹配暴露给拥有连接的那条隧道。原生 IKEv2 配置可以在网关推送时通过 IKE 配置载荷接收 DNS，但某个客户端是否真的应用所收到的内容，是你必须验证的实现细节。基于 App 的客户端可以完全实现自己的解析路径。

这些是不同的集成点，其中一种的结果不会成为所有 iPhone 的规则。受支持的机制是配置文件或提供方针对所用协议所记录的方式。

按归属决定，而不是按方便决定

如果设备受管理，配置文件的所有者应当随 VPN 配置一起下发 DNS 设置，这样重新注册就能恢复它，用户无需记住任何东西。如果提供方 App 拥有隧道，它的设置界面就是该看的地方，而它的文档就是关于它能拆分什么的权威。如果手机是私人的，需求只是某个网络上的一个内部名称，那么按网络配置就是相称的。

决策规则很短：设置属于连接被配置的地方。放在别处，它就只是一个本地例外，下一次网络变更会抹掉它。

在手机真正使用的路径上验证

从需要该私有名称的 App 发出一次新请求，分别在办公室 Wi-Fi、蜂窝网络以及两者之间的切换中测试。带有自己解析器集成的 App 可能走与系统不同的路径，所以要测真实应用，而不是一个碰巧能用的浏览器标签页。

当私有名称失败时，请保留准确的错误和配置文件状态。公共解析器回答该名称不存在，是对错误问题的正确回答；把它加在公司解析器旁边并不构成命名空间设计。

最后，把已验证的策略与配置来源一起保存。下一次重连或注册应当恢复同一套名称服务，因为配置文件这样说了，而不是因为有人记得两年前在某个热点上做过的一次修改。