域名内网请求，说到底就是局域网里的设备向内部DNS服务器要“门牌号”的过程；它和公网解析的最大不同，在于查询路径更短、可控性更强，而绝大多数故障都出在转发配置或递归超时上。
内网域名解析失败怎么办：先查本机、网关和上游DNS
很多朋友一上来就盯着应用日志和代码框架,结果折腾半天，问题其实在DNS那一层，遇到内网域名解析失败，不要急，按照下面这个顺序排查，通常几分钟就能定位。
域名内网请求怎么排查：从Ping到抓包的三步走
第一步，确认本机的DNS指向。
在Windows上打开命令提示符,运行ipconfig /all，看“DNS服务器”那一行是不是指向你们内网DNS的IP，比如10.0.0.53，如果指向的是192.168.1.1这种家用网关地址，那多半是从DHCP里自动分配来的，先手动改掉再说。
Linux和macOS用户可以直接看/etc/resolv.conf，里面nameserver字段就是当前生效的DNS，注意，如果你的服务器是云主机或者容器，这个文件可能被云平台或Kubernetes重写过，改之前先确认是谁在管它。
第二步，用nslookup直接问内网DNS。
nslookup your.internal.domain 10.0.0.53
看到返回Address: 10.0.1.25这种内网IP，说明记录存在，解析成功，如果返回Server: Unknown或者直接Request timed out，问题出在“问”这个环节上也就是你的DNS服务器与上游之间的链路。
第三步，用dig看递归路径。
dig +trace your.internal.domain
看它从根域名服务器一路查下来,是走到了你们自己的权威DNS，还是被公网递归服务器“截胡”了，内网域名解析失败最常见的原因之一，就是内网DNS把不该转发的请求转发到了公网，结果公网递归器回了一个NXRCODE，客户端就认为域名不存在。
别把缓存刷新当万灵药
每次出问题就ipconfig /flushdns，这属于治标不治本，缓存刷新只能清除本机缓存，如果内网DNS服务器自身还缓存着旧记录，你刷新一百遍也没用。
务实一点的做法是：
- 在Windows上用
Clear-DnsServerCache清除服务器端缓存； - 在Linux上用
systemd-resolve --flush-caches刷新systemd-resolved； - 如果是dnsmasq,直接
kill -HUP $(cat /var/run/dnsmasq.pid)让进程重新加载配置。
内网域名解析失败怎么办，核心思路永远是先确认“客户端问的是谁”，再确认“服务器答了什么”，只要这两条链路是清晰的，问题就解决了一半。
内网域名解析和公网解析有什么区别：一张表看懂
不少人习惯用8.8.8.8或者223.5.5.5这类公共DNS来解析内网域名，这是内网环境里最大的一个坑，你问公网DNS“company.local在哪”，它根本不认识，因为它不是这个域名的权威服务器。
内网域名解析和公网解析的区别,远不止“服务器不同”这么简单。
一个维度是可见性：公网解析结果对全网公开，内网解析结果通常只在特定网段可用，另一个维度是查询路径：公网权威服务器与递归服务器可能相隔好几个网络节点，内网解析往往是“同机房一跳”甚至“同进程内查内存”。
| 对比维度 | 公网域名解析 | 内网域名解析 |
|---|---|---|
| 查询路径 | 从根域逐级递归，可能跨多个网络节点 | 客户端→内网DNS，通常局域网内完成 |
| 记录可见性 | 公网全网一致 | 按网络区域返回不同结果 |
| TTL策略 | 保守设计，通常300~600秒 | 可按发布频率灵活调至60秒甚至更低 |
| 常见故障 | 污染、递归超时、权威节点故障 | 转发规则写错、上游DNS不可达、记录被缓存覆盖 |
核心区别在于“谁来回答”和“回答多快”
公网DNS遇到不知道的域名,会帮你从根服务器问起；内网DNS遇到内网域名，应该直接查自己的区域文件或者转发给内网权威服务器，前者是“通用服务”，后者是“定向服务”，定位完全不同。
行业共识认为,内网域名系统最容易出问题的地方，恰恰不在权威服务器本身，而在递归转发的超时配置，很多内网DNS转发到公网上游时，把超时时间默认设成5秒或更长，一旦上游抖动，所有内部请求都会跟着遭殃。
记录类型和视图机制也不一样
公网解析一般用A记录、CNAME记录就够用了，偶尔加个MX记录，内网环境则会用到更细的视图功能，比如按源IP段返回不同结果，同一个域名，办公网访问解析到192.168.10.10，服务器网段访问解析到10.10.10.10，这在BIND和CoreDNS里都能配置。
还有一个不容忽视的点：现在主流浏览器和操作系统在启用DoH（DNS over HTTPS）之后，可能会绕过系统配置的DNS服务器，这会让部分人以为“内网域名解析失败了”，其实只是流量走了HTTPS通道，根本没经过内网DNS。
内网API域名请求慢如何优化：从缓存到转发的落地配置
如果说“解析失败”是急性病，解析慢”就是慢性病，它不会让服务直接不可用，但会造成每次API调用都多出几十毫秒的延迟，接口量一上来，整体体验就差远了。
内网域名请求转发配置：dnsmasq与CoreDNS实践
小规模内网用dnsmasq是最省事的,它的转发规则很直白：
# 把.internal后缀的域名全部转给内网权威DNS server=/internal/10.0.0.53 # 其余请求走公共DNS server=223.5.5.5 server=119.29.29.29 # 固定某个内网域名到指定IP，绕开权威服务器 address=/gitlab.internal/192.168.1.30
这套配置解决了一个常见痛点：让内网API域名请求走内网权威服务器，同时把其余流量交给公共DNS兜底，注意不要把server=/internal/10.0.0.53里的目标地址写成dnsmasq自己机器的地址，否则会形成递归死循环。
中等规模或容器里的场景,CoreDNS更合适，它支持动态配置和插件化转发：
.:53 {
forward . 192.168.1.10 {
policy random
}
cache 60
}
cache 60表示缓存60秒，你可以把这个值调大或者调小，取决于域名对应的后端服务变更频率，对于版本发布频繁的微服务，缓存时间设太长会导致新Pod上线后流量还打到旧IP上；设太短则会让每个请求都穿透到上游。
TTL调优与预解析策略
内网API域名请求慢,很多时候不是网络慢，而是TTL太长导致“改了解析却迟迟不生效”，或者TTL太短让DNS缓存形同虚设。
实务中的参考做法：
- 对频繁变动的服务域名，TTL设60秒，发布后最多等1分钟就能切流量；
- 对相对静态的内部中间件域名，比如数据库、消息队列，TTL可以设600秒到1800秒；
- 对客户端应用，可以在启动时提前预解析所有用到的内网API域名，把首次查询的延迟消化在加载阶段。
有经验的运维会发现,内网API域名请求慢还有一种隐蔽情况：客户端librarary对DNS查询结果做了二次验证，比如Java的JVM在解析某些地址时会顺手做一次反向解析（PTR查询），如果PTR记录缺失，这个反向查询会等超时才放弃，表现就是“每次调用API都慢半拍”。
大规模环境里的架构选择
对于超过几百台服务器的内网,单台dnsmasq可能扛不住突发解析流量，很多团队会搭一套“两级DNS”结构：
- 一级缓存节点,部署在每个子网或机架，只做缓存和转发；
- 一级权威节点,保存所有内网域名记录，接收来自缓存节点的查询。
把内网API域名请求转发配置放到缓存节点上,权威节点只负责回答自己辖区内的记录，互不干扰，这样既保证了高可用，又让故障范围被限制在局部。
业内专家指出,内网DNS的架构设计不需要追求复杂，把“递归”和“权威”拆开，就能规避掉大多数配置冲突和性能瓶颈。
回到最初的观点：域名内网请求看似基础，却是所有内部服务的“总机台”，你能做的不是祈祷它不出问题，而是把排查步骤写进文档、把TTL调成匹配业务节奏的值、把转发规则画成拓扑图，把这些事情做完，内网解析慢和解析失败的问题，基本就离你远去了。
域名内网请求的常见问题与解决办法
内网没有外网出口，域名解析还搞得起来吗？
完全可以,在没有外网权限的离线内网里，自建一台权威DNS服务器，把所有内网域名的A记录、CNAME记录写在它的区域文件里，客户端的DNS地址统一指向这台服务器就行，它不需要向外转发任何请求，因为它本身就是“最终答案”，唯一要留心的是定期备份区域文件，别让那台服务器变成单点故障。
公网DNS能用来解析内网域名吗？
不能,公网DNS没有你们内网域名的记录授权，它查不到就会返回“域名不存在”的结果，而且这个否定结果会被缓存一段时间，即使你的内网域名和公网域名长得一样，公网解析出来的也是公网IP，客户端根本访问不到内部服务，更稳妥的做法是把内外网解析彻底分开，互不干扰。
内网DNS服务器自己解析很慢，该怎么查？
先确认这台服务器的上游配置是否合理,如果你把它指向了一个公网DNS，而公网DNS又被墙或者限速，解析自然慢，用一个比较巧的方法：在服务器上执行dig @127.0.0.1 your.internal.domain和dig @127.0.0.1 baidu.com，对比两者的响应耗时，内网域名慢，说明权威链路有问题；公网域名慢，说明上游递归链路有问题，接着用抓包工具看UDP 53端口的往返时间，就能判断延迟消耗在哪一跳上，内网解析器的记录会暴露内部网络拓扑，建议与出口策略配合限制查询来源。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/654142.html
