You can publish a DNS record in Route 53 by running echo 1.2.3.4 | sudo tee /mnt/r53fs/example.com/@/A. Route 53 Files, launched on August 27, 2026 by Colin Percival, mounts a Route 53 hosted zone over NFS: each record name is a directory, each record set is a file, and writing to that file changes live DNS in about 90 seconds. The launch post is written entirely in the voice of an AWS launch blog — the joke is the prose, not the artifact. The console, IAM roles, and mount commands are real and they work.
What is Route 53 Files?
It’s a service that turns a hosted zone into a mountable filesystem. Percival’s pitch: “With Route 53 Files, it becomes possible to use standard UNIX software to edit your DNS without needing any additional steps.”
That’s the whole payload. grep, sed, find, diff, git — every tool you already have in the terminal becomes a DNS tool, with no SDK and no intermediary CLI.
What do DNS record types look like as files?
The mapping is the central idea. A record name is a directory; a record set is a file named after its type:
/mnt/r53fs/example.com/www/A— the A record forwww/mnt/r53fs/example.com/www/CNAME— the CNAME for the same name/mnt/r53fs/example.com/vixie/TXT— a TXT record
The rules that make the mapping work:
- Multiple values in a record set are multiple lines within the file.
- The zone apex uses the special name
@, so the root A record lives at@/A. - The TTL lives in a sibling file:
@/A.TTL. The default value is 300 seconds. - Alias records appear as symbolic links, so
readlinkdoes exactly what you’d expect. - Files that don’t correspond to a DNS record name are ignored, which has a consequence Percival points out: “So you could absolutely have a git checkout and update your DNS with
git pull.” Your zone under version control, applied with a pull. It’s not a joke feature — it comes free from the design.
Why can you mount a DNS zone over NFS?
Because AWS already built the hard part. S3 Files is a real AWS service, generally available since April 2026, that exposes S3 buckets as mounted NFS filesystems using the amazon-efs-utils client (sudo mount -t s3files $FS:/ /mnt/s3files, NFS 4.2 over TLS 1.2, according to AWS documentation).
Route 53 Files runs on top of it: your zone is projected to a bucket in your own account, and that bucket is what you mount. Percival says so in the FAQ, and explains both the timing and the design:
Why didn’t you launch on April 1st? “Because S3 Files launched in early April and I didn’t want to wait until April 2027.”
Why expose DNS zones over NFS instead of a FUSE filesystem? “Because it’s funnier. Also, because that’s what S3 Files does (but I repeat myself).”
That also explains the propagation numbers. A write reaches live DNS in about 90 seconds; a change made from the console or AWS API takes up to 6 minutes to show up in your mount. Concurrent edits are resolved with last-write-wins.
How do you install it?
Five steps, from the console at https://www.daemonology.net/r53fs/:
1. Generate the IAM role bundle. Runs entirely in the browser, with no network access. You give it your AWS account ID (12 digits) and your hosted zone IDs (comma-separated, or * for all).
2. Install the roles. Unzip the bundle, read README.txt, and run create-roles.sh with your AWS credentials. It creates four roles, plus an optional fifth for deprovisioning behind the --deprovisioning flag.
3. Register the zone. This is the only step that sends anything to Route 53 Files: account ID, a hosted zone ID, the region where the filesystem will be created, and the External ID from your bundle. That External ID can’t be recovered if you lose it.
4. Create a mount target, one for each availability zone in your VPC:
$ aws s3files create-mount-target \
--file-system-id fs-0123456789abcdef0 \
--subnet-id <a subnet in that VPC> \
--security-groups <a group allowing TCP 2049 from your clients> \
--region <your region>
It takes about five minutes to become available.
5. Mount the filesystem. You need amazon-efs-utils 3.0.0 or higher, and your instance role needs the AmazonS3FilesClientFullAccess policy:
$ sudo mkdir -p /mnt/r53fs/example.com
$ sudo mount -t s3files -o nodirects3read \
fs-0123456789abcdef0 /mnt/r53fs/example.com
TLS and IAM authentication are mandatory and can’t be disabled. If the mount fails with “Failed to resolve”, wait ten minutes before retrying.
How do you edit a record?
An A record at the apex:
$ echo 1.2.3.4 | sudo tee /mnt/r53fs/example.com/@/A
A second value in the same record set — use append, don’t overwrite:
$ echo 5.6.7.8 | sudo tee -a /mnt/r53fs/example.com/@/A
A new name, pointing to the apex as an alias:
$ sudo mkdir /mnt/r53fs/example.com/www
$ sudo ln -s ../@/A /mnt/r53fs/example.com/www/A
A TTL of 60 seconds, in the sibling file:
$ echo 60 | sudo tee /mnt/r53fs/example.com/@/A.TTL
How do you create a DNS wildcard?
The asterisk is an actual directory name, so you have to escape it from your shell:
$ sudo mkdir /mnt/r53fs/example.com/\*
$ echo www.example.com | sudo tee /mnt/r53fs/example.com/\*/CNAME
And the demo that defends the idea better than any argument: a cron that rewrites a TXT record every five minutes.
$ echo "*/5 * * * * root date > /mnt/r53fs/daemonology.net/vixie/TXT" | sudo tee -a /etc/crontab
$ sleep 600
$ dig +short -t txt vixie.daemonology.net
What doesn’t it support?
Routing policies. DNSSEC record types. Alias records with EvaluateTargetHealth. And the Route 53 control plane lives in us-east-1, so a regional outage there freezes your updates no matter where your filesystem is mounted.
Should you point production at it?
No, and the author is the first to say so. From the FAQ:
Is this an official AWS service? “Of course not; but I’d be happy to let them have it if they’re crazy enough to want to maintain it.”
Did anyone at Amazon know you were doing this? “Absolutely not. If they knew, they would have had to try to stop me.”
What happens if you run
rm -rf *? “Route 53 Files attempts to delete all of your DNS records, of course; what else would it do?”
That last one isn’t a joke. The filesystem semantics are honest in both directions, which means a careless glob deletes your zone.
Three practical warnings, as of August 28, 2026: the service is free and available in every commercial AWS region except Bahrain and the United Arab Emirates — both availability and freedom depend on one person continuing to maintain it. It’s a third party holding an IAM role in your account against your DNS, a trust decision worth making deliberately; the deprovisioning path exists precisely so you can reverse it. And the write path is a projection, not a transaction: 90 seconds one way, 6 minutes back, last write wins.
Where it does earn a place is in what it was built to demonstrate. If you ever wanted to diff two zones, grep across your DNS looking for an old IP, or keep your records in git without adopting Terraform for it, this is the shortest path that exists — built on a real AWS service, by someone who’s been reading AWS launch posts for twenty years and finally wrote one.