Metaphor

DNS深入解析

7分钟阅读

概述

DNS（Domain Name System）是互联网的基础设施之一，将人类可读的域名（如example.com）转换为计算机可理解的IP地址（如93.184.216.34）。每次网站访问、API调用、邮件发送都始于DNS查询。1

DNS层级结构

DNS采用分层、分布式数据库架构：

                    ┌─────────────┐
                    │   Root      │  根服务器（13个）
                    │   Servers   │  a-m.root-servers.net
                    └──────┬──────┘
                           │
                           ▼
         ┌─────────────────┼─────────────────┐
         │                 │                 │
    ┌────┴────┐      ┌────┴────┐       ┌────┴────┐
    │  .com   │      │  .org   │       │  .cn    │  TLD服务器
    └────┬────┘      └────┬────┘       └────┬────┘
         │                 │                 │
         ▼                 ▼                 ▼
    ┌────────┐       ┌────────┐        ┌────────┐
    │example │       │ wikipedia│      │baidu   │ 权威服务器
    │.com    │       │.org    │        │.cn     │
    └────────┘       └────────┘        └────────┘

三层结构

  1. 根域（Root Zone）：管理TLD服务器，仅回答”谁负责这个TLD”
  2. 顶级域（TLD）：管理二级域名（如.com、.org、.cn）
  3. 权威服务器（Authoritative NS）：域名的最终数据源

解析过程

当查询example.com时，完整流程如下：

1. Client → Recursive Resolver: "example.com是什么？"
              ↓
2. Resolver → Root Server: "谁负责.com？"
              Root → Resolver: "问a.gtld-servers.net"
              ↓
3. Resolver → TLD Server (.com): "谁负责example.com？"
              TLD → Resolver: "问ns1.example.com (93.184.216.34)"
              ↓
4. Resolver → Authoritative NS: "example.com的A记录是什么？"
              Auth NS → Resolver: "A记录: 93.184.216.34"
              ↓
5. Resolver → Client: "IP地址是93.184.216.34"

使用dig查看

# 完整递归跟踪
dig +trace example.com
 
# 快速查询
dig +short example.com A
 
# 查看DNS响应详情
dig example.com ANY

记录类型

DNS有数十种记录类型，以下是最常用的几种：

类型用途示例
A域名→IPv4example.com. 300 IN A 93.184.216.34
AAAA域名→IPv6example.com. 300 IN AAAA 2606:2800:220:1::
CNAME域名别名www.example.com. 300 IN CNAME example.com.
MX邮件交换example.com. 300 IN MX 10 mail.example.com.
NS名称服务器example.com. 300 IN NS ns1.example.com.
TXT文本记录example.com. 300 IN TXT "v=spf1 include:_spf.example.com ~all"
SRV服务定位_http._tcp.example.com. 300 IN SRV 0 5 443 api.example.com.

CAA记录（SSL证书授权）

# 限制证书颁发机构
example.com. 300 IN CAA 0 issue "letsencrypt.org"
example.com. 300 IN CAA 0 issuewild ";"

DNS查询类型

递归查询 vs 迭代查询

  • 递归查询：客户端→递归解析器，解析器完成全部查询工作
  • 迭代查询：解析器→根→TLD→权威，每步返回下一个服务器的地址

查询工具

# 系统解析器查询
nslookup example.com
 
# 直接查询权威服务器
dig @8.8.8.8 example.com
 
# 查看SOA（起始授权记录）
dig example.com SOA

DNS缓存

多层缓存

  1. 浏览器缓存：Chrome等浏览器维护自己的DNS缓存
  2. 操作系统缓存：OS级别的DNS缓存
  3. 递归解析器缓存：1.1.1.1、8.8.8.8等公共解析器
# 清除Chrome DNS缓存
chrome://net-internals/#dns
 
# 刷新系统DNS缓存 (macOS)
sudo dscacheutil -flushcache
 
# 刷新系统DNS缓存 (Linux)
sudo systemd-resolve --flush-caches

TTL（生存时间）

TTL决定缓存有效期：

example.com.  300  IN  A  93.184.216.34
         ↑
      300秒 = 5分钟
  • 短TTL：频繁变更的记录，便于快速切换
  • 长TTL：降低解析延迟，减少查询负载

DNS安全

DNSSEC（DNS安全扩展）

DNSSEC通过加密签名防止DNS欺骗：

Query: example.com DNSKEY
Response: 
  - DNSKEY (公钥)
  - RRSIG (记录签名)

验证链：

DNSKEY → ZSK (Zone Signing Key)
      → KSK (Key Signing Key)
      → DS记录 → 父区域

# 检查DNSSEC
dig +dnssec example.com A
 
# 验证签名
dnssec-dsfromkey example.com

DNS隐私

DoH（DNS over HTTPS）

HTTPS加密的DNS查询：

https://dns.google/resolve?name=example.com&type=A

浏览器/系统配置：

  • Chrome: 设置 → 安全 → 使用安全DNS
  • Firefox: 设置 → 网络设置 → 启用DoH

DoT（DNS over TLS）

TLS加密的DNS查询：

dns.google:853

DNS过滤与监控

# 使用OpenDNS过滤
8.8.8.8        # Google DNS
1.1.1.1        # Cloudflare DNS
208.67.222.123 # OpenDNS FamilyShield

常见问题与调试

NXDOMAIN

“域名不存在”不一定意味着域名未注册：

  • 域名确实不存在
  • 权威服务器配置错误
  • 递归解析器缓存过期记录

SERVFAIL

通常原因：

  • DNSSEC验证失败
  • 权威服务器不可达
  • 网络连接问题

调试命令

# 完整跟踪
dig +trace +nodnssec example.com
 
# 检查传播
dig @1.1.1.1 example.com
 
# DNS检查工具
whatsmyresolver.org
dnschecker.org

DNS与CDN的关系

DNS是CDN的关键入口：

用户 → DNS查询 → CDN返回边缘节点IP → 用户直接访问边缘服务器

CDN使用DNS实现：

  • 地理路由：根据用户位置返回最近节点
  • 负载均衡：分散流量到多个节点
  • 故障转移：某节点故障时切换到其他节点

性能优化

减少DNS查询

  1. 域名收敛：减少页面使用的独立域名数量
  2. 预解析：<link rel="dns-prefetch" href="//example.com">
  3. 持久连接：复用HTTP连接减少查询
<head>
    <link rel="dns-prefetch" href="//fonts.googleapis.com">
    <link rel="dns-prefetch" href="//www.google-analytics.com">
</head>

优化TTL策略

# 生产环境：长TTL降低查询负载
example.com.  3600  IN  A  93.184.216.34
 
# 变更前：短TTL确保快速生效
example.com.  300   IN  A  93.184.216.35  # 5分钟TTL

zone文件格式

DNS记录的文本表示：

; 区域文件示例
$TTL 3600
example.com.  IN  SOA  ns1.example.com. admin.example.com. (
                2026041301  ; Serial (YYYYMMDDNN)
                3600        ; Refresh (1小时)
                1800        ; Retry (30分钟)
                604800      ; Expire (7天)
                300 )       ; Minimum TTL (5分钟)
 
; 名称服务器
example.com.  IN  NS   ns1.example.com.
example.com.  IN  NS   ns2.example.com.
 
; A记录
@           IN  A    93.184.216.34
www         IN  A    93.184.216.34
api         IN  A    93.184.216.35
 
; 邮件记录
@           IN  MX   10 mail.example.com.
mail        IN  A    93.184.216.36

最佳实践

  1. 使用可靠的递归解析器：1.1.1.1、8.8.8.8或自建
  2. 启用DNSSEC：防止DNS欺骗攻击
  3. 监控DNS健康：定期检查解析延迟和可用性
  4. 合理设置TTL：平衡灵活性和性能
  5. 使用预解析：对关键域名提前解析
  6. 限制域名数量：减少DNS查询开销

参考资料

Footnotes

  1. DNS Resolution: The Full Picture — krowdev ↩

关系图谱

反向链接