星期六（5 月 18 日），我启动了其中一台虚拟机（运行 Ubuntu 18.04 Server）。
令我惊讶的是，虚拟机几乎立即尝试连接d16r8ew072anqo.cloudfront.net:80，这是我以前从未见过的——这是一个非常“原始”的 Ubuntu 安装，没有自定义apt存储库，只安装了几个包。它之前从未连接过任何可疑的东西——主要是 Ubuntu 和 Snap 域。（我使用 Little Snitch 来监控网络流量，这样我就可以实时查看连接，也可以拒绝它们。）
我花了一些时间试图弄清楚发生了什么，我相信我已经将问题缩小到unattended-upgrades安装安全补丁。具体来说，当我手动重新安装intel-microcode:amd64软件包时，我能够重现与 CloudFront 的奇怪连接（尽管这可能只是巧合）。
然后，在星期一，我想记录下这个问题以防再次发生类似的事情，但令我惊讶的是，我再也无法重现这种奇怪的连接了。
周一唯一可观察到的区别是 [1] 的输出
sudo apt-get install --reinstall intel-microcode:amd64没有这条Ign:1线。
我搜索了网络，包括http://archive.ubuntu.com/ubuntu，grep检查了 VM 的磁盘，检查了其他子域的 DNS 记录ubuntu.com，尝试wget使用不同的 URL 来查找到可疑域的重定向——但我找不到有关与 CloudFront 的奇怪连接的任何线索。
我的问题是：有人知道发生了什么吗，或者至少在他们的日志中注意到了相同的连接？
（顺便说一句，我知道一个 Ubuntu 团队使用 CloudFront 来减轻其服务器负担的例子： 我的 12.04 ISO 上的 MD5 不匹配，发生了什么？ ——所以我希望这可能是一个类似的情况？）
[1]：
$ sudo apt-get install --reinstall intel-microcode:amd64
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 1,801 kB of archives.
After this operation, 0 B of additional disk space will be used.
Ign:1 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 intel-microcode amd64 3.20190514.0ubuntu0.18.04.2
Get:1 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 intel-microcode amd64 3.20190514.0ubuntu0.18.04.2 [1,801 kB]
Fetched 1,801 kB in 20s (89.2 kB/s)
(Reading database ... 107477 files and directories currently installed.)
Preparing to unpack .../intel-microcode_3.20190514.0ubuntu0.18.04.2_amd64.deb ...
Unpacking intel-microcode (3.20190514.0ubuntu0.18.04.2) over (3.20190514.0ubuntu0.18.04.2) ...
Setting up intel-microcode (3.20190514.0ubuntu0.18.04.2) ...
update-initramfs: deferring update (trigger activated)
intel-microcode: microcode will be updated at next boot
Processing triggers for initramfs-tools (0.130ubuntu3.7) ...
update-initramfs: Generating /boot/initrd.img-4.15.0-50-generic
答案1
我向安全和档案团队询问了这个问题，因为他们是判断这是否是预期行为的权威人士。以下是他们与我分享的内容摘要：
观察到的这种行为是将流量负载从存档镜像卸载到 Cloudfront，并于 5 月 15 日星期三至 5 月 20 日星期一之间完成，以减轻存档服务器的负载，特别是对于内核和微码更新。
据这些团队称，这是第一次通过 CloudFront 进行此类卸载，并且在这种情况下预期行为。
虽然这看起来很可疑，但团队已经通过 IRC 向我确认这是预期的行为，并且他们很惊讶过去没有更多人注意到这种行为。
最终：这不是恶意行为，而是预期行为，并且是必要的，以防止存档服务器超载。（这也是他们第一次这样做，所以至少没有发生任何爆炸，呵呵）
现在应该恢复不卸载到 Cloudfront 的标准行为。