Colin Percival launches Route 53 Files, an unofficial AWS DNS filesystem

Why it matters

Route 53 Files turns a cloud infrastructure gag into a usable developer tool and a pointed demonstration of what one experienced founder can build on top of AWS primitives.

Colin Percival (@cperciva) launched Route 53 Files on August 27th, a free service that mounts Amazon Route 53 hosted zones as NFS file systems and represents DNS records as ordinary files. It is real enough to accept IAM roles and provision infrastructure inside a user's AWS account. It is unofficial enough that Percival's own FAQ answers the question of AWS affiliation with: "Of course not."

Percival is a plausible person to carry a cloud infrastructure joke all the way into production. He founded Tarsnap, the encrypted online backup service he began building in 2006, and has spent two decades using AWS while pointing out its security flaws and awkward abstractions. He studied mathematics at Simon Fraser University from age 13, completed a doctorate at Oxford and later served as FreeBSD's security officer. His FreeBSD work includes FreeBSD Update and Portsnap, tools built to make system maintenance less error-prone.

In an April account of his first 20 years on AWS, Percival traced a long relationship with Amazon that mixed unpaid engineering, security criticism and the work required to keep FreeBSD running on EC2. AWS named him a Community Hero in 2019. Route 53 Files fits that history: find an interface that bothers him, build the missing layer and make the critique executable.

A working joke with IAM permissions

Route 53 Files turns each DNS record set into a file and each record name into a directory. Writing an IP address into @/A creates an A record at the zone apex. Appending another line adds an address for round-robin DNS. TTL values live in adjacent .TTL files, while Route 53 alias records appear as symbolic links.

The result means echo, tee, sed, text editors and cron jobs can modify authoritative DNS. Changes also travel in the other direction: edits made through the Route 53 console, API or AWS CLI are eventually reflected in the mounted file system.

Percival's launch post says Route 53 Files works with public and private hosted zones and can be mounted from EC2, ECS, EKS and Lambda environments. Multiple compute resources can share a mount. The implementation uses Amazon S3 Files underneath, so users create mount targets with the AWS CLI and mount them using the s3files helper.

The Route 53 Files console generates IAM policy documents inside the browser, where users can inspect them before creating the roles in their AWS accounts. Enrollment requires an AWS account ID, hosted zone ID, region and external ID.

Those controls matter because Route 53 Files sits in front of production DNS. The product can read and write an enrolled zone, and a shell command aimed at the wrong path can remove records. The FAQ treats the inevitable rm -rf * question with literal precision: Route 53 Files will attempt to delete the records, while Route 53 itself preserves the zone's required SOA and apex NS records.

AWS launch copy, rewritten as product criticism

The product appeared four months after AWS launched Amazon S3 Files on April 7th. That service exposes S3 buckets over NFS and provides the infrastructure Route 53 Files repurposes.

Percival modeled his announcement closely on AWS's S3 Files launch post, following its structure and recasting its claims around DNS. AWS presented file access as a way for compute jobs and AI agents to work with S3 data. Percival extends the same framing to agents collaborating through file-based tools while mutating authoritative DNS, then adds on-call engineers reverting each other's changes with sed.

The joke lands because the underlying abstraction works. UNIX files are a durable interface for automation, and mapping DNS concepts onto directories, text files and symbolic links produces behavior an experienced operator can understand immediately. It also exposes how much safety is normally carried by purpose-built DNS tooling, validation and change-review systems.

Route 53 Files reports rejected writes asynchronously through .error files. It does not currently support routing policies, DNSSEC-specific record types or aliases with EvaluateTargetHealth enabled. Unsupported records appear in a .r53fs-unsupported file.

Percival also qualifies the concurrency model. Route 53 does not expose record modification timestamps, so strict last-write-wins conflict resolution is impossible. Route 53 Files estimates ordering from local write times and the window in which it detects an external Route 53 change.

Useful enough to be dangerous

Percival claims in the launch post that a file save takes roughly 90 seconds to reach live DNS, while a change made elsewhere in Route 53 can take up to six minutes to appear in a mount. Those figures have not been independently benchmarked, and DNS caching can delay global visibility further according to each record's TTL.

The latency rules out treating the mount like a conventional low-latency file system. Route 53 Files is closer to an asynchronous control surface that happens to speak NFS. A write can appear successful locally before Route 53 rejects it, while simultaneous edits may be resolved using an estimate rather than an authoritative timestamp.

Percival is offering Route 53 Files without a service fee. Users pay for the AWS infrastructure created in their accounts.

That pricing keeps the project in the tradition of founder-built infrastructure tools whose first job is proving a technical point. Tarsnap itself came from Percival's dissatisfaction with the backup services available in 2006. It entered public beta in November 2008 and became profitable in February 2009, according to Tarsnap's published history.

Route 53 Files makes a smaller wager: an experienced infrastructure founder can turn an absurd interface into working software faster than a large cloud provider can explain why anyone asked for it. Operators should still audit every permission and keep change controls around production zones. Percival built the sharp edges into the documentation rather than pretending they were not there.