本地DNS缓存的作用不可小看
在企业内部网络中，员工每天打开OA系统、内部Wiki、文件服务器时，其实都在频繁依赖域名解析。比如输入 http://wiki.corp.com，系统需要先通过DNS查出对应的IP地址。如果每次请求都要走一遍完整的DNS查询流程，不仅慢，还会加重网络负担。
这时候，本地操作系统和内网DNS服务器的缓存机制就派上用场了。当第一次成功解析某个内网域名后，结果会被暂时存下来，后续访问直接从缓存读取，响应速度从几百毫秒降到几毫秒，体验明显更流畅。
缓存时间设置不当带来的问题
但缓存也不是万能的。TTL（Time to Live）设置过长，会导致服务迁移后客户端仍然指向旧IP。例如，IT部门把内部报表系统从192.168.10.20迁移到192.168.10.35，虽然DNS记录已更新，可部分电脑仍连不上——原因就是本地缓存还没过期。
这时候排查就得一步步来：先看是不是本机缓存的问题。Windows用户可以运行 ipconfig /displaydns 查看当前缓存，用 ipconfig /flushdns 清除；Linux或macOS则常用 sudo dscacheutil -flushcache 或重启nscd服务。
内网DNS服务器的缓存策略
除了终端，企业通常会部署自己的内网DNS服务器（如BIND或Windows Server DNS）。这类服务器也会缓存上游和内部域名记录。合理配置TTL值很关键。对于变动频繁的测试环境，可以把TTL设成60秒；而稳定的内部服务可以设为几小时。
举个例子，某次上线新版本API服务，前端应用始终调用不到新的后端节点。排查发现是内网DNS缓存了旧A记录。运维人员临时将TTL改为30秒并刷新主从同步，问题才得以缓解。
避免缓存污染的小技巧
有时候，错误的缓存条目会“赖着不走”。比如误配置的CNAME指向了一个不存在的地址，即使修正后，部分客户端可能还在用错的记录。这时候除了清缓存，还可以在关键服务前加IP直连的Hosts绑定做临时过渡。
开发测试阶段，不少人会在本地Hosts文件里写：
192.168.10.50 api.dev.corp.com企业网络不像公网那样容忍高延迟，每一个环节的优化都会叠加出整体体验的提升。DNS缓存看似是个小角色，但在内网访问中，它常常是“快”与“卡”的分水岭。