【网络工程】DNS 故障排查实战：从超时到劫持

# 原因一: 本地 DNS 配置错误
cat /etc/resolv.conf
# 检查 nameserver 是否可达
ping -c 1 <nameserver_ip>

# 原因二: 防火墙阻断 UDP 53
# 某些防火墙会限制或阻断 DNS UDP 流量
# 尝试 TCP 查询
dig @8.8.8.8 example.com +tcp +time=5
# 如果 TCP 成功但 UDP 超时 → UDP 被防火墙阻断

# 原因三: MTU 问题导致大 DNS 包被丢弃
# DNSSEC 或 EDNS0 响应可能超过 MTU
dig @8.8.8.8 example.com +bufsize=512 +time=5
# 限制 EDNS0 缓冲区大小，避免大包
dig @8.8.8.8 example.com +noedns +time=5
# 完全禁用 EDNS0

# 原因四: 递归解析器过载
# 检查解析器的负载指标（如果有权限）
ss -ulnp | grep :53
# 查看 DNS 端口的连接队列

# 原因五: conntrack 表满（常见于高流量环境）
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
# 如果 count 接近 max → conntrack 表满导致新 DNS 包被丢弃

# /etc/resolv.conf 的超时相关参数
nameserver 8.8.8.8
nameserver 1.1.1.1
options timeout:2    # 每次查询超时 2 秒（默认 5 秒）
options attempts:3   # 每个 nameserver 重试 3 次（默认 2 次）
options rotate       # 轮询多个 nameserver（而非只用第一个）

# 总超时时间 = timeout × attempts × nameserver数量
# 默认: 5 × 2 × 2 = 20 秒
# 优化后: 2 × 3 × 2 = 12 秒

# 但要注意: 缩短超时可能导致在高延迟网络中
# 本应成功的查询被提前放弃

# 第一步: 确认域名是否真的不存在
dig example.com @8.8.8.8
# status: NXDOMAIN → 在 Google DNS 也不存在

# 第二步: 查询权威服务器
dig example.com NS
# 找到权威服务器
dig example.com @ns1.example.com
# 如果权威服务器也返回 NXDOMAIN → 域名确实不存在或记录未配置

# 第三步: 检查域名注册状态
whois example.com
# 查看域名是否已注册、是否过期
# Status: ok / clientTransferProhibited → 正常
# Status: redemptionPeriod → 域名已过期，在赎回期
# 无结果 → 域名未注册

# 场景: 刚添加了 DNS 记录，但还是返回 NXDOMAIN

# 原因: 否定缓存（Negative Caching）
# 之前的 NXDOMAIN 被递归解析器缓存了
# 缓存 TTL 由 SOA 记录的 minimum 字段决定

dig example.com SOA
# example.com. 86400 IN SOA ns1.example.com. admin.example.com. (
#   2025080101 3600 900 604800 300 )
#                                    ^^^ 否定缓存 TTL = 300 秒

# 解决方案:
# 1. 等待否定缓存过期（这里是 300 秒 = 5 分钟）
# 2. 使用其他递归解析器验证（没有缓存的解析器）
dig @1.1.1.1 newrecord.example.com
# 3. 如果你管理递归解析器，可以手动清除缓存
rndc flush  # BIND
unbound-control flush newrecord.example.com  # Unbound

# 步骤一: 确认是否所有递归解析器都返回 SERVFAIL
dig example.com @8.8.8.8      # Google
dig example.com @1.1.1.1      # Cloudflare
dig example.com @208.67.222.222  # OpenDNS

# 全部 SERVFAIL → 权威服务器问题或 DNSSEC 问题
# 部分 SERVFAIL → 特定递归解析器问题

# 步骤二: 直接查询权威服务器
# 先找到权威服务器
dig example.com NS +norecurse @8.8.8.8
# 然后直接查询
dig example.com @ns1.example.com
# 如果权威服务器正常返回 → 问题在递归解析器端

# 步骤三: 检查 DNSSEC
# 禁用 DNSSEC 验证（Checking Disabled）
dig example.com @8.8.8.8 +cd
# 如果 +cd 返回 NOERROR 但不加 +cd 返回 SERVFAIL
# → DNSSEC 验证失败

# 步骤四: 追踪完整解析链路
dig example.com +trace
# 逐级显示从根到权威的查询
# 在哪一级失败就是哪一级的问题

# DNSSEC 验证失败是 SERVFAIL 的高频原因

# 诊断:
dig example.com @8.8.8.8 +dnssec
# 查看返回的 DNSSEC 记录

# 使用 delv 做详细验证
delv @8.8.8.8 example.com A +rtrace +vtrace
# 输出会显示验证在哪一步失败

# 常见原因:
# 1. RRSIG 签名过期
dig example.com A +dnssec +noall +answer | grep RRSIG
# 检查 RRSIG 中的过期时间

# 2. DS 记录与 DNSKEY 不匹配
dig example.com DS +short  # 父域的 DS
dig example.com DNSKEY +short  # 本域的 DNSKEY
# 用 dnssec-dsfromkey 验证是否匹配

# 3. 算法不支持
dig example.com DNSKEY +short | awk '{print $3}'
# 检查算法编号，确认递归解析器是否支持

# 紧急修复: 如果你是域名管理员
# 选项 A: 修复签名（重新签名区域文件）
# 选项 B: 删除父域的 DS 记录（降级到非 DNSSEC）
#         注意: 这需要等待 DS TTL 过期

# 检查所有权威服务器的可达性和响应
dig example.com NS +short
# ns1.example.com.
# ns2.example.com.

# 逐个测试
for ns in $(dig example.com NS +short); do
  echo "=== $ns ==="
  dig example.com @$ns +time=3 +tries=1 +noall +stats 2>&1 | \
    grep -E "status|Query time|connection timed"
done

# 如果所有 NS 都不可达 → 权威服务器全部故障
# 如果部分 NS 可达 → 部分故障，检查不可达 NS 的网络/服务状态

# 检查权威服务器端口是否开放
nc -zuv ns1.example.com 53 2>&1
# Connection to ns1.example.com 53 port [udp/domain] succeeded!

# 方法一: 多解析器交叉对比
echo "=== 对比多个 DNS 解析器的结果 ==="
for dns in 8.8.8.8 1.1.1.1 208.67.222.222 9.9.9.9; do
  result=$(dig @$dns www.example.com +short +time=3 2>/dev/null)
  echo "$dns: $result"
done
# 如果所有解析器返回相同 IP → 大概率正确
# 如果本地解析器的结果不同 → 可能被劫持

# 方法二: 直接查询权威服务器
# 获取权威 NS
AUTH_NS=$(dig example.com NS +short | head -1)
# 查询权威服务器
AUTH_IP=$(dig @$AUTH_NS www.example.com +short)
# 对比本地解析
LOCAL_IP=$(dig www.example.com +short)

echo "权威: $AUTH_IP"
echo "本地: $LOCAL_IP"
# 不一致 → 可能被劫持

# 方法三: 使用 HTTPS 验证（DoH）
# 绕过本地 DNS，直接通过 HTTPS 查询
curl -s "https://dns.google/resolve?name=www.example.com&type=A" | \
  python3 -c "import sys,json; d=json.load(sys.stdin); \
    print('DoH结果:', [a['data'] for a in d.get('Answer',[])])"

# 方法四: 检查 NXDOMAIN 劫持
# 查询一个确定不存在的域名
dig @<local_dns> thisdomaindoesnotexist12345.com
# 正确结果: NXDOMAIN
# 劫持结果: NOERROR + 某个 IP（ISP 的广告页面）

# 特征一: NXDOMAIN 被重定向
dig nonexistent-domain-xyz.com
# 正常: status: NXDOMAIN
# 劫持: status: NOERROR, A 记录指向 ISP 的搜索/广告页面

# 特征二: HTTP 302 重定向
# ISP 将 DNS 指向自己的服务器，然后返回 302 重定向到广告页
curl -I http://nonexistent-domain-xyz.com
# 劫持时可能返回:
# HTTP/1.1 302 Found
# Location: http://search.isp.com/?q=nonexistent-domain-xyz.com

# 特征三: HTTPS 证书不匹配
# 劫持后访问 HTTPS 网站会出现证书错误
# 因为 ISP 的服务器没有目标域名的合法证书
curl -v https://www.example.com 2>&1 | grep "SSL certificate"
# 证书不匹配 → 可能被劫持

# 特征四: 透明 DNS 代理
# 即使你配置了 8.8.8.8，ISP 仍然拦截端口 53 的流量
dig @8.8.8.8 whoami.ds.akahelp.net TXT +short
# 如果返回的不是 Google 的解析器 IP → ISP 劫持了端口 53

# dig 是最重要的 DNS 诊断工具

# 基本查询
dig example.com                    # 使用默认 DNS
dig @8.8.8.8 example.com          # 指定 DNS 服务器
dig example.com AAAA              # 查询 IPv6 地址
dig example.com MX                # 查询邮件记录
dig example.com ANY               # 查询所有记录类型

# 详细输出控制
dig example.com +noall +answer    # 只显示 Answer 段
dig example.com +noall +authority # 只显示 Authority 段
dig example.com +short            # 最简输出
dig example.com +multiline        # 多行格式（SOA 更易读）

# 追踪完整解析链路
dig example.com +trace
# 从根服务器开始，逐级追踪到权威服务器
# 每一级显示 NS 记录和查询结果

# 非递归查询（直接问，不让服务器递归）
dig @ns1.example.com example.com +norecurse

# DNSSEC 相关
dig example.com +dnssec           # 请求 DNSSEC 记录
dig example.com +cd               # 禁用 DNSSEC 验证

# 反向查询
dig -x 93.184.216.34              # PTR 查询

# 批量查询
dig -f domains.txt +noall +answer # 从文件读取域名批量查询

# TCP 查询
dig example.com +tcp              # 强制 TCP（绕过 UDP 问题）

# 控制超时和重试
dig example.com +time=2 +tries=1  # 2 秒超时，不重试

# EDNS0 控制
dig example.com +bufsize=1232     # 设置 EDNS0 缓冲区
dig example.com +noedns           # 禁用 EDNS0

# 查看 OPT 伪记录（EDNS0 信息）
dig example.com +noall +additional

# Cookie
dig example.com +cookie           # 发送 DNS Cookie

# nslookup（交互式）
nslookup
> server 8.8.8.8
> set type=MX
> example.com
> exit

# nslookup（非交互式）
nslookup example.com 8.8.8.8
nslookup -type=MX example.com

# host（简洁输出）
host example.com
# example.com has address 93.184.216.34
# example.com has IPv6 address 2606:2800:220:1:248:1893:25c8:1946
# example.com mail is handled by 0 .

host -t MX example.com
host -t NS example.com

# host 查反向
host 93.184.216.34

# drill 是 ldns 库的 DNS 查询工具，DNSSEC 支持更好

# 安装
apt-get install -y ldnsutils

# 基本查询
drill example.com
drill @8.8.8.8 example.com A

# DNSSEC 追踪（比 dig 的 DNSSEC 追踪更清晰）
drill -DT example.com
# -D: 启用 DNSSEC
# -T: 追踪信任链
# 输出每一级的 DNSKEY、DS、RRSIG 验证结果
# 最后: ;; Chase successful 或 ;; Chase failed

# DNSSEC 签名验证
drill -S example.com

# 查看系统使用的 DNS 配置
cat /etc/resolv.conf

# 查看 nsswitch 配置（DNS 查询优先级）
grep hosts /etc/nsswitch.conf
# hosts: files dns
# → 先查 /etc/hosts，再查 DNS

# 查看 /etc/hosts 中是否有覆盖
grep example.com /etc/hosts

# systemd-resolved 状态
resolvectl status
resolvectl query example.com    # 使用系统解析器查询
resolvectl statistics            # 缓存统计

# 清除系统 DNS 缓存
# systemd-resolved
resolvectl flush-caches
# nscd
nscd --invalidate=hosts
# Chrome 浏览器
# chrome://net-internals/#dns → Clear host cache

# 跟踪 DNS 查询（实时监控系统的 DNS 行为）
tcpdump -i any -n port 53 -l 2>/dev/null

# 当 DNS 故障且修复需要时间时，用 /etc/hosts 临时绕过

# 1. 确认正确的 IP（通过其他能正常解析的渠道）
dig @8.8.8.8 api.example.com +short  # 从其他 DNS 获取

# 2. 添加到 hosts 文件
echo "93.184.216.34 api.example.com" >> /etc/hosts

# 3. 验证
ping -c 1 api.example.com
# PING api.example.com (93.184.216.34)

# 4. 故障恢复后移除
sed -i '/api.example.com/d' /etc/hosts

# 批量修复（影响多个域名时）
cat >> /etc/hosts << 'EOF'
# === DNS 故障临时修复 2025-08-01 ===
93.184.216.34  api.example.com
93.184.216.35  www.example.com
93.184.216.36  cdn.example.com
# === END DNS 故障临时修复 ===
EOF

#!/bin/bash
# dns_health_check.sh — DNS 健康检查脚本
# 用于 crontab 定期运行或告警触发时手动运行

DOMAINS=(
  "api.example.com"
  "www.example.com"
  "db-primary.internal"
  "redis.internal"
)

DNS_SERVERS=(
  "8.8.8.8"
  "1.1.1.1"
  "10.0.0.2"  # 内部 DNS
)

TIMEOUT=3
ALERT_EMAIL="oncall@example.com"
ISSUES=()

echo "=== DNS Health Check $(date) ==="

for domain in "${DOMAINS[@]}"; do
  echo ""
  echo "--- $domain ---"

  for dns in "${DNS_SERVERS[@]}"; do
    result=$(dig @$dns $domain +short +time=$TIMEOUT +tries=1 2>/dev/null)
    status=$?
    rcode=$(dig @$dns $domain +noall +comments +time=$TIMEOUT +tries=1 2>/dev/null | \
            grep "status:" | awk -F'status: ' '{print $2}' | awk -F',' '{print $1}')

    if [ -z "$result" ] && [ "$rcode" != "NOERROR" ]; then
      echo "  $dns: FAIL (rcode=$rcode)"
      ISSUES+=("$domain@$dns: $rcode")
    else
      echo "  $dns: OK ($result) [rcode=$rcode]"
    fi
  done
done

echo ""
if [ ${#ISSUES[@]} -gt 0 ]; then
  echo "=== ISSUES FOUND ==="
  for issue in "${ISSUES[@]}"; do
    echo "  ✗ $issue"
  done

  # 发送告警（如果配置了邮件）
  if command -v mail &>/dev/null; then
    echo "DNS Issues: ${ISSUES[*]}" | \
      mail -s "DNS Health Check Alert" "$ALERT_EMAIL"
  fi

  exit 1
else
  echo "=== ALL CHECKS PASSED ==="
  exit 0
fi

# 使用 named-checkzone 验证区域文件
named-checkzone example.com /etc/bind/zones/example.com.zone
# zone example.com/IN: loaded serial 2025080101
# OK

# 使用 named-checkconf 验证 BIND 配置
named-checkconf /etc/named.conf
# （无输出表示通过）

# 在线工具:
# - https://intodns.com/ — 综合 DNS 配置检查
# - https://mxtoolbox.com/ — 邮件 DNS 检查（MX/SPF/DKIM）
# - https://dnschecker.org/ — 全球 DNS 传播检查

# 问题一: Pod 内无法解析域名
# 进入 Pod 测试
kubectl exec -it <pod> -- nslookup kubernetes.default
# 如果失败:

# 1. 检查 CoreDNS 是否运行
kubectl get pods -n kube-system -l k8s-app=kube-dns
# 如果 CoreDNS Pod 不健康 → 修复 CoreDNS

# 2. 检查 DNS Service
kubectl get svc -n kube-system kube-dns
# ClusterIP 应该与 Pod 的 /etc/resolv.conf 中的 nameserver 一致

# 3. 检查 Pod 的 DNS 配置
kubectl exec <pod> -- cat /etc/resolv.conf
# nameserver 10.96.0.10
# search default.svc.cluster.local svc.cluster.local cluster.local
# options ndots:5

# 4. 直接测试 CoreDNS 端点
kubectl exec <pod> -- dig @10.96.0.10 kubernetes.default.svc.cluster.local

# 问题二: 外部域名解析慢
# 原因: ndots:5 导致大量无效搜索
kubectl exec <pod> -- time dig google.com
# 可能需要 5+ 秒（尝试 5 个搜索域后才查真实域名）

# 解决:
# 方案 A: 使用 FQDN（末尾加点）
kubectl exec <pod> -- dig google.com.  # 注意末尾的点

# 方案 B: 降低 ndots
# 在 Pod spec 中设置 dnsConfig: options: [{name: ndots, value: "2"}]

# 启用 CoreDNS 查询日志（调试时使用）
kubectl edit configmap coredns -n kube-system
# 添加 log 插件

# 查看 CoreDNS 日志
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=50

# 分析日志中的错误
kubectl logs -n kube-system -l k8s-app=kube-dns | \
  grep -E "SERVFAIL|NXDOMAIN|i/o timeout" | tail -20

# 常见日志错误:
# [ERROR] plugin/errors: 2 example.com. A: i/o timeout
# → CoreDNS 到上游 DNS 超时
# → 检查 CoreDNS 的 forward 配置和上游 DNS 可达性

# [ERROR] plugin/errors: 2 svc.cluster.local. A: NXDOMAIN
# → 查询的 Service 不存在
# → 检查 Service 名称和 namespace

# DNS 告警规则
groups:
  - name: dns-alerts
    rules:
      - alert: DnsResolutionFailure
        expr: |
          probe_success{job="dns-probe"} == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "DNS 解析失败: {{ $labels.instance }}"
          description: "DNS 服务器 {{ $labels.instance }} 连续 2 分钟无法解析"

      - alert: DnsHighLatency
        expr: |
          probe_dns_lookup_time_seconds{job="dns-probe"} > 1
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "DNS 延迟过高: {{ $labels.instance }}"
          description: "DNS 查询延迟超过 1 秒，持续 5 分钟"

      - alert: DnsCacheHitRateLow
        expr: |
          sum(rate(coredns_cache_hits_total[5m])) /
          (sum(rate(coredns_cache_hits_total[5m])) +
           sum(rate(coredns_cache_misses_total[5m]))) < 0.8
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "DNS 缓存命中率过低"
          description: "缓存命中率低于 80%，持续 10 分钟"

      - alert: CoreDnsServfailRate
        expr: |
          sum(rate(coredns_dns_responses_total{rcode="SERVFAIL"}[5m])) /
          sum(rate(coredns_dns_responses_total[5m])) > 0.01
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "CoreDNS SERVFAIL 率过高"
          description: "SERVFAIL 比例超过 1%，持续 5 分钟"