推出 Route 53 Files

# 启动 Route 53 Files 来源：https://www.daemonology.net/blog/2026-08-27-Launching-Route-53-Files.html 我非常兴奋地宣布推出 Route 53 Files，这是一个全新的文件系统，能够将任何 AWS 计算资源与 Amazon 高可用性数据库（https://aws.amazon.com/route53/）无缝连接。 四十年前，当伯克利互联网名称域名服务器推出时，它将 DNS 记录存储在“区域文件”中。你可以使用 vi 编辑这些文件，但 BIND 必须被告知重新加载它们，你的更改才能生效。后来，出现了其他 DNS 服务器，如 Daniel Bernstein 的 tinydns，它直接从磁盘上的数据库中提供记录服务——但即便如此，在编辑人类可读的 DNS 记录后，仍需重新编译数据库文件。 借助 Route 53 Files，你可以使用标准 UNIX 软件编辑 DNS，无需任何额外步骤。它将你的托管区域作为文件系统进行访问；这意味着你在文件系统中对记录所做的更改会自动反映到 Route 53 中，而通过其他任何渠道（AWS 管理控制台、Route 53 API、AWS CLI）在 Route 53 中所做的更改也会自动出现在文件系统中。 Route 53 Files 文件系统可以挂载到多个计算资源上，实现跨团队对你的区域的共享访问，无需重复数据。 在此之前，你不得不在 Route 53 控制台、Route 53 API 以及建立在其上的工具之间做出选择。Route 53 Files 消除了这种权衡。你的托管区域成为所有组织 DNS 记录的中心枢纽。你可以直接从任何 AWS 计算实例、容器或函数访问它，无论你是在运行生产应用程序、响应事件还是构建智能体 AI 系统。 你可以将任何注册的公共或私有托管区域作为原生文件系统访问你的 Amazon Elastic Compute Cloud (Amazon EC2) 实例、运行在 Amazon Elastic Container Service (Amazon ECS) 或 Amazon Elastic Kubernetes Service (Amazon EKS) 上的容器，或 AWS Lambda 函数。该文件系统将每个资源记录集表示为一个文件，将每个记录名称表示为一个目录，支持标准的网络文件系统 (NFS) v4.1+ 操作，如创建、读取、更新和删除 DNS 记录。别名记录表示为指向其目标的符号链接，`ls -l` 会按预期方式渲染它们，`readlink` 也会按你希望的方式执行。跨区域别名表示为悬空的符号链接——鉴于其目标不在同一文件系统内，这是理所当然的。 在底层，Route 53 Files 使用 S3 Files，并提供约 90 秒的延迟，使文件保存能实时到达 DNS，而 Route 53 中其他位置所做的更改出现在你的挂载点中最多需要 6 分钟的延迟。（请注意，更改到达实时 DNS 并不保证它们会立即在全球范围内可见；DNS 更改的全球可见延迟取决于记录 TTL 和缓存行为。） 该文件系统支持来自多个计算资源的并发访问，采用“最后写入者胜出”的冲突解决策略，使其非常适合修改权威 DNS 的共享工作负载，例如通过文件工具协作的 AI 智能体以及使用 `sed` 相互回滚更改的值班工程师。 **让我向你展示如何开始。** 创建我的第一个 Route 53 Files 文件系统、挂载它并从 EC2 实例编辑 DNS 非常简单。在此示例中，我已有一个 Route 53 托管区域和一个我想挂载它的 EC2 实例。 首先，我访问 Route 53 Files 控制台 (https://www.daemonology.net/r53fs/) 并创建 IAM 角色。这些角色是必要的，以允许 Route 53 Files 在我的 AWS 账户中创建资源，并读取和写入我现有的 Route 53 托管区域。 Route 53 Files 创建 IAM 角色 我填写我的 12 位 AWS 账户 ID 和我计划使用的 Route 53 托管区域 ID；如果我愿意，我可以指定多个托管区域，甚至指定“\*”以允许所有 Route 53 托管区域被注册。当我点击“创建包”时，会在 Web 浏览器内生成一个 tarball，其中包含具有所需精确权限的 IAM 角色策略；如果你像应该做的那样偏执于安全（你应该如此），你可以审计角色生成代码以确认它没有试图授予任何不必要的权限。 下载包后，我解压它并运行包含的脚本来创建角色。tarball 内还有一个 README.txt 文件，其中包含说明，包括解释如果你想以后允许注册额外托管区域需要调整什么。 Route 53 Files 创建 IAM 角色 现在已创建必要的 IAM 角色，我可以继续将 Route 53 托管区域注册到 Route 53 Files。我输入我的 AWS 账户 ID、我的 Route 53 托管区域 ID、我想创建 Route 53 Files 文件系统的 AWS 区域——我是加拿大人，所以我选择了 `ca-central-1`——外部 ID 在我创建角色包时已自动填充。如果我稍后返回此页面，我可以从生成的角色包 tarball 的 README.txt 文件中获取外部 ID。（外部 ID 确保你，且仅你，可以注册你的托管区域；如果你曾想停止使用 Route 53 Files，它也会被用到。） 在 Route 53 Files 中注册区域 当我注册我的托管区域时，我得到了一个格式为“fs-0123456789abcdef0”的文件系统 ID，现在我可以创建一个挂载目标。Route 53 Files 与 S3 Files 兼容，因此我使用相同的命令： ``` $ aws s3files create-mount-target \ --file-system-id fs-0123456789abcdef0 \ --subnet-id <subnet-id> \ --security-groups <security-group-id> \ --region <region> ``` 请注意，由于 Route 53 Files 使用 NFS，你需要使用允许访问 TCP/2049 端口的安全组。一旦我的挂载目标可用，我就可以将其挂载到我的 EC2 实例上。我已经确认我拥有 `amazon-efs-utils` 版本 3.0.0 或更高版本以及 botocore 已安装，并且我的 EC2 实例附加了包含 AmazonS3FilesClientFullAccess 策略的 IAM 角色（https://www.daemonology.net/blog/2016-10-09-EC2s-most-dangerous-feature.html）。 ``` $ sudo mkdir -p /mnt/r53fs/example.com $ sudo mount -t s3files -o nodirects3read \ fs-0123456789abcdef0 /mnt/r53fs/example.com ``` **使用 Route 53 Files 编辑 DNS** 我现在可以使用标准命令行工具编辑我的 DNS。在文件系统内，`foo/TYPE` 是名为“foo”的 TYPE 记录；遵循 DNS 传统，特殊名称“@”指的是区域顶点。例如： ``` $ echo 1.2.3.4 | sudo tee /mnt/r53fs/example.com/@/A ``` 为区域顶点 `example.com` 创建了一个值为 `1.2.3.4` 的 A 记录。如果我想使用循环 DNS，我只需在同一记录集中创建第二个记录： ``` $ echo 5.6.7.8 | sudo tee -a /mnt/r53fs/example.com/@/A ``` 由于文件有两行，现在 DNS 将返回两个 IP 地址。 我希望 `www` 主机别名指向区域顶点，因此我创建一个符号链接： ``` $ sudo mkdir /mnt/r53fs/example.com/www $ sudo ln -s ../@/A /mnt/r53fs/example.com/www/A ``` 如果我想在迁移前提前降低记录 TTL，我只需创建一个 `.TTL` 伴随文件： ``` $ echo 60 | sudo tee /mnt/r53fs/example.com/@/A.TTL ``` 该更改会立即反映在实时 DNS 中；如果没有 `.TTL` 伴随文件，则使用默认值 300 秒。 通配符记录——例如 `*.example.com`——的命名正如你所料；但请注意，`*` 在大多数 shell 中会展开，因此如果从命令行运行，你需要对其转义： ``` $ sudo mkdir /mnt/r53fs/example.com/\* $ echo www.example.com | sudo tee /mnt/r53fs/example.com/\*/CNAME ``` 当然，文件系统可以被任何工具访问，而不仅仅是命令行；例如，我们可以通过 cron 作业更新 DNS： ``` $ echo "*/5 * * * * root date > /mnt/r53fs/daemonology.net/vixie/TXT" | sudo tee -a /etc/crontab $ sleep 600 $ dig +short -t txt vixie.daemonology.net "Tue Aug 25 00:20:01 UTC 2026" ``` **需要了解的事项** 让我分享一些我认为你会觉得有用的重要技术细节。 - Route 53 Files 与 AWS 身份和访问管理（IAM）集成以进行访问控制。每个角色都由你创建。该服务不持有任何角色创建权限；如果你删除 IAM 角色，该服务将立即且静默地停止工作。 - 如果同一记录在文件系统和 Route 53 中同时被更改，我们的目标是“最后写入者胜出”。严格来说这不可能实现，因为 Route 53 不公开记录的修改时间戳，因此有时我们会根据记录在文件系统中更改的时间以及我们知道记录在 Route 53 中更改的时间窗口进行有根据的猜测。 - Route 53 拒绝的写操作会在记录旁边的 `.error` 文件中报告。这在格式错误的数据到达 Route 53 之后异步发生；如果你在写入记录后立即查找 `.error` 文件，你还不会看到它。 - 路由策略、DNSSEC 特定记录类型以及将 EvaluateTargetHealth 设置为 true 的别名目前不受支持。在 Route 53 中发现的任何不被 Route 53 Files 支持的记录将在文件系统根目录中的 `.r53fs-unsupported` 文件中报告。 - 更改会在你停止编辑记录一段时间后出现在 Route 53 中。与 S3 Files 一致，如果你保持文件打开并持续对其进行更改，更改不会传播到 Route 53。 - 为了支持在写入新文件之前移动或删除文件的文本编辑器，有一个短暂的保留期；运行 `vi www/A` 不应导致 NXDOMAIN 错误。 **客户怎么说** Duckbill 首席云经济学家 Corey Quinn： > “多年来我一直告诉人们 Route 53 是一个数据库。Colin 像冠军一样接受了这一正义的理念，这个疯狂的东西比实际的 Route 53 API 好得多，而 Route 53 API 对所有数据库来说都是个耻辱。它没有更改时间戳，没有事件，而且出于某种令人费解的原因，它的 ChangeBatch 模式读起来就像在监狱里学会了 JSON 的 XML。与此同时，`echo` 和 `tee` 在 72 秒内就让我的记录生效了。谢谢你，Colin！” **定价与可用性** Route 53 Files 今天在除中东（巴林）和中东（阿联酋）之外的所有 AWS 商业区域推出。 请注意，由于 Route 53 的控制平面完全在 us-east-1 区域运行，影响 us-east-1 的区域故障将阻止你的 Route 53 Files 文件系统更新 DNS——尽管它们仍可在其各自的区域访问。 你为你 AWS 账户内由 Route 53 Files 创建的基础设施付费，但 Route 53 Files 服务本身是免费的。 我很想听听你如何使用这个新功能。欢迎在下方评论中分享你的反馈。 — cperciva (https://www.twitter.com/cperciva) **常见问题解答** **问：这是官方 AWS 服务吗？** 答：当然不是；但如果他们疯了想要维护它，我很乐意让他们接手。 **问：为什么不在 4 月 1 日发布？** 答：因为 S3 Files 在 4 月初发布，我不想等到 2027 年 4 月。 **问：为什么通过 NFS 而不是 FUSE 文件系统暴露 DNS 区域？** 答：因为这样更有趣。另外，因为 S3 Files 就是这么做的（但我是在重复自己）。 **问：如果你运行 `rm -rf *` 会发生什么？** 答：Route 53 Files 当然会尝试删除你的所有 DNS 记录；不然它还能做什么呢？（请注意，Route 53 不允许你删除托管区域的 SOA 或顶点 NS 记录，因此这些记录会默默地重新出现在文件系统中。） **问：有 SLA 吗？** 答：有，我保证在任何可用性低于 110% 的月份，100% 退还已付费用。 **问：这符合 HIPAA 吗？** 答：请勿在 DNS 中存储患者信息。 **问：Amazon 有人知道你在做这个吗？** 答：完全不知道。如果他们知道，他们肯定会试图阻止我。亚马逊人不仅是同事；他们是我的朋友，我不想因为我无可救药的古怪而让任何人惹上麻烦。 博客评论由 Disqus (https://disqus.com/) 提供支持