去年夏天，企业一家做芯片设计的内网公司差点因为DNS配置失误丢掉一笔大单。他们的企业研发内网有上千台服务器，运维图省事，内网直接把公共DNS写进了所有机器的企业 resolv.conf。结果某天外部DNS解析出现延迟，内网整个CI/CD流水线卡了四十分钟，企业测试环境无法拉取镜像，内网交付节点被迫推迟。企业这事之后，内网他们的企业技术负责人跟我说了一句话：内网DNS不是“能解析就行”，它决定了整个基础设施的内网响应基线。

很多团队对内网DNS的企业认知停留在“装个BIND就完事”。真动手时才发现，内网难点根本不在软件安装，企业而在架构设计。你要考虑递归还是转发、视图分离怎么做、动态更新走什么协议、缓存TTL设多少。这些参数一旦定错，后面迁移成本极高。

我见过最离谱的一个案例：某公司内网DNS用了一台Windows Server，所有Linux机器通过Samba Winbind去解析主机名。后来Windows那台机器蓝屏，整个Kubernetes集群的节点心跳全部超时，Pod被批量驱逐。根本原因就是CoreDNS的上游指向了那台单点Windows DNS。没有冗余，没有fallback，也没有监控。

搭建内网DNS，第一步是明确解析范围。内部域名（比如 corp.internal）和外部域名（比如 github.com）最好分开处理。内部域名由权威DNS直接应答，外部域名走递归或转发。如果混在一起，很容易出现内部域名泄漏到公网，或者外部解析被内部记录污染。BIND的 view 功能可以解决这个问题，但配置复杂度不低。更轻量的方案是用 dnsmasq 做转发加本地hosts，适合中小规模。超过五百台机器，建议上 PowerDNS 或 CoreDNS，配合etcd做动态后端。

具体到配置，有几个参数值得单独拎出来说。forward only 和 forward first 的区别在于：前者只转发，不尝试递归；后者先转发，失败后再递归。内网环境通常用 forward only，指向可靠的公共DNS或上游内网DNS。dnssec-validation 如果开启，需要确保上游支持DNSSEC，否则解析会静默失败。我建议初期关闭，等链路稳定后再逐步启用。

缓存策略也容易踩坑。TTL设得太短，DNS查询量暴涨；设得太长，记录变更后客户端迟迟不更新。内部服务发现场景下，TTL建议在30到60秒之间。如果是静态主机名，可以放宽到300秒。另外，max-cache-ttl 和 max-ncache-ttl 要显式设置，避免上游返回异常大的TTL导致缓存污染。

监控这块，很多人只盯着进程存活。真正有用的是查询延迟分布、NXDOMAIN比例、缓存命中率。我用过最简单的方案是 dnstop 加 Prometheus 的 bind_exporter。一次线上故障中，NXDOMAIN比例突然从2%跳到40%，查下来是某个应用把 .local 域名当成了内部域名去查询，而内网DNS没有配置 .local 的转发规则。加上一条 server=/local/114.114.114.114 就解决了。

高可用方面，主从架构是标配。但主从同步的延迟经常被忽略。如果从节点同步间隔是60秒，主节点挂掉后，最长有60秒的解析空窗期。对于核心业务，这个窗口不可接受。可以用 notify 加 also-notify 让主节点主动推送变更，把同步延迟压到秒级。再配合 anycast 或者 keepalived 做VIP漂移，基本能实现无感切换。

最后说一个细节：内网DNS的日志不要只记查询内容。记录客户端IP、查询类型、响应码、响应时间，这些字段在排查问题时比查询域名本身更有价值。有一次某台机器频繁查询 _ldap._tcp.corp.internal，日志里只看域名以为是LDAP服务异常，后来加上客户端IP才发现是一台误配置的打印机在疯狂重试。

内网DNS搭建没有银弹。规模、团队习惯、现有基础设施都会影响选型。但核心原则不变：解析路径要短，单点要少，监控要细。做到这三点，至少不会因为DNS把整个内网拖垮。