一、DNS 本质:一个分布式数据库 + 缓存系统
完整的DNS查询链路(递归解析)
┌─────────┐ ①查询 ┌──────────┐
│ 浏览器 │──────────→│ 本地缓存 │ 有?直接返回
│ /OS │ └──────────┘
└─────────┘ ↓ 没有
②问本地DNS
(8.8.8.8 / 114.114.114.114)
↓
③本地DNS也没有 → 开始迭代
↓
根服务器(只知道.com在哪)
↓
.com顶级域服务器
↓
example.com权威DNS
↓
返回 A记录 93.184.216.34
二、DNS 记录类型(运维必背)
| 类型 | 全称 | 作用 | 运维场景 |
|---|---|---|---|
| A | Address | 域名→IPv4 | 最常用 |
| AAAA | Quad-A | 域名→IPv6 | 双栈环境 |
| CNAME | Canonical Name | 别名→另一个域名 | CDN、云服务标配 |
| MX | Mail Exchange | 邮件服务器 | 邮件系统 |
| TXT | Text | 任意文本 | SPF、DKIM、域名验证 |
| NS | Name Server | 指定权威DNS | 域名托管 |
| SOA | Start of Authority | 区域权威信息 | 主从同步、刷新时间 |
| PTR | Pointer | IP→域名(反向解析) | 邮件服务器反查 |
| SRV | Service | 服务发现 | K8s、Consul、LDAP |
| CAA | Cert Auth Auth | 指定允许签发证书的CA | HTTPS证书安全 |
三、TTL —— DNS 的”双刃剑”
TTL = Time To Live(秒)
含义:这条记录在缓存中存活多久
| 场景 | TTL 策略 | 原因 |
|---|---|---|
| 日常运行 | 300~3600s | 平衡负载和灵活性 |
| 即将切换IP | 提前改小到 60s | 让旧缓存快速过期 |
| 切换完成后 | 改回正常值 | 避免DNS服务器压力过大 |
| 故障容灾 | 低TTL + 健康检查 | 快速切流 |
💡 经典翻车:改了 DNS 解析,但 TTL 是 86400(24小时),用户24小时内还在访问旧IP
查看TTL:
dig www.baidu.com +noall +answer
# 输出示例:
# www.baidu.com. 300 IN A 180.101.50.242
# ↑ TTL(秒)
四、DNS 排错工具箱(运维必会)
1. dig —— 排错之王
# 基本查询
dig www.example.com
# 只看答案
dig www.example.com +short
# 追踪完整解析链路(排错神器)
dig www.example.com +trace
# 指定DNS服务器查询
dig @8.8.8.8 www.example.com
# 查所有记录
dig example.com ANY +short
# 反向解析
dig -x 93.184.216.34
# 详细计时(看哪里慢)
dig www.example.com +stats
2. nslookup —— 简单快速
nslookup www.example.com
nslookup www.example.com 8.8.8.8
3. host —— 一行搞定
host www.example.com
host -t MX example.com # 查MX记录
host -t NS example.com # 查NS记录
4. 系统级排查
# 看系统用哪个DNS
cat /etc/resolv.conf
# systemd-resolved 环境
systemd-resolve --status
# 清本地DNS缓存
systemd-resolve --flush-caches # systemd
rndc flush # BIND
systemctl restart nscd # nscd
五、高频故障场景与排错思路
场景1:改了 DNS 但不生效
排查清单:
□ TTL 还没过期?→ dig 看 TTL 是否在递减
□ 本地缓存?→ systemd-resolve --flush-caches
□ 浏览器缓存?→ 无痕模式测试
□ /etc/hosts 有硬编码?→ grep 域名 /etc/hosts
□ 运营商DNS缓存?→ dig @运营商DNS 对比 dig @8.8.8.8
场景2:间歇性解析失败
可能原因:
1. 多个NS记录中某个DNS服务器挂了
→ dig @每个NS 逐个测试
2. 权威DNS响应慢,递归服务器超时
→ dig +stats 看 query time
3. 网络丢包导致DNS请求丢失(UDP 53)
→ mtr DNS服务器IP
4. 并发查询被限速
→ 看 DNS 服务器日志
场景3:容器内解析慢/失败
# K8s 里常见问题
# 1. 看 Pod 的 DNS 配置
cat /etc/resolv.conf
# nameserver 通常指向 CoreDNS ClusterIP
# 2. 测试 CoreDNS 是否正常
nslookup kubernetes.default 10.96.0.10
# 3. ndots 配置导致多余查询
# options ndots:5 → 任何域名都先尝试加search后缀
# 解决:pod.spec.dnsConfig.options: { name: ndots, value: "2" }
场景4:DNS 劫持/污染
症状:返回了奇怪的IP(广告页、拦截页)
排查:
□ dig @8.8.8.8 vs dig @本地DNS → 结果不同 = 被劫持
□ 用 DoH/DoT 绕过(见下文)
□ 检查路由器 DNS 设置
六、DNS 安全:DNSSEC / DoH / DoT
| 技术 | 全称 | 解决的问题 | 运维关注 |
|---|---|---|---|
| DNSSEC | DNS Security Extensions | 防篡改、防欺骗 | 签名链验证 |
| DoH | DNS over HTTPS | 防监听、防劫持 | 端口443,防火墙友好 |
| DoT | DNS over TLS | 防监听、防劫持 | 端口853 |
💡 企业内网运维注意:DoH 会绕过内网 DNS 策略,需要管控浏览器 DoH 设置
七、DNS 监控与告警(生产必备)
# 1. 监控解析成功率(定时探测)
dig +short @dns-server example.com || alert
# 2. 监控解析延迟
dig example.com +stats | grep "Query time"
# 3. 监控证书域名解析(防止DNS挂了证书续签失败)
# certbot 依赖 DNS 验证时尤其重要
# 4. 监控 TTL 变化(防止被篡改)
dig +short example.com
# 对比历史值


