域名解析不生效怎么办？DNS缓存、TTL与故障排查教程

修改域名解析后，网站仍然访问旧服务器、部分地区无法打开，或者出现NXDOMAIN、SERVFAIL和“找不到服务器”等错误，通常会被统称为“DNS不生效”。

实际上，DNS解析涉及域名注册商、父域委派、权威DNS服务器、递归解析器、本地系统、浏览器和应用缓存。任意一层配置错误或仍保留旧缓存，都可能让用户获得错误结果。

本文介绍如何使用dig、nslookup、resolvectl和权威服务器查询，判断问题发生在哪一层，并排查A、AAAA、CNAME、NS、TTL、DNSSEC、CDN代理和本地缓存等常见问题。

Table of Contents

一、先确认具体是什么现象

“解析不生效”可能表现为：

域名仍然返回旧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为：

表示解析器可以缓存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