CodeRoadMap
首页路线题库资源库文章社区
CodeRoadMap

程序员的学习成长路线图。内容免费开放,登录后可同步路线图与课时进度。

由 程序员柏风 独立维护 · 关于作者

学习

  • 路线图
  • 课程
  • 面试题
  • 文章
  • 我

更多

  • 资源
  • 社区
  • 关于作者
  • 内容说明

© 2026 CodeRoadMap

津ICP备2026012044号-1·津公网安备12011002026155号·coderoadmap@126.com
DNS 与域名解析/课时/综合练习
RawBlame
课时目录12 节

DNS 与域名解析

  1. 01DNS 是什么
  2. 02记录类型
  3. 03解析过程
  4. 04域名层次
  5. 05诊断工具
  6. 06本站域名配置
  7. 07DNS 与 HTTPS
  8. 08邮件相关记录
  9. 09K8s CoreDNS
  10. 10常见故障
  11. 11DNS 与 CDN
  12. 12综合练习

综合练习

从域名到 curl https 全链路排障。

40 分钟

综合练习

这一课你将能做到

  1. 独立完成一次「新子域从零上线」:权威记录、Nginx、证书、CDN 策略、多解析器验收与回滚
  2. 写出并运行一套 DNS + 站点健康巡检脚本,能自动区分解析层与服务层故障
  3. 完成一次「源站迁移演练」与一次「故障注入」:降 TTL、双机对比、制造 NXDOMAIN/超时并复盘

为什么要学

前 11 课是按知识点组织的:记录、链路、工具、加密、邮件、集群、CDN、排障。真实工作里这些从不单独出现——一次发版可能同时碰 DNS、Nginx、证书和 CDN,一个工单可能要在缓存窗口内快速止血。本课用一个贯穿项目把所有技能串起来,要求你不看前面的课独立跑通。能完成本课,你就具备了小中型站点的域名运维实战能力。

练习场景全部基于本站真实架构:coderoadmap.cn 委派给 Cloudflare,源站云主机跑 Nginx(静态站 + 反代 API),部分服务在 K8s 集群内。

先建立图像

综合练习总图(你要交付的四件事):

  任务A 新子域上线     任务B 健康巡检脚本
  ───────────────     ──────────────────
  权威 → CDN → 源站    dig ×3 + curl + 告警
  证书 → Nginx         分层输出 OK/WARN/FAIL
        │                    │
        ├────────────┬───────┘
        ▼            ▼
  任务C 迁移演练    任务D 故障注入+复盘
  降TTL→新机验证    写错域名/超时/5s卡顿
  →切流→回滚预案    现象→证据→修复记录

验收标准:所有命令真实执行并留输出记录;每个结论标注证据(status/TTL/响应头/时间戳);回滚方案在动手前写好。

跟着做

任务 A:上线 lab.coderoadmap.cn(完整流水线)

# A1 权威记录:Cloudflare 添加 A → 203.0.113.10,橙云,TTL 300
# A2 源站验证(先绕过 CDN,确认源站本身正确)
curl -I --resolve lab.coderoadmap.cn:443:203.0.113.10 https://lab.coderoadmap.cn/

# A3 证书:用已有的泛域名证书或单独申请(DNS-01)
sudo certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cf.ini \
  -d lab.coderoadmap.cn

# A4 Nginx 增加 server 块
sudo tee /etc/nginx/conf.d/lab.conf >/dev/null <<'EOF'
server {
    listen 443 ssl http2;
    server_name lab.coderoadmap.cn;
    ssl_certificate     /etc/letsencrypt/live/lab.coderoadmap.cn/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/lab.coderoadmap.cn/privkey.pem;
    root /var/www/lab;
    index index.html;
}
EOF
sudo nginx -t && sudo systemctl reload nginx

# A5 多解析器验收(权威视图 + 两个递归视图)
dig @ns1.cloudflare.com lab.coderoadmap.cn +norecurse +short
dig @8.8.8.8 lab.coderoadmap.cn +short
dig @223.5.5.5 lab.coderoadmap.cn +short
curl -I https://lab.coderoadmap.cn/

期望:三条 dig 均返回地址(橙云为 Cloudflare IP),curl 返回 200。记录全部输出到 taskA.log。

任务 B:写健康巡检脚本

新建 dns-health.sh:

#!/usr/bin/env bash
# 用法: ./dns-health.sh lab.coderoadmap.cn /
set -u
NAME=${1:?域名}
PATH_URI=${2:-/}
RESOLVERS=(8.8.8.8 223.5.5.5 1.1.1.1)

echo "== [1] 本机解析 =="
if ! dig +time=3 +tries=1 +short "$NAME" A; then
  echo "FAIL 本机解析失败"; exit 1
fi

echo "== [2] 多解析器对比 =="
for r in "${RESOLVERS[@]}"; do
  out=$(dig @"$r" +time=3 +tries=1 +short "$NAME" A)
  [ -n "$out" ] && echo "OK  $r -> $out" || { echo "FAIL $r 无应答"; exit 1; }
done

echo "== [3] HTTPS 与缓存头 =="
head=$(curl -sI --max-time 8 "https://$NAME$PATH_URI")
echo "$head" | grep -E "^HTTP|cf-cache-status|cache-control|server:" || true
code=$(echo "$head" | awk 'NR==1{print $2}')
[ "${code:-000}" = "200" ] && echo "OK HTTP 200" || echo "WARN HTTP=$code"

echo "== [4] 源站直连(--resolve,按需传 SOURCE_IP)=="
[ -n "${SOURCE_IP:-}" ] && curl -sI --max-time 5 \
  --resolve "$NAME:443:$SOURCE_IP" "https://$NAME$PATH_URI" | head -3

运行:

chmod +x dns-health.sh
SOURCE_IP=203.0.113.10 ./dns-health.sh lab.coderoadmap.cn / | tee taskB.log

脚本设计要点:超时短(3s)避免卡在单次查询;每一层独立判定,FAIL 立即退出;第 4 步可选,体现「解析层 vs 源站层」分离。

任务 C:源站迁移演练(不影响真实用户的前提下)

# C1 变更前 24h(练习时直接确认)TTL 已为 300
dig lab.coderoadmap.cn | grep -E "IN\s+A"

# C2 新机 203.0.113.20 部署完成后,先验证新机站点与证书
curl -I --resolve lab.coderoadmap.cn:443:203.0.113.20 https://lab.coderoadmap.cn/

# C3 切流:Cloudflare/面板把记录改为新 IP(橙云则改回源地址)
# C4 观察收敛:连续 6 分钟(一个 TTL+余量)
for i in $(seq 1 7); do
  curl -o /dev/null -s -w "$(date +%H:%M:%S) %{http_code} %{remote_ip} %{time_total}\n" \
    https://lab.coderoadmap.cn/
  sleep 60
done | tee taskC.log

回滚预案(动手前写在 taskC.log 顶部):面板记录改回 203.0.113.10;5 分钟内流量回流;新机保留不删,事后排查。若新机验证任一项不过,不允许进入 C3。

任务 D:故障注入与复盘

三个实验,逐个做、逐个恢复:

# D1 NXDOMAIN/否定缓存:临时把 lab 改名 → dig 观察 NXDOMAIN → 改回
#    记录现象时间;恢复后解释为什么部分递归器仍短暂 NXDOMAIN
dig @223.5.5.5 lab.coderoadmap.cn

# D2 解析超时:本机临时把 DNS 指到一个不可达地址(或断网模拟)
#    Windows: 网络适配器设置改 DNS;Linux: 改 /etc/resolv.conf(练习环境)
dig +time=2 lab.coderoadmap.cn        # 观察超时与报错

# D3 5 秒延迟(可选,需要能丢包的环境):
sudo iptables -I OUTPUT -p udp --dport 53 -m statistic --mode random --probability 1.0 -j DROP
dig lab.coderoadmap.cn                  # 查询应超时;概率设 0.5 时可观察 ~5s 重传
sudo iptables -D OUTPUT -p udp --dport 53 -m statistic --mode random --probability 1.0 -j DROP

注意:iptables 实验只在你自己的练习机做,做完立即删除规则;生产机严禁操作。Windows 练习机可只做 D1、D2。

任务 E:交付复盘报告(模板)

新建 practice-report.md:

任务A:上线时间;最终记录与证书 SAN;验收命令结果(贴关键行)
任务B:脚本运行结果;是否全部 OK;脚本文件路径
任务C:切换时间线(每分钟一行);全部收敛耗时;回滚预案是否需要启用
任务D:三次注入的现象→你用的证据→恢复方式
总结:本次哪一步最容易出错?下次改进项(至少一条)

讲清楚要点

  1. 顺序纪律:先验证再切流,先备份再修改,先降 TTL 再迁移——这三条覆盖绝大多数线上事故的预防。
  2. 巡检脚本必须分层判定:本机解析、多递归器、HTTP、源站直连各自独立,否则脚本只会报「网站坏了」,没有定位价值。
  3. 多解析器验收是最低发布标准:单一视图(尤其只用本机)通过不等于全球通过。
  4. 迁移演练的核心不是切,而是「切之前新机已被证明可用」与「切之后知道看什么」:remote_ip、HTTP 码、耗时三列足够判断收敛。
  5. 故障注入的价值是建立「现象-证据」映射:亲手制造过 NXDOMAIN 和超时,真实工单时你才不会慌。
  6. 复盘要写改进项而不是只写原因:例如「TTL 未提前降低」「脚本缺少告警出口」,让每次练习产生可沉淀的东西。
  7. K8s 中的服务同样适用本套方法:把 dig 换成 Pod 内 nslookup、源站直连换成 Service/NodeLocal 检查即可(第 9 课)。

你可能会懵的地方

  • 没有自己的域名/云主机,怎么做这些练习? 可以用任意已注册的域名配合便宜的云主机;纯本机可用 D2 段的方式 + 自建 Nginx(本机 hosts 指域名到 127.0.0.1)完成大部分任务,只是没有「全球传播」可观察;CDN 部分可用 Cloudflare 免费套餐完整体验。

  • 脚本里 +tries=1 会不会误报? 巡检脚本追求快速暴露问题,单次失败即 WARN/FAIL 是合理的;判定真实故障时人工再跑一次完整 dig 确认,避免把偶发丢包当成宕机。

  • 迁移时浏览器一直连旧 IP,怎么确认是缓存? 用 curl(不带任何本机缓存)按任务 C 观察;或换一台干净机器 dig。浏览器还有连接复用,重启浏览器再看,不要把连接复用误判成 DNS 没生效。

  • 任务 D 的 iptables 会不会把自己关在服务器外面? 规则只丢弃 UDP 53(DNS),不影响 SSH(22);但在远程主机上操作仍建议保留一个已登录的 root 会话,规则删除命令提前准备好。

  • 证书申请成功了但浏览器说不安全,可能漏了什么? 检查 SAN 是否含完整名字、证书链 fullchain 是否完整(少中间证书部分老设备告警)、系统时间是否正确。这三项比「重新签发」更先查。

错法对照

错法后果正确做法
新机没验证就切 DNS全部用户打到坏站,只能回滚--resolve 先验新机,通过后切
脚本只 curl 不 digDNS 坏时只报 HTTP 失败,定位慢分层:dig → curl → 源站
演练不写回滚预案出问题时边想边操作,时间翻倍动手前写清两步回滚
注入故障后忘记恢复练习机长期解析异常每任务结束立即验证恢复并记录
只截图不留命令输出复盘无证据、不可复核全部 tee 到日志文件

卡点急救

  1. 任务 A 卡在「公网查不到新记录」:先 dig @ns1.cloudflare.com 确认权威已保存;权威正常则等否定缓存(SOA minimum);面板报错优先按第 2 课 CNAME 冲突思路查。
  2. 任务 C 收敛超过 10 分钟:检查记录 TTL 是否真是 300(很多面板「自动」在代理模式另有值);多权威直查是否都更新;必要时用厂商刷新接口。
  3. 任务 D 后本机无法解析任何域名:检查 iptables 规则是否删净(iptables -L OUTPUT -n --line-numbers)、resolv.conf 是否恢复;重启网络服务恢复默认配置。

面试常问

  • 让你独立负责一个新子域的上线,你按什么流程做? 确认 NS 委派正常;权威加记录并按变更需要设 TTL(计划可迁移则 300);源站 Nginx 配 server_name 与站点;申请覆盖该名的证书并配 HTTPS、80 跳转;CDN 场景对齐回源协议与缓存策略;上线用权威直查 + 两个以上公共递归 + curl 验收;全程保留旧配置与两步回滚方案。上线后跑巡检脚本观察一段时间。

  • 如何设计一个 DNS 健康检查脚本? 分层设计:本机 dig(短超时、单次)判定本地解析;多公共递归器并行查询对比答案一致性;curl 检查 HTTP 状态与缓存头;可选 --resolve 直连源站区分 CDN 与源站。每层输出 OK/WARN/FAIL 并带时间戳,失败立即返回非零退出码供定时任务/监控系统消费。重点是输出能直接用于定位,而不只是告警。

  • 做服务器零停机迁移时,DNS 环节怎么安排? 迁移前 1~2 天把记录 TTL 降到 300;新机部署并用 --resolve 完整验证站点与证书;选择低峰切流,改权威/回源记录;按一个 TTL 为周期观察 HTTP 码、落点 IP 与耗时,确认收敛后保留旧机一段时间再回收;全程备好「记录改回旧值」的回滚路径。不要先关旧机,也不要在 TTL=86400 的状态下迁移。

自测三问

  1. 不看前文,默写出任务 A 的五条命令顺序,并说出每步的验收点。
  2. 巡检脚本为什么必须把 dig 与 curl 分开?合并成一条 curl 会丢失什么定位能力?
  3. 迁移切流后你观察哪三列数据?全部收敛的标准是什么?

小结一句话

综合实战靠纪律:先降 TTL、先验新机、切流后多解析器观察、留好两步回滚,并用分层巡检脚本把每一次故障变成可定位、可复盘的证据。

延伸

  • RFC 1034 / RFC 1035:DNS 奠基双文档
  • RFC 9116:终端用户对递归解析器的安全期望
  • Cloudflare 学习中心:DNS 全系列主题
  • Kubernetes 与 CoreDNS 官方运维文档
  • 结业建议:把本课的巡检脚本接入你的服务器定时任务(cron)或监控平台,让练习成果持续运行;后续可继续学习 HTTP 协议与 Nginx 进阶课程。
加载本节练习…
← 上一课DNS 与 CDN