企业 DNS 服务的 3 种部署模式及对比

为什么 DNS 选错会让整个办公室下午茶时间集体断网

去年帮一家顺义做汽配的外贸公司处理故障，工程师到现场时整个办公区二十多台电脑全部打不开客户询价系统。查了一圈发现不是网络不通，是 DNS 解析超时——他们用了房东牵的宽带，DNS 是当地某运营商的 202.106.0.20，响应延迟已经飙到 3 秒。这不是个例。DNS 这个环节在 IT 架构里长期被当透明人，直到它出问题才被发现。中小企业选哪种 DNS 部署模式，直接决定了员工打开网页的速度、上游业务系统的可用性，以及 IT 部门半夜被叫醒的频率。

运营商 DNS：省事但埋雷

国内大多数中小企业的网络设备接上宽带后，默认就走运营商分配的 DNS 服务器。电信、联通、移动都有自己的递归解析节点，IP 常见的有 202.96.128.86、202.106.195.68 这类。这种方案零成本、零配置，路由器 WAN 口自动获取，用起来确实方便。但问题也最实际——跨运营商解析时延迟会明显放大，北京电信的用户访问托管在阿里云华东节点的 SaaS 系统，DNS 这层要先跑去运营商节点，如果对方没有做 Anycast 或者缓存策略不完善，首次解析可能要 500 毫秒甚至更久。

更棘手的是运营商 DNS 的解析结果劫持问题。某些地区的宽带用户输入一个不存在的域名，会被运营商 DNS 强制跳转到一个广告页面或者他们的导航站。这对普通员工查资料还好，但对业务系统来说是灾难——如果代码里写死了某个内部域名的 IP，这个域名恰好不存在，浏览器就会被重定向到奇怪的地址，session 直接失效。我见过不止一家公司的 OA 系统因为这个原因间歇性登录失败，最后排查到 DNS 层面才发现问题。

自建递归 DNS：Unbound 的实操门槛

在望京一家做对日外包的科技公司，我给他们的机房部署过一套基于 Unbound 的自建递归 DNS。选 Unbound 主要是因为它轻量、资源占用低，一台 4 核 8G 的虚拟机就能扛住 500 终端的解析量，而且支持 DNSSEC 验证。安装过程不算复杂，Ubuntu 20.04 下 apt install unbound，几行配置就能跑起来。关键是缓存策略要调对——Unbound 默认的缓存时间是 TTL 值的两倍，但很多中小网站的 TTL 设置混乱，导致某些记录被缓存过久而失效。

自建递归的最大价值是可控性。你可以决定要不要启用 DNSSEC，要不要屏蔽特定域名，要不要针对内网做 split-horizon 解析。望京那家外包公司当时有个需求：日本客户访问他们的测试环境需要走日本节点，当地员工访问要走国内节点，这个分流逻辑在 Unbound 里通过 view 模块实现，两个地区同一域名解析出不同 IP，自建方案改几行配置就能搞定。

但门槛也很现实。自建递归 DNS 需要有人具备基本的 Linux 操作能力和 DNS 协议知识，出了问题要能看懂日志、会调试。中小企业 IT 人手本来就紧张，如果只有一台 Windows Server 在跑文件共享，专门为 DNS 再搭一套 Linux 环境其实有点过度投入。更重要的是，自建递归的出口带宽决定了整体解析能力，如果公司只有一条 100M 宽带，出口带宽跑满了递归解析也会卡。

私有 DNS 服务与 DoH/DoT：安全与隐私的新选择

这两年 DNS 领域最大的变化是 DoH（DNS over HTTPS）和 DoT（DNS over TLS）逐步落地。传统 DNS 查询是明文 UDP 端口 53，在企业内网里容易被中间人截获或者被出口网关记录。DoH/DoT 把 DNS 请求封装在 HTTPS/TLS 隧道里，运营商或者中间设备只能看到一个 HTTPS 连接，看不到具体查询了什么域名。

Cloudflare 的 1.1.1.1、Google Public DNS 8.8.8.8 都支持 DoH/DoT，企业内网设备如果支持的话可以直接配置。但有个现实问题——很多公司的出口防火墙默认会阻断非标准端口流量，DoT 用的是 853 端口，DoH 用的是 443 端口，这两个端口如果不放开，设备配置了也用不了。从安全角度来说，DoH/DoT 确实能防止 DNS 投毒和劫持，但实际落地要配合网络策略调整。

对于有更高安全诉求的企业，现在也有一些私有 DNS 服务可以自建。比如在内部部署一套基于 adGuard Home 或者 CoreDNS 的方案，配合 DoH 对外提供服务。员工电脑安装了对应客户端后，解析请求直接走加密隧道到内网 DNS 服务器，内网服务器再去上游递归。这种模式适合研发型企业或者对数据泄露比较敏感的场景。思文力得给某制造业客户部署的网络整包方案里，就包含了一套基于 adGuard Home 的内网 DNS，既做了解析加速，也拦截了员工访问钓鱼域名的风险。

中小企业的推荐方案：分层 + 冗余

综合我们在北京服务 300 多家企业的经验，中小企业（50 人以下）最务实的方案是双层结构：出口网关或者路由器上配置两个公共 DNS 作为兜底，比如 223.5.5.5（阿里）和 119.29.29.29（腾讯），这两个在国内节点多、响应快，比运营商 DNS 靠谱得多。如果业务系统对解析稳定性要求高，比如用 ERP 或者云端 OA，再在局域网内部署一台 DNS 缓存服务器，用 Windows Server 的 DNS 角色或者 Linux 的 dnsmasq 都行，主要用来缓存内网域名的解析结果，同时分担出口压力。

如果预算允许、希望进一步提升安全水位，可以考虑把内网 DNS 升级为支持 DoH/DoT 的方案，或者直接用商业的 DNS 安全服务。思文力得的 sTrust 零信任方案 里就包含 DNS 层的防护能力，能够识别并拦截恶意域名访问，适合对信息安全有合规要求的企业客户。

1. 基础档：双公网 DNS（阿里 223.5.5.5 + 腾讯 119.29.29.29），零成本，适合员工少于 30 人、业务系统不依赖自建域名的场景。
2. 进阶层：局域网 DNS 缓存服务器（Windows Server DNS 或 dnsmasq）+ 双公网 DNS 上游，适合 30-100 人，有内部域名的公司。
3. 企业档：自建递归 DNS（Unbound/adGuard）+ DNSSEC + DoH/DoT 出口，配合 sTrust 等安全方案，适合 100 人以上或研发型企业。

选型的时候还有个细节要注意：DNS 的失效切换要自动化。有些公司的路由器支持 DNS 故障转移，当首选 DNS 超时就自动切到备用，这个功能看起来简单，但能避免半夜断网没人发现的尴尬情况。

DNS 看似是基础设施里最不起眼的一环，但它出问题时影响面最广、排查链路最长。如果你的企业还没有梳理过 DNS 策略，现在是动手的好时机——毕竟修 DNS 故障的时间，通常比部署一套稳定 DNS 的时间要长得多。