修改域名解析后，网站仍然访问旧服务器、部分地区无法打开，或者出现NXDOMAIN、SERVFAIL和“找不到服务器”等错误，通常会被统称为“DNS不生效”。
实际上，DNS解析涉及域名注册商、父域委派、权威DNS服务器、递归解析器、本地系统、浏览器和应用缓存。任意一层配置错误或仍保留旧缓存，都可能让用户获得错误结果。
本文介绍如何使用dig、nslookup、resolvectl和权威服务器查询，判断问题发生在哪一层，并排查A、AAAA、CNAME、NS、TTL、DNSSEC、CDN代理和本地缓存等常见问题。
Table of Contents
Toggle
一、先确认具体是什么现象二、使用dig查看当前解析结果三、区分NOERROR、NXDOMAIN和SERVFAILNOERRORNXDOMAINSERVFAIL四、确认域名实际使用哪一组权威DNS五、直接查询权威DNS服务器六、TTL为什么会影响生效时间七、不同公共DNS为什么返回不同结果八、NXDOMAIN也可能被缓存九、检查A、AAAA和CNAME记录冲突十、确认DNS正确后再检查网站服务十一、检查本地hosts文件十二、清理本地DNS缓存十三、浏览器也可能使用独立DNS十四、检查服务器实际使用的DNS解析器十五、检查53端口的UDP和TCP十六、DNSSEC配置错误十七、检查NS委派和Glue记录十八、CDN代理模式会隐藏源站IP十九、智能解析导致不同地区返回不同结果二十、邮件和验证记录不生效二十一、推荐的完整排查顺序总结
一、先确认具体是什么现象
“解析不生效”可能表现为：
域名仍然返回旧IP。
不同网络返回不同IP。
主域名可以访问，www无法访问。
IPv4正常，IPv6访问异常。
部分地区返回NXDOMAIN。
公共DNS可以解析，公司网络无法解析。
权威服务器结果正确，但本机仍然错误。
修改NS后整个域名无法解析。
开启DNSSEC后返回SERVFAIL。
DNS已经正确，但浏览器仍打开旧网站。
先记录：
出问题的完整域名。
查询的记录类型。
期望值和实际值。
修改时间。
原TTL值和新TTL值。
使用的DNS服务商。
哪些网络或地区出现问题。
不要只说“域名不生效”。example.com、www.example.com、api.example.com和mail.example.com是不同名称，A、AAAA、CNAME、MX和TXT也是不同记录类型。
二、使用dig查看当前解析结果
查询A记录：
dig example.com A
只显示答案：
dig +short example.com A
查询IPv6：
dig +short example.com AAAA
查询CNAME：
dig example.com CNAME
查询名称服务器：
dig example.com NS
查询SOA：
dig example.com SOA
重点观察：
status是NOERROR、NXDOMAIN还是SERVFAIL。
ANSWER SECTION返回的记录是否正确。
TTL还剩多少秒。
响应来自哪个DNS服务器。
响应是否带有aa权威回答标记。
三、区分NOERROR、NXDOMAIN和SERVFAIL
NOERROR
查询成功，但不一定存在所查询类型的记录。
例如域名有A记录但没有AAAA记录，查询AAAA可能返回NOERROR且答案为空。这与整个域名不存在不同。
NXDOMAIN
表示查询的域名不存在。
常见原因：
主机记录没有创建。
域名输入错误。
查询了错误的子域名。
域名未注册或已过期。
父域委派异常。
递归解析器仍缓存之前的不存在结果。
SERVFAIL
表示解析器无法完成解析。
常见原因：
DNSSEC验证失败。
权威服务器无法访问。
NS委派错误。
权威服务器响应不一致。
DNS查询超时。
大型响应无法通过UDP完成，TCP 53又不可用。
看到SERVFAIL时，不要只检查A记录内容。应继续检查权威服务器、DNSSEC和网络可达性。
四、确认域名实际使用哪一组权威DNS
查询父域委派：
dig example.com NS
更直接地从顶级域服务器查询：
dig +trace example.com NS
需要区分：
域名注册商控制台中设置的DNS服务器。
DNS服务商区域内填写的NS记录。
父域实际委派的NS服务器。
真正决定互联网去哪里查询的是父域委派。仅在DNS区域中添加NS记录，不能替代注册商处的名称服务器设置。
如果刚更换DNS服务商，应确认：
注册商处已经填写新NS。
新DNS服务商已经创建完整区域。
所有必要记录已经迁移。
新旧权威服务器在过渡期都能正确回答。
DNSSEC的DS记录已经正确处理。
五、直接查询权威DNS服务器
先获得权威服务器：
dig +short example.com NS
假设返回：
ns1.dns-provider.example.
ns2.dns-provider.example.
分别查询：
dig @ns1.dns-provider.example example.com A
dig @ns2.dns-provider.example example.com A
查询www：
dig @ns1.dns-provider.example www.example.com A
dig @ns2.dns-provider.example www.example.com A
如果所有权威服务器都返回新记录，而公共DNS仍返回旧记录，通常是递归缓存尚未过期。
如果不同权威服务器返回不同结果，应检查：
区域同步是否失败。
是否误用了两组DNS服务商。
某个节点仍加载旧区域。
SOA序列号是否一致。
地理线路或智能解析规则是否符合预期。
比较SOA：
dig @ns1.dns-provider.example example.com SOA +short
dig @ns2.dns-provider.example example.com SOA +short
六、TTL为什么会影响生效时间
TTL表示递归解析器可以缓存记录的时间，单位为秒。
例如原记录TTL为：
86400
表示解析器可以缓存24小时。即使你把新记录的TTL改为300秒，已经缓存的旧记录仍可能按照原来的86400秒继续存在。
正确的迁移流程通常是：
在变更前至少一个原TTL周期降低TTL。
等待旧的高TTL缓存自然过期。
修改目标记录。
观察不同解析器和权威服务器。
服务稳定后再恢复合理TTL。
TTL越低不一定越好。过低会增加权威DNS查询量，也可能增加缓存未命中时的解析延迟。
七、不同公共DNS为什么返回不同结果
分别查询多个递归解析器：
dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A
dig @9.9.9.9 example.com A
如果只有某个解析器返回旧值，可能是该解析器仍保留未过期缓存。
如果多个公共解析器都返回错误结果，但直接查询权威DNS正确，需要确认：
权威记录是否刚刚修改。
旧TTL是否较长。
是否存在负缓存。
权威服务器是否偶尔返回旧数据。
DNSSEC是否导致验证解析器拒绝结果。
如果所有公共DNS都错误，直接查询权威DNS也错误，问题通常在权威配置或父域委派，而不是“全球传播速度”。
八、NXDOMAIN也可能被缓存
DNS不仅缓存成功结果，也会缓存域名不存在等否定答案。
例如先访问一个尚未创建的子域名：
api.example.com
递归解析器返回并缓存NXDOMAIN。随后即使添加了记录，该解析器仍可能在否定缓存到期前继续返回不存在。
排查方法：
dig @authoritative-server api.example.com A
dig @8.8.8.8 api.example.com A
如果权威DNS已有记录，但递归解析器仍返回NXDOMAIN，应查看SOA中的否定缓存相关时间，并等待缓存过期或使用解析器提供的缓存刷新工具。
频繁刷新浏览器无法清除公共递归解析器缓存。
九、检查A、AAAA和CNAME记录冲突
常见错误包括：
A记录指向新服务器，AAAA仍指向旧服务器。
www配置了CNAME，但目标域名解析错误。
同一主机名同时配置不兼容的CNAME和其他记录。
CDN要求使用CNAME，但实际填写成A记录。
主域名使用了服务商不支持的CNAME。
分别查询：
dig +short example.com A
dig +short example.com AAAA
dig +short www.example.com CNAME
dig +short www.example.com A
dig +short www.example.com AAAA
现代系统可能优先使用IPv6。A记录修改正确但AAAA仍指向旧地址时，部分用户会访问旧服务器或完全无法连接。
如果不使用IPv6，不要保留无效AAAA记录。
十、确认DNS正确后再检查网站服务
DNS只负责把名称解析成目标地址。解析结果正确，不代表网站服务一定正常。
测试目标IP：
curl -I http://203.0.113.10/ -H 'Host: example.com'
测试HTTPS并保留正确SNI：
curl -vk --resolve example.com:443:203.0.113.10 https://example.com/
如果DNS已经返回新IP，但浏览器仍显示旧网站，可能是：
CDN仍缓存旧页面。
新服务器虚拟主机没有配置域名。
反向代理仍指向旧上游。
浏览器缓存或Service Worker缓存。
HTTPS证书或SNI配置错误。
新IP又通过代理回到旧源站。
不要把所有网站访问异常都归因于DNS。
十一、检查本地hosts文件
Linux和macOS：
/etc/hosts
Windows：
C:\Windows\System32\drivers\etc\hosts
检查是否存在固定映射：
grep -n 'example.com' /etc/hosts
hosts通常优先于DNS查询。开发测试时遗留的旧IP会让本机始终访问错误服务器，而其他用户访问正常。
Windows可以使用：
Select-String -Path C:\Windows\System32\drivers\etc\hosts -Pattern example.com
十二、清理本地DNS缓存
使用systemd-resolved的Linux：
sudo resolvectl flush-caches
查看缓存统计：
resolvectl statistics
重启systemd-resolved：
sudo systemctl restart systemd-resolved
Windows：
ipconfig /flushdns
macOS不同版本的缓存服务可能不同，通常可以刷新本地DNS缓存并重启相关解析服务。
清理本地缓存只能影响当前设备，无法清除运营商、企业网络或公共DNS解析器中的缓存。
十三、浏览器也可能使用独立DNS
现代浏览器可能启用DNS over HTTPS，使用与操作系统不同的解析器。
因此可能出现：
dig结果正确，但浏览器仍错误。
系统DNS已切换，浏览器继续使用DoH。
公司内网域名只能由企业DNS解析，但浏览器绕过了企业DNS。
排查时可以：
使用无痕窗口测试。
彻底退出并重新打开浏览器。
检查浏览器安全DNS设置。
清除浏览器DNS和连接池缓存。
对比curl、浏览器和dig结果。
如果网站使用Service Worker，还应检查离线缓存和前端缓存策略。
十四、检查服务器实际使用的DNS解析器
查看：
cat /etc/resolv.conf
使用systemd-resolved：
resolvectl status
resolvectl query example.com
需要注意：
/etc/resolv.conf可能是符号链接。
VPN可能给特定域名配置独立DNS。
容器可能使用Docker内置解析器。
Kubernetes Pod通常通过CoreDNS解析。
云服务器可能使用VPC内网DNS。
本机dig @8.8.8.8正确，不代表应用实际使用8.8.8.8。应确认应用所在网络命名空间和容器的实际解析路径。
十五、检查53端口的UDP和TCP
DNS通常先使用UDP 53。当响应较大或被截断时，客户端可能改用TCP 53。
分别测试：
dig @ns1.dns-provider.example example.com A
dig @ns1.dns-provider.example example.com A +tcp
如果UDP成功但TCP失败，DNSSEC、TXT和大型响应可能出现间歇性故障。
检查防火墙和安全组是否允许：
入站UDP 53。
入站TCP 53。
出站UDP和TCP 53。
返回流量。
权威DNS服务器不能只允许UDP 53。可靠DNS服务必须能够处理TCP查询。
十六、DNSSEC配置错误
启用DNSSEC后，父域会保存DS记录，权威DNS提供匹配的DNSKEY和签名。
常见错误：
更换DNS服务商后旧DS记录没有删除。
新DNS服务商的DNSKEY与父域DS不匹配。
区域签名过期。
部分权威节点返回不同DNSSEC数据。
算法或签名配置错误。
典型表现：
验证型公共DNS返回SERVFAIL。
禁用DNSSEC验证后可以获得普通记录。
部分不验证DNSSEC的解析器仍然可以访问。
查询：
dig example.com A +dnssec
dig example.com DS
dig example.com DNSKEY +dnssec
如果更换DNS服务商，应按照服务商迁移流程处理DS和DNSKEY。不要在不了解密钥状态时随意添加DS记录。
十七、检查NS委派和Glue记录
如果权威名称服务器位于被委派域名自身，例如：
ns1.example.com
父域通常需要提供Glue地址，避免解析ns1.example.com时形成循环依赖。
使用：
dig +trace example.com
检查：
父域返回的NS是否正确。
NS主机名能否解析。
Glue地址是否正确。
权威服务器是否监听这些地址。
子域区域内的NS是否与父域委派一致。
父域与子域NS不一致可能造成lame delegation、间歇解析失败或不同解析器行为不一致。
十八、CDN代理模式会隐藏源站IP
使用CDN或代理DNS时，域名返回CDN节点地址而不是源站IP通常是正常现象。
需要确认：
记录是否开启代理。
CDN回源地址是否正确。
回源Host和协议是否正确。
CDN是否仍缓存旧配置。
源站防火墙是否允许CDN节点。
用户是否绕过CDN直接访问源站。
不要因为dig没有返回源站IP就判断解析错误。应根据DNS记录的代理状态和CDN产品设计判断。
如果要测试源站：
curl -vk --resolve example.com:443:SOURCE_IP https://example.com/
十九、智能解析导致不同地区返回不同结果
DNS服务商可能根据运营商、地区、国家、客户端子网或线路返回不同答案。
如果不同地区结果不同，应检查：
是否启用了线路解析。
默认线路是否存在。
某些线路记录是否仍指向旧IP。
海外和国内记录是否分别配置。
CDN是否根据ECS返回不同节点。
监控切换是否改变了记录。
直接查询权威服务器时，查询来源和EDNS Client Subnet可能影响结果。不要只用单一网络测试智能解析。
二十、邮件和验证记录不生效
MX、TXT、SPF、DKIM和域名验证也受DNS缓存影响。
查询MX：
dig example.com MX
查询TXT：
dig example.com TXT
查询DKIM：
dig selector1._domainkey.example.com TXT
常见错误：
主机记录位置填写错误。
TXT值被额外添加引号或空格。
DKIM选择器不正确。
SPF拆成多条冲突记录。
MX记录目标填写了IP而不是主机名。
验证平台查询的是主域名，但记录添加在www。
应按照服务商给出的完整主机名和记录类型逐项核对。
二十一、推荐的完整排查顺序
明确出问题的完整域名和记录类型。
使用dig查看状态码、答案和TTL。
查询A、AAAA和CNAME，排除IPv6或别名问题。
查询NS，确认父域实际委派。
使用dig +trace检查完整解析链。
分别直接查询每台权威DNS服务器。
比较权威服务器的记录和SOA序列号。
对比多个公共递归解析器。
根据原TTL判断是否仍处于缓存期。
检查NXDOMAIN否定缓存。
检查本地hosts、系统DNS和浏览器DoH。
清理本地缓存后重新测试。
检查UDP和TCP 53可达性。
出现SERVFAIL时检查DNSSEC和NS委派。
检查CDN代理、智能线路和回源配置。
DNS结果正确后继续测试Web服务器和HTTPS。
总结
域名解析不生效不能只用“等待传播”解释。正确的排查方法是逐层比较控制台配置、父域委派、权威DNS回答、公共递归缓存和本地应用结果。
如果权威DNS仍返回错误记录，应修复DNS区域或委派；如果权威DNS正确而公共解析器返回旧值，应结合原TTL和否定缓存等待更新；如果返回SERVFAIL，则需要重点检查DNSSEC、权威服务器可达性和TCP 53。
DNS排查最有价值的命令是dig +trace和直接查询每台权威服务器。它们可以把模糊的“解析没生效”，转换成明确的委派、权威记录、缓存或客户端问题。