介绍
Willow Commons 正在把网站迁移到新的服务器地址。社区必须继续使用 site.community.test，迁移期间原位置也必须保持可用。两个后端都已包含各自合法的活动安排；你的工作是 DNS 迁移，而不是发布内容。
请先完成 查看客户端实际使用的地址。这个独立环境会重新从正式名称指向旧地址的状态开始，并准备好独立的权威服务器、缓存解析器和正常运行的新旧 HTTP 服务，不会复用之前的 VM。你将准备 TTL、修改地址，并验证实际客户端及完整内容。请预留约 50 分钟，包括阅读和处理普通错误；这是作者估计。
这是受控的本地 DNS 练习，不承诺全球传播、零停机、公共注册商迁移，也不表示可以立即删除旧服务器。
准备迁移窗口
在这一步中，你将先检查正常服务和新后端，再缩短正式记录的 TTL。先进入 Community Preview，选择 Warm Client，阅读带有 old location 标签的现有 Willow Commons 页面。修改地址之前不要使用 Fresh Client，它的独立解析器还没有查询过这个站点。
切换到 Warm Client。命令和 curl 参数与第一个单元相同。先请求现有的命名服务：
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
你应看到来自 Service location: old 的完整活动安排。再通过新后端的地址检查它，使用相同路径和端口：
curl --noproxy '*' -fsS --max-time 5 http://10.94.0.20:8081/programme.txt
你应看到相同的三项聚会和入口信息，但位置为 Service location: new。这个直接就绪检查是有意绕过 DNS 的，并不能证明通过名称访问的客户端已经迁移。请保持两个网站不变。
查询 Warm Client 当前的副本：
dig @127.0.0.1 site.community.test A +noall +answer
应返回旧地址，TTL 不超过 120。如果 setup 预热的副本在阅读时已过期，这个真实查询会再次取得仍指向旧地址的现行记录。实验没有从打开时刻开始计算的完成期限。
切换到 DNS Desk，位于 /home/labex/project/site-move，阅读记录文件和已准备的后端规划：
cat backends.tsv
cat community.zone
迁移只允许编辑 site 的 A 地址、TTL 和必要的 SOA serial。practice 留作可选的重复观察；必须保留 keep、名称服务器和全部网站字节。准备好的旧记录具有真实的 120 秒 TTL。本练习有意使用秒，并不意味着生产环境中缓存一天的记录会在两分钟内消失。
修改地址之前，先只降低正式记录的 TTL。这个完整的字面 here-document 使用第一个单元教过的文件写入语法：
cat > community.zone <<'ZONE'
$TTL 120
@ IN SOA ns.community.test. admin.community.test. (2 60 30 3600 30)
@ IN NS ns.community.test.
ns IN A 10.94.0.2
site 45 IN A 10.94.0.10
practice 120 IN A 10.94.0.10
keep 120 IN A 10.94.0.10
ZONE
named-checkzone community.test community.zone
你应看到 loaded serial 2 和 OK；重载前先纠正任何语法问题：
sudo /opt/labex/site-move/reload-zone
确认 运行中的权威服务器 的数据，而不仅是已保存的文件：
sudo ip netns exec site-authority dig @10.94.0.2 site.community.test A +noall +answer
应返回 45 IN A 10.94.0.10。权威数据仍然指向旧后端。切换到 Warm Client：
dig @127.0.0.1 site.community.test A +noall +answer
旧缓存副本仍保留原先的剩余寿命。不要把剩余 TTL 为 40 秒当成客户端已取得新 45 秒策略的证据：原来的 120 秒副本也可能只剩 40 秒。
等待刚刚观察到的旧副本过期，再次查询。你可以等待最后显示的剩余秒数再加一秒。下面完整的保守命令覆盖原有 120 秒最大值：
sleep 121
dig @127.0.0.1 site.community.test A +noall +answer
你应看到旧地址，以及新取得的、接近 45 秒的 TTL。最后这个 DNS 请求很重要：过期只会移除旧副本，不会主动获取替代副本。原生 DNS 交换会记录这个缩短了寿命的旧地址回答。检查会先阅读既有交换记录，再发出任何探测，绝不会替你完成这一准备阶段。
如果没有回答或出现其他地址，请先重新阅读权威服务器和客户端的准确输出。在 DNS Desk 修正文件错误，验证并重载，再到 Warm Client 重试命名查询。不要重启或清空解析器。只有确实取得了缩短寿命的旧地址后，才运行本阶段的检查。
修改地址并比较两个客户端
在这一步中，你将迁移正式名称，并比较独立客户端。先完整阅读本步骤，再开始短暂的操作序列。接下来的 warm 查询会显示剩余比较窗口；缓存命中不会重新开始计算 TTL。只有自然过期后重新取得的副本，才会开始新的 45 秒寿命，这与 setup 无关。编辑较慢可能错过可见差异；迁移仍然有效，下方单独练习名称的恢复方法可以让你重复观察。
在 Warm Client 中刷新当前观察：
dig @127.0.0.1 site.community.test A +noall +answer
如果剩余 TTL 即将耗尽，请在权威服务器仍返回旧地址时等它过期，再次查询。然后切换到 DNS Desk。修改正式 A 地址，保留 45 秒 TTL，并增大 serial：
cat > community.zone <<'ZONE'
$TTL 120
@ IN SOA ns.community.test. admin.community.test. (3 60 30 3600 30)
@ IN NS ns.community.test.
ns IN A 10.94.0.2
site 45 IN A 10.94.0.20
practice 120 IN A 10.94.0.10
keep 120 IN A 10.94.0.10
ZONE
named-checkzone community.test community.zone
sudo /opt/labex/site-move/reload-zone
sudo ip netns exec site-authority dig @10.94.0.2 site.community.test A +noall +answer
运行中的权威服务器 现在必须返回 45 IN A 10.94.0.20。如果仍是旧地址，说明保存文件与已加载数据不一致；解释客户端缓存之前，先检查语法和重载结果。
切换到 Warm Client：
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
在缓存剩余寿命内，它合理地仍可能使用旧地址，并返回 Service location: old。切换到 Fresh Client；它从 /home/labex/project/site-move/fresh 启动，使用自己的解析器：
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/programme.txt
你应看到新地址和完整的 Service location: new 活动安排。在 DNS 迁移期间，两个客户端可以使用同一个名称，却访问不同的有效后端。它们是同一个 VM 中独立的 Linux 客户端命名空间与缓存进程，不是两台实体设备或独立 VM。
如果两个客户端已经都显示 new： warm 副本在比较前已自然过期。继续正式迁移；通过检查不要求截图或历史上的重叠窗口。若想在不撤销迁移的情况下重复现象，请按第一个单元的方法使用 practice.community.test。在 DNS Desk 中保持 site 指向新地址，只把 practice 设为旧地址和 120 秒，并通过 nano community.zone 增大当前 serial（按 Ctrl+O、Enter、Ctrl+X）。验证并重载。在 Warm Client 中等待当前练习副本到期，再查询 practice，以开始新的窗口。只把 practice 改为新地址和 45 秒，使用另一个更大的 serial，验证并重载，然后通过两个客户端比较 practice。整个过程中正式 site 记录始终保持已迁移状态。通过自然过期结束练习观察，绝不要清空缓存或替换网站内容。
如果在完成 TTL 准备之前就改了正式地址，请使用教过的记录编辑流程，只把 site 恢复为旧地址和 45 秒，使用更大的 serial，验证并重载，然后等待 Warm Client 当前回答过期。请求短 TTL 的旧地址，再使用更大的 serial 重新切换。两个原始后端始终可用，因此这种限定范围的 DNS 回退可以修复操作顺序，而不必重置服务或删除工作。最终目标仍是新的正式地址。确认 运行中的权威服务器 已改变后，运行本阶段的检查。
通过 DNS 确认新访问路径
在这一步中，你将证明受控客户端能访问新内容，同时旧服务保持可用。先进入 Warm Client。在允许的策略下，迁移时原副本最多持续 60 秒（示范流程使用 45 秒）。检查剩余 TTL：
dig @127.0.0.1 site.community.test A +noall +answer
如果仍返回旧地址，请等待剩余秒数再加一秒，然后重复查询。下面完整的保守等待覆盖允许的最大短 TTL：
sleep 61
dig @127.0.0.1 site.community.test A +noall +answer
应返回 10.94.0.20；按示范策略，剩余 TTL 不超过 45。只有地址正确还不够；通过这个名称请求首页并保存完整活动安排：
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat programme.txt
你应看到真实的 new location 首页和 Service location: new 活动安排，包含全部三项聚会及入口信息。如果 DNS 正确但内容错误，请调查实际后端路径和地址；把旧网站改成新网站的样子不在允许范围内。
切换到 Fresh Client，独立保存相同的完整资源：
dig @127.0.0.1 site.community.test A +noall +answer
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat programme.txt
你应看到同样的新位置内容。切换到 Community Preview，必要时使用浏览器 Back 返回选择页，分别选择客户端并刷新真实页面。现在两者都应显示 new location。在每个视图使用 Download the programme，并打开完整文本。这些浏览器请求使用选定的课程客户端，与浏览器所在电脑的 DNS 相互独立。
阅读顶部附近的 new location 标签，以及三项聚会下方原有的活动安排链接。每个客户端都应显示这个真实的新后端页面。
回到 Warm Client，证明保留要求仍满足。直接请求旧后端：
curl --noproxy '*' -fsS --max-time 5 http://10.94.0.10:8081/programme.txt
应返回原始旧位置的活动安排。在权威服务器查询无关名称：
dig @10.94.0.2 keep.community.test A +noall +answer
应得到未改变的 120 IN A 10.94.0.10。旧服务仍属于本次迁移的契约要求。不要因为两个客户端迁移完成就停止它；这些观察不能证明真实世界的所有客户端都已更新。
如果已保存文件仍包含较早位置的内容，请在该客户端的真实 DNS 查询改变后，在正确的客户端标签页重复相同下载命令。如果路径错误，请用 pwd 和 cd /home/labex/project/site-move/warm，或对应的 fresh 目录恢复。最终检查会先读取既有 DNS 与重载证据，再自行请求。重复评分不会清空缓存或重载权威服务器；普通读取可能追加原生日志。
总结
你检查了新后端，在权威数据仍指向旧地址时降低 TTL，并让真实客户端取得该策略。随后你修改地址、比较独立客户端，并在自然过期后验证完整的新站内容。原名称、旧后端和无关记录都保持可用。这些是受控客户端的观察结果，不是全球 DNS 传播保证。
