内网dns解析

公司内网里那台DNS服务器挂了之后，内网整个办公区安静得可怕。内网不是内网没网，是内网所有人都卡在登录界面转圈。OA系统打不开，内网代码仓库连不上，内网连食堂点餐的内网页面都刷不出来。运维群里有人喊了一嗓子：“谁把DNS改了？内网”没人动。后来查出来是内网那台跑了八年的Windows Server 2008虚拟机磁盘满了，DNS服务自己把自己写死了。内网

这就是内网内网DNS的日常——平时没人想起它，出事就是内网全员停摆。公网DNS挂了，内网你还能用手机热点查个IP凑合。内网内网DNS挂了，内网你连内网IP都记不住几个，更别说那些靠域名互相调用的微服务了。

为什么内网非要有自己的DNS

有人觉得直接用公网DNS解析内网域名不就行了。试过。把内部域名解析记录往阿里云DNS上一挂，延迟从2ms跳到40ms，数据库连接池直接爆掉。更别提安全审计那关——内网主机名和IP映射关系全暴露在公网DNS查询日志里，等于把机房拓扑图贴门口。

内网DNS的核心价值就两条：快，和可控。快是因为它就在局域网里，查询走的是内网交换机，延迟通常低于1ms。可控是因为你能自己决定哪个域名解析到哪个IP段，还能根据来源IP做视图解析——研发网段查git.internal返回测试环境，办公网段查同一个域名返回生产环境。这种玩法公网DNS给不了。

那些年踩过的坑

最经典的是DNS缓存。改了一条A记录，以为立刻生效，结果客户端本地缓存还留着旧IP。Windows默认缓存TTL是负缓存15分钟，Linux的nscd更离谱，能缓存到你重启服务。后来学乖了，改完记录先ipconfig /flushdns，再systemctl restart nscd，最后还得在DNS服务器上把SOA的minimum TTL调低。

还有一次更隐蔽的。内网有个服务叫api.pay.local，解析到两台服务器做负载均衡。某天开始间歇性超时，查了半天发现是DNS轮询返回的IP顺序不固定，而其中一台服务器的防火墙规则只允许特定源IP访问。客户端拿到被拒绝的那个IP就超时，拿到另一个就正常。这种问题在公网环境很少见，因为公网DNS通常配合健康检查，内网DNS如果只做简单轮询，就是给自己埋雷。

自己搭还是用现成的

小公司直接上dnsmasq，配置文件就几行，扔在一台Linux跳板机上跑着，够用。中型公司用Windows AD集成的DNS，省事，跟域控绑定，客户端自动注册记录。但AD DNS有个毛病——它默认只允许安全动态更新，非Windows设备想注册个记录得折腾半天Kerberos认证。

大公司通常上BIND或者PowerDNS，配合自研的IPAM系统做自动化。我见过最狠的一家，用Consul做服务发现，内网DNS直接跟Consul联动，服务实例上线自动注册A记录，下线自动删除。开发人员永远不用手动改DNS，也永远不会因为忘删记录导致请求打到已经下线的机器上。

监控比配置更重要

DNS服务器本身不需要多强的CPU和内存，但它对网络质量极其敏感。丢包率超过0.1%就能让整个内网感受到解析变慢。我们现在的做法是：每台DNS服务器上都跑一个dnstop，实时看查询量和响应码分布。再配一个黑盒监控，从不同网段定时dig特定域名，记录解析耗时和返回IP。一旦某个域名解析结果跟预期不符，或者耗时超过阈值，直接电话告警。

还有个细节：内网DNS的日志一定要开查询日志。不是为了审计，是为了排障。当某个服务突然连不上数据库时，第一反应应该是去DNS服务器上grep一下这个服务的主机名，看看它到底解析到了哪个IP。十次里有三次，问题就出在DNS记录被误改或者过期没续上。

内网DNS这东西，说到底是基础设施里的基础设施。它不产出业务价值，但它是所有业务价值的地基。地基裂了，楼越高摔得越惨。