关于域名与DNS
什么是DNSSEC?验证结果的含义与局限
说明有效、未配置、验证失败与无法判断的区别,以及DS、DNSKEY和注册信息的差异。
更新日期: 2026年10月9日
DNSSEC通过数字签名帮助验证DNS数据是否由负责区域发布,但它不加密DNS通信。
在NetKarte中
在DNSSEC检查输入域名或主机名,完成认证后搜索。应查看状态与验证结果,不能仅因存在DS或DNSKEY就判断验证成功。
NetKarte使用Cloudflare的验证解析器。当DS、DNSKEY和SOA响应正常,存在DS和DNSKEY,并且三个响应均带有AD(Authenticated Data)时,显示“有效”。NetKarte不会独立验证全部签名。
未返回DS且相关查询正常响应时显示“未设置”。此判断不要求AD,也不表示NetKarte自身验证了带签名的不存在证明。带有特定DNSSEC扩展错误的SERVFAIL显示为“验证失败”,证据不足时显示“无法判断”。查询本身失败时,也可能显示获取错误。
注意事项
DNSSEC验证DNS数据真实性,但不加密查询。验证成功也不保证网站整体安全,TLS证书与应用安全属于不同层面。
先读状态,再看记录
输入名称后,先确认输入主机名与判定区域。子域名可能通过SOA找到另一个区域。先读状态与验证结果,再看DS和DNSKEY。
DS的Key Tag、Algorithm、Digest Type、Digest要按同一记录阅读;DNSKEY的Flags、Protocol、Algorithm、Key Tag也一样。换钥等过程可能出现多条DS或密钥,不能凭数量判断异常。目前不显示公钥全文。
与注册信息不同的原因
域名查询显示注册服务公开数据,DNSSEC检查使用当前DNS响应及解析器验证。来源与区域可能不同,信息缺失不等于验证失败。失败时,将判定区域和状态告知DNS管理员,以检查签名及父区域DS。
参考资料
- IETF / RFC Editor: RFC 4033: DNS Security Introduction and Requirements (外部网站)确认日期: 2026-10-09
- IETF / RFC Editor: RFC 4034: Resource Records for the DNS Security Extensions (外部网站)确认日期: 2026-10-09
- IETF / RFC Editor: RFC 4035: Protocol Modifications for DNSSEC (外部网站)确认日期: 2026-10-09
- IETF / RFC Editor: RFC 8484: DNS Queries over HTTPS (外部网站)确认日期: 2026-10-09