公司内网那台DNS服务器挂了三次，内网每次都是析服同一个原因——有人把测试环境的域名解析指到了生产IP上。运维群里骂声一片，内网但问题不在人，析服在架构。内网

内网DNS解析服务器，析服说白了就是内网给内部设备用的“电话簿”。你访问gitlab.corp.local，析服它告诉你这台机器在哪。内网跟公网DNS最大的析服区别是：它只服务自己人，不对外，内网所以理论上可以做得更简单、析服更可控。内网但现实往往相反——很多公司的析服内网DNS比公网还乱。

为什么不用公网DNS凑合

有人觉得，内网内网机器直接配个8.8.8.8不就完了？不行。公网DNS解析不了你的.corp、.local、.internal域名，这些后缀在公网根域里根本不存在。你总不能让内部Git、Wiki、CI/CD都去申请公网域名，成本不说，安全性也过不去——内网IP暴露在公网DNS记录里，等于把家底贴在门口。

还有个更实际的原因：延迟。公网DNS走一圈回来几十毫秒，内网DNS通常1毫秒以内。别小看这点差距，微服务之间调用频繁，DNS查询次数多了，累积起来很可观。

选型这事，别想太复杂

我见过用BIND的，配置起来像在写汇编。也见过用Windows DNS的，图形界面点来点去，批量操作能把人逼疯。如果只是几十台机器的小内网，dnsmasq足够——一个配置文件，几行address=/gitlab.corp.local/10.0.1.50，重启服务就生效。

规模上百台、需要动态更新记录的，CoreDNS更合适。它是Go写的，单二进制文件，配置用Corefile，插件机制灵活。Kubernetes集群里默认就是它。我自己的做法是：CoreDNS做核心解析，上游转发到dnsmasq做缓存，dnsmasq再往上走公网。分层处理，各管各的。

那些年踩过的坑

最坑的一次是TTL设太长。某台服务器换了IP，DNS记录改了，但客户端缓存了24小时。结果一整天都有人连到旧IP上，报错五花八门。后来把内网记录的TTL统一压到60秒，改完一分钟内全网生效。代价是DNS查询量上去了，但内网带宽不值钱，这点流量无所谓。

还有泛解析的坑。*.corp.local指向一个IP，本意是方便，结果有人写错了域名，比如gtilab.corp.local，照样解析成功，连到错误的机器上。排查了半天才发现是泛解析把错误吞掉了。泛解析这东西，方便和隐患并存，看你怎么权衡。

监控和日志不能省

DNS服务器不出问题的时候没人记得它，出问题的时候整个内网瘫痪。所以监控必须做。我一般盯三个指标：查询量突增（可能有人扫描）、NXDOMAIN比例（说明有人在访问不存在的域名，可能是配置错误）、响应时间（超过5ms就要查原因）。

日志也得留着。CoreDNS可以配log插件，把查询记录打到文件里。有次排查一个诡异的连接超时，最后就是从DNS日志里发现某台机器在反复查询一个已经不存在的服务名。日志保留一周就够，太占地方。

安全这块别偷懒

内网DNS最容易被忽视的安全问题是：谁都能查。默认情况下，任何能访问到DNS服务器53端口的设备都能查询所有记录。这意味着一旦有人接入内网，就能通过DNS枚举出你所有的内部服务。解决办法是配ACL，只允许特定网段查询。BIND和CoreDNS都支持。

另一个是DNS劫持。内网DNS服务器如果被拿下，攻击者可以把gitlab.corp.local指向自己的钓鱼服务器。所以DNS服务器本身要最小化安装，只跑DNS，别在上面装其他东西。SSH密钥登录，禁用密码。

说到底，内网DNS解析服务器是个基础设施，平时感觉不到它的存在，但它决定了整个内网的访问体验和安全性。花半天时间把它配好，比后面花三天排查问题划算得多。