你启动了第三台服务器，希望这些机器之间用名称而不是 IP 互相访问，于是搜索“private DNS VPS”。返回了三个结果，而且互相对不上。一个是加密手机查询的 Android 设置。一个是为域名定制品牌名称服务器的 cPanel 指南。还有一个是关于私有托管区域的 AWS 文档。2026 年 7 月 20 日， Cloudflare 将 Internal DNS 正式发布为全面可用 并将其描述为“有时也称为私有 DNS”，于是这种名称冲突现在也来自基础设施厂商。
这个术语被过度使用了。本文先区分它的不同含义，然后聚焦于 VPS 网络层面的含义：用于服务器之间通信的内部 DNS 区域。读完之后，你就能判断自己需要哪一种系统、决定你的服务器群是否需要私有 DNS，并避开常见的设计错误。
TL;DR（太长不看版）
- “私有 DNS”至少指代三种互不相干的系统：面向服务器网络的内部 DNS 区域、Android 的 DNS-over-TLS 加密功能，以及 cPanel 的品牌名称服务器。本文采用第一种含义：面向 VPS 网络的内部 DNS 区域。
- VPS 私有 DNS 区域是一个作用范围限于网络的内部命名空间，它把诸如
db.internal.example.com这样的主机名映射到私有 IP。它的记录不会发布到公共 DNS 中。 - 对于少数几台 IP 稳定的服务器来说，
/etc/hosts确实就够了。只有当服务器规模变大、IP 频繁变动，或服务需要可靠的名称解析时，内部 DNS 服务器才值得投入。 - 对于大多数生产环境的 VPS 网络，请使用你自己拥有的子域名，例如
internal.example.com。只有在孤立的环境中才使用 .internal 命名空间，前提是你能接受跨网络的名称冲突、私有 CA 的证书管理，以及特殊的 DNSSEC 处理方式。避免使用 .local，它是 mDNS 保留的。
本文不涉及的内容
本文只讨论私有 DNS 在 VPS 网络层面的含义，不涉及与之无关的消费级用法和主机品牌用法：
- 在手机上配置 Android 的私有 DNS 或 DNS-over-TLS 设置。
- 为主机品牌配置 cPanel 私有名称服务器。
- BIND 9、Unbound、dnsmasq 或 CoreDNS 的完整安装教程。本文的实现部分只停留在参考层面，而不是逐步配置。
- 1.1.1.1 或 NextDNS 之类面向消费者的加密解析器，除了把它们与网络层面的含义区分开之外。
“私有 DNS”到底指什么？
“私有 DNS”并不是单一系统。这个说法至少指代三种互不相干的系统：在 VPS 或 VPC 网络内部解析内部主机名、且访问范围受限于网络的 DNS 区域；Android 的 DNS-over-TLS 加密功能；以及 cPanel 中自定义品牌的权威名称服务器。本文讨论的是第一种，也就是你的服务器为找到彼此而查询的内部区域。此外还有第四种较宽泛的用法：以“私有”为卖点的加密公共解析器。
这四种含义只共用一个名字，别无共同之处：
| 系统 | 它是什么 | 谁在使用 | 它不做什么 |
|---|---|---|---|
| 内部 DNS 区域（VPS/VPC） | 作用范围限于网络的命名空间，把内部主机名解析为私有 IP | VPS 运维人员、DevOps 团队、云平台 | 本身不加密查询，也不会把记录发布到公共 DNS |
| Android 私有 DNS | 一个 DNS-over-TLS 开关，在 853 端口上加密设备的查询（自 Android 9 起） | 手机和平板用户 | 不会创建内部主机名或私有区域 |
| cPanel 私有名称服务器 | 为某个域名定制品牌的权威名称服务器（ns1.yourbrand.com） | 网站主机商和代理商 | 不会创建服务器之间通信用的私有命名空间 |
| 面向消费者的加密解析器 | 以查询隐私为卖点的公共解析器（1.1.1.1、NextDNS） | 希望查询保持隐私的个人用户 | 其本身不会创建内部权威区域 |
Cloudflare 关于 Internal DNS 全面可用的公告 是第一种含义当下的托管式实例，也是这种名称冲突之所以变得显眼的原因之一：一家基础设施厂商如今在发布文案中把“私有 DNS”当作内部 DNS 的同义词。它所描述的系统，即面向 Enterprise 客户的 Gateway Resolver 加 Internal Authoritative DNS，与你在 VPS 集群上自行搭建的属于同一类系统，只不过是托管版本。
本节要点： 被称为“私有 DNS”的几种主要系统共用的是一个标签，而不是同一种功能。在照着任何配置教程动手之前，先弄清指的是哪一种。
私有 DNS 在 VPS 网络中如何工作？
VPS 私有 DNS 区域是一个作用范围限于网络的命名空间，由你的服务器被配置去使用的解析器提供服务。它把诸如 db.internal.example.com 这样的内部主机名映射到你所控制的地址段中的私有 IP。这些记录不会发布到公共 DNS，尽管查询在到达解析器之前可能会经过私有隧道或托管的 DNS 控制平面。这种隔离正是私有 DNS 与公共 DNS 区别的核心：协议是相同的，不同的是区域的可见性和访问范围。
有三个部分在协同工作。一个权威服务器或区域数据源保存内部区域及其记录。一个解析器负责回答你的服务器发出的查询。而该区域的 A 记录和 AAAA 记录把内部主机名映射到私有地址，于是 app.internal.example.com 会解析到应用层，而 db.internal.example.com 则解析到数据库。其他记录类型可以提供别名或服务信息。当区域和解析器路径配置正确时，解析器会在本地回答内部查询，而不会把它送往公共 DNS 根。
各家云平台把这件事的作用范围定在网络而不是单台机器上，这是个很有参考价值的模型。 AWS Route 53 私有托管区域 只有当 VPC 同时把 enableDnsHostnames 和 enableDnsSupport 设为 true 时才生效，并且对于你关联到该区域的任何 VPC，解析器都会从私有区域作答。 Google Cloud 私有区域 的作用范围限于已授权的 VPC 网络，而在 标准的 VPC 名称解析顺序 中，它们会先于公共 DNS 被查询，除非有出站服务器策略改变了这条路径。请把这些当作该模式的示例，而不是平台教程：你自行管理的内部 DNS 服务器是同一个思路，只不过跑在自己的 VPS 上。
把区域挡在公共 DNS 之外只完成了一半工作。请把 DNS 服务绑定到私有网络接口，或者把 UDP 和 TCP 的 53 端口限制在你的私有网络或 VPN 内。不要把递归服务暴露到公网上；因为 开放解析器可能被滥用于 DNS 放大攻击.
私有区域和公共区域使用同一套 DNS 记录和缓存模型。记录带有 TTL，缓存解析器通常会重复使用某个应答，直到该 TTL 过期，不过解析器自身的设置可能改变实际的缓存时间。这一行为在我们那篇把域名指向 VPS 的指南中有说明，其中包括 DNS 传播与 TTL 基础，因此本文不再重复解释。
你的 VPS 网络到底什么时候才需要私有 DNS？
对于两三台静态服务器来说， /etc/hosts 确实就够了。只有当服务器规模变大、IP 经常变动，或应用需要可靠的服务发现时，内部 DNS 服务器才值得投入。真正的触发点是运维复杂度，而不是某个固定的服务器数量。
/etc/hosts 是一张静态的主机名到 IP 的映射表，每台 Linux 机器上本来就有。它不需要守护进程，也不需要区域文件，但过期或不一致的副本是实实在在的故障来源。把每台服务器的私有 IP 写进这个文件，保持各副本同步，机器之间就能按名字互相找到。对于规模小而稳定的机群来说，这就是正确答案；改用 BIND 9 只是白白多出一个要维护的守护进程。
在三种情形下它就撑不住了。当你频繁增删服务器时，让一份静态文件在每台主机上保持一致会变成繁琐的手工活。当 IP 因为自动扩缩容、重建或服务商重新分配而变动时，这个文件会悄无声息地过期。而当容器或隔离的运行时不会继承宿主机的条目时，这套映射就不再是通用的了。其中任何一条才是真正的触发点。单看服务器数量只是粗略的替代指标，并不是真正的信号。
本节要点： 触发点是运维层面的变动频率，而不是服务器数量。一个十台机器且长期不变的机群完全可以只靠 /etc/hosts撑下去；而一个每晚都重建的三台机器的机群，大概就不该这么做了。
在拥有 root 权限、NVMe 与 AMD EPYC 强大性能的 Linux VPS 上构建应用。
查看 Linux 套餐该运行哪个 DNS 服务器：BIND 9、Unbound、dnsmasq 还是 CoreDNS？
按你机群的形态来选。dnsmasq 适合想要轻量 DNS、并在需要时由同一个守护进程顺带提供 DHCP 的小型网络。Unbound 是一个精简的、带校验的递归解析器，也能回答规模不大的本地区域。BIND 9 提供广泛的权威与递归能力，配置面也最广。CoreDNS 适合容器和 Kubernetes 机群，那里 DNS 本身就是服务发现的一部分。
| 工具 | 角色 | 最适合 | 取舍 |
|---|---|---|---|
| BIND 9 | 完整的权威加递归 | 需要广泛 DNS 功能和大量参考资料的机群 | 配置面最广，运维复杂度也最高 |
| Unbound | 递归或转发解析器，支持本地区域并可做 DNSSEC 校验 | 既需要递归、又需要一个规模不大的静态内部区域的小型机群 | 本地区域数据比较简单；复杂的权威行为更适合通过 auth-zone 或专门的权威服务器来处理 |
| dnsmasq | 轻量 DNS 与 DHCP 合二为一 | 规模小且稳定的机群，或者同时还需要 DHCP 的 LAN 式网络 | 随着机群和区域变大，功能显得不足 |
| CoreDNS | 基于插件的 DNS 服务器 | 使用容器、Kubernetes 以及大量依赖服务发现的机群 | 灵活，但行为取决于你配置的插件链 |
选型逻辑很短。如果你需要一个以 hosts 风格文件为底的小解析器，或者本来就在分发 DHCP 租约，dnsmasq 能少一个要照看的部件。如果你主要需要的是一个带校验、向外转发并能回答一个小型内部区域的解析器，Unbound 就能提供这套更窄的功能，而不必完整部署 BIND 9。如果你需要完整的权威控制、委派，以及凌晨三点能依靠的最庞大文档，尽管配置面更广，BIND 9 依然是稳妥之选。如果 DNS 本来就是容器或 Kubernetes 服务发现栈的一部分，CoreDNS 正好落在那个位置上。经验法则是：跑能覆盖你机群形态的最小的那个东西。
对于生产环境的机群，不要让单个 DNS 实例成为通往每一个内部名称的唯一路径。请运行 至少两个 DNS 实例 能够回答该区域的实例，在条件允许时把它们放在不同的故障域里，并把客户端配置成两者都能访问。否则，一次 DNS 故障就能让健康的服务看起来像是挂了。
内部域名该怎么起名：.internal、.local，还是子域名？
对于大多数生产环境的 VPS 网络，请使用你自己拥有的子域名，例如 internal.example.com。只有在孤立的环境中才使用 .internal 命名空间，前提是你能接受跨网络的名称冲突、私有 CA 的证书管理，以及特殊的 DNSSEC 处理方式。避免使用 .local，它是 mDNS 保留的。
.local 的问题是具体的。 RFC 6762 为以 .local 结尾的名称规定了 Multicast DNS 的特殊处理方式，因此使用同一后缀的 BIND 9 或 Unbound 单播区域，可能与 Apple 设备及其他启用 mDNS 的系统上的 mDNS 行为发生冲突。请改用另一个命名空间，而不是依赖针对特定客户端的变通做法。
专业提示：如果你接手了一个 .local 内部区域，请把它当作技术债。有些客户端会把 .local 查询发给 mDNS 而不是你的单播 DNS 服务器，这会造成因客户端而异、或看起来时好时坏的故障。
ICANN 董事会已永久保留 .internal ，使其在 2024 年 7 月起不再于公共 DNS 根中被委派，此前 SSAC 已有相关建议。按照设计，该后缀下的名称不会通过全球 DNS 解析。这带来一些取舍：.internal 名称并非全球唯一，公共证书颁发机构预计不会为其签发证书，而依赖全球信任锚做 DNSSEC 校验的解析器将无法解析它们。如果你需要在 .internal 上使用 HTTPS，就要打算自己运营一个私有 CA。
这里要把两件事分开。ICANN 的保留决定是最终的。另外还有一份 仍在生效的 Internet-Draft，draft-davies-internal-tld-06，于 2026 年 5 月 6 日发布，用于记录该命名空间并将其与 RFC 1918 的私有地址方案作比较。它仍是一份处于草拟阶段的 Internet-Draft，而不是已发布的 RFC，因此请把 .internal 描述为由 ICANN 保留的私用顶级域，而不是 IETF 标准。
对于大多数 VPS 机群，用你自己掌控的域名下的子域名是更稳妥的默认选择。 ISC 推荐采用子域名层级结构，比如用你自己域名下的一个内部子域名，而不是为同一个父区域维护彼此分离且都不完整的内部版本和公共版本。这个偏好不是风格问题：它能避免下一节要讲的那种故障。
本节要点： 命名空间的决定会长期跟着你。对大多数生产环境来说，你自己掌控的子域名是默认选择，因为它保持了全球唯一性，也能与公共 PKI 配合。当一个孤立的私有命名空间更合适、且你能接受它在 DNSSEC、证书和名称冲突上的取舍时，再使用 .internal。
分离视图 DNS 以及会把它弄坏的那些错误
分离视图 DNS 会根据提问者的不同，为同一个主机名给出不同的答案：内部返回私有 IP，外部返回公网 IP。它最常见的失效原因是同域下的 NXDOMAIN 陷阱、绕开预期视图的备用解析器，以及没有到达预期上游的容器 DNS 路径。要做对，取决于同时成立的三件事，而不是一件。
NXDOMAIN 陷阱正是 ISC 直接警告过的那种故障。如果你的内部服务器对父域具有权威，但它们那份区域数据里没有某条公共记录（比如 www 主机），那么内部客户端查询这个名称时就会收到 NXDOMAIN，即便公共区域里确实有这条记录。内部区域是权威的，对于父域它不会回退到公共 DNS。这正是命名那一节里子域名层级方案成为 ISC 首选设计的原因。
专业提示：在把服务器指向同域的分离视图配置之前，先从网络内部试着解析该域下一个已知的公共名称。如果一个在外部解析正常的名称却返回 NXDOMAIN，那就是这个陷阱的典型特征。
还有三个容易被忽略的坑。在宿主机或容器上配置的备用解析器可能绕开这套分离；具体取决于解析器的实现，它可能在超时后被查询，也可能被并行查询，因此答案会不一致。使用 Docker 默认网桥的容器在启动时会拿到宿主机 DNS 配置的一份副本，而自定义网络上的容器则查询 Docker 内置解析器，地址是 127.0.0.11。该解析器会把外部查询转发给为宿主机或容器配置的 DNS 服务器，因此 split-DNS 的行为取决于 Docker 和宿主机的配置，而不只是容器自己的解析配置文件。如果某个内部服务位于反向代理之后，比如 Nginx 代理管理器，那么当证书没有覆盖所请求的主机名，或者签发它的 CA 不被客户端信任时，证书校验就会失败。仅仅在内部使用另一张证书，本身并不是错误。这些都是配置上的缺口，而不是工具的缺陷。
远程客户端也可能碰上同样的故障，比如当一套 自托管 VPN 没有把 DNS 查询推送或路由到预期的内部解析器时。
这里还有安全维度。如果内部主机名和私有 IP 泄漏进公共 DNS 记录，你就等于把内部命名和编址方案的一部分暴露给了任何发起查询的人。分离视图存在的部分理由，正是把这张图留在内部，而一个配置有误的公共区域会悄悄把它拆掉。
本节要点： 分离视图的失效是配置陷阱，而不是工具缺陷。正确与否取决于命名纪律、弄清每个客户端实际查询的是哪个解析器，以及把区域范围划得恰当，而不取决于某一个设置项。
结论：如何选择合适的私有 DNS 设计
现在你能分辨自己说的“私有 DNS”到底是哪一种系统了。就 VPS 网络而言，它指的是内部 DNS 区域，而不是 Android 的 DNS-over-TLS 设置，也不是带品牌的权威名称服务器。如果你的机群规模小而稳定， /etc/hosts 就是站得住脚的选择。如果不是，就用你自己拥有的子域名作为默认命名空间，挑选最小的、能满足机群需要的 DNS 服务器，并把访问控制、冗余以及内部与公共区域的边界都写清楚。只有当孤立的命名空间更合适、且你能接受它在证书、DNSSEC 和名称冲突上的取舍时，才使用 .internal。
常见问题
Android 的私有 DNS 和 VPS 上的私有 DNS 服务器是一回事吗？
不是。Android 私有 DNS 是一项 DNS-over-TLS 功能（在 853 端口上加密查询，自 Android 9 引入），用于保护设备查询在传输过程中的安全。而 VPS 上的私有 DNS 服务器，是在整个网络范围内把内部主机名解析为私有 IP。一个加密查询，另一个创建内部命名空间。它们解决的是毫不相干的问题。
私有 DNS 和公共 DNS 有什么区别？
私有 DNS 只把某个区域开放给特定网络、VPN 或云环境中的授权客户端。公共 DNS 则发布互联网上的解析器都能查询的记录。两者使用同样的 DNS 记录类型和缓存模型；区别在于谁能访问这个区域，以及它的记录在哪里可见。
私有 DNS 和加密 DNS 有什么区别？
DoT、DoH 之类的加密 DNS 协议保护的是 DNS 查询在传输过程中的安全。而网络意义上的私有 DNS，是为内部名称创建一个作用范围限于网络的命名空间。加密改变的是查询怎么走；私有区域改变的是哪些名称存在、以及谁能解析它们。
把 .internal 用于内部主机名安全吗？
可以，但有前提。ICANN 已于 2024 年 7 月永久把 .internal 排除在公共委派之外，所以你可以在私有解析器上提供它。不过它并非全球唯一，公共证书颁发机构预计不会为它签发证书，依赖全球信任锚的 DNSSEC 校验器也无法解析它。对大多数生产环境的 VPS 网络来说，你自己拥有的子域名才是更稳妥的默认选择。
私有 DNS 记录和公共 DNS 使用同样的 TTL 和缓存机制吗？
是的。私有区域和公共区域使用同一套基于 TTL 的缓存模型：记录带有 TTL，缓存解析器通常会重复使用某个应答，直到该值过期。解析器自身的设置仍可能改变实际的缓存时间。相关机制可参见 DNS 传播与 TTL 行为 ，其中讲了底层机制。
讨论
评论
登录后参与讨论。