// HACKER NEWS — CYBERSECURITY
Launching Route 53 Files
Four decades ago, when the Berkeley Internet Name Domain Server launched, it
stored DNS records in "zone files". You could edit these files in vi,
but BIND had to be told to reload them before your changes took effect.
Later, other DNS servers came along, like Daniel Bernstein's tinydns, which
served records directly out of a database on disk — but even there,
after editing the human-readable DNS records, it was necessary to recompile
the database file.
With Route 53 Files, it becomes possible to use standard UNIX software to
edit your DNS without needing any additional steps. It makes your hosted
zones accessible as file systems; this means changes you make to records in
the file system are automatically reflected in Route 53, and changes made in
Route 53 through any other channel — the AWS Management Console, the
Route 53 API, the AWS CLI — automatically appear in the file system.
A Route 53 Files file system can be attached to multiple compute resources,
enabling shared access to your zones across teams without duplication.
Until now, you had to choose between the Route 53 console, the Route 53 API,
and the tools built on top of them. Route 53 Files eliminates that tradeoff.
Your hosted zone becomes the central hub for all your organization's DNS
records. It's accessible directly from any AWS compute instance, container,
or function, whether you're running production applications, responding to
an incident, or building agentic AI systems.
You can access any enrolled public or private hosted zone as a native file
system on your Amazon Elastic Compute Cloud (Amazon EC2) instances, containers
running on Amazon Elastic Container Service (Amazon ECS) or Amazon Elastic
Kubernetes Service (Amazon EKS), or AWS Lambda functions. The file system
presents each resource record set as a file and each record name as a
directory, supporting standard Network File System (NFS) v4.1+ operations
like creating, reading, updating, and deleting DNS records.
Alias records are presented as symbolic links to their targets, so
ls -l renders them the way you would expect and readlink
does what you would hope. Cross-zone aliases are presented as dangling
symbolic links — as they should be, given that their targets are not
inside the same file system.
Under the hood, Route 53 Files uses S3 Files and delivers ~90s latency for
a file save to reach live DNS, and up to 6 minutes of latency for a change made
elsewhere in Route 53 to appear in your mount. (Note that changes reaching
live DNS does not ensure that they are immediately visible worldwide; the
latency for global visibility of DNS changes depends on record TTLs and
caching behaviour.) The file system supports concurrent access from multiple
compute resources with last-write-wins conflict resolution, making it ideal
for shared workloads that mutate authoritative DNS, such as AI agents
collaborating through file-based tools and on-call engineers reverting each
other's changes using sed.
Creating my first Route 53 Files file system, mounting it, and editing DNS
from an EC2 instance is straightforward. In this example, I already have
a Route 53 hosted zone and an EC2 instance where I want to mount it.
First, I navigate to the
Route 53 Files Console and
create IAM roles. These are needed to allow Route 53 Files to create
resources in my AWS account and read and write to my existing Route 53 hosted
zone.
I fill in my 12-digit AWS account ID and the Route 53 hosted zone ID I'm
planning on using; if I wanted to I could specify multiple hosted zones or
even "*" to allow all Route 53 hosted zones to be enrolled. When I click
"Create bundle", a tarball is generated inside the web browser containing
IAM role policies with exactly the privileges required; if you're paranoid
about security (as you should be), you can audit the role-generation code
to confirm that it isn't trying to grant any unnecessary privileges.
Having downloaded the bundle, I extract it and run the included script to
creat