Speaking as a former Blog Bar Raiser, cperciva has internalized the AWS blog style guide better than most Amazonians. This is spot-on.
Wait, there's an official style guide?<p>(In all seriousness, I've been reading AWS launch posts for 20 years; this one was mainly imitating the S3 Files launch post but I diverged by adding the customer quote and the FAQ -- because of course I started this process with a PRFAQ, and some of the questions in the FAQ are legitimately important.)
I left 18 months ago, so my memory is a bit fuzzy, but there was at least an overall style guide, one for each post type (e.g. a launch announcement), and the style for procedures (inherited from AWS Docs).
Oh, I was being facetious. I'm pretty sure Jeff mentioned needing to spend time writing a style guide when he started having other Amazonians write posts for "his" blog.<p>As a non-Amazonian I've never seen it, of course.
At first I thought this was a general purpose file system over R53, ala Corey Quinn. But my, what a gorgeously terrible idea. Well done.
Route53 makes a great, simple, HA key-value store for some use cases. I've used it in GitHub Actions when nothing else was easily available to store values and put a little post together explaining how a while back. For many things, there isn't a reason for more complexity.<p><a href="https://doug.sh/posts/route53-as-a-key-value-store-2026-edition/" rel="nofollow">https://doug.sh/posts/route53-as-a-key-value-store-2026-edit...</a>
Fun! Reminds me of <a href="https://github.com/nathanvy/dnsbbs" rel="nofollow">https://github.com/nathanvy/dnsbbs</a>
A “schema that reads like XML that learned JSON in prison” IM DEAD<p>Stealing this. Gold lies at the intersection of cperciva and quinnypig.
Are there that many people managing their dns by hand that they need this? Outside of various txt records, most of my domains are mapped to specific resources via automation.
There are apparently many people managing their S3 Objects by hand but long to have them in a file system, yes.
I don't think this is there to satisfy "need".<p>But "automation" with this could legitimately (well, mostly) be based on a git repo with an s3files mount inside it. And a cron job, if you really want to get fancy.
Last job, we did for various control/audit reasons BUT it was all IaC and tickets.
This is... well it's mostly a joke. It's funny but you can indeed use and interact with DNS as a file store or have a file system based control over records.<p>Both DNS and S3 or any filesystem really... they're just key/value stores.<p>DNS also has considerably higher reliability and compatibility than almost anything else
> Are there that many people managing their dns by hand that they need this?<p>How many thousands or millions of employees does your org have? And how many projects deployed over the decades?
<p><pre><code> > Q. Is this HIPAA compliant?
> A. Please do not store patient information in DNS.
</code></pre>
love this. reminds me a little of something else in the realm of DNS "hosting" posted to hn a few years ago [0][1]<p>[0]<a href="https://banner.triweb.dev" rel="nofollow">https://banner.triweb.dev</a>
[1]<a href="https://news.ycombinator.com/item?id=39502097">https://news.ycombinator.com/item?id=39502097</a>
Am I the only one who thinks that read() and write () (block based api) would be a poorer experience for managing key/value dns records?
This is FANTASTIC! I laughed so hard I nearly fell out of my chair.<p>Have you seen DNSControl?<p>If you want a serious alternative to the Route53 API, there's an open source project called <a href="https://dnscontrol.org/" rel="nofollow">https://dnscontrol.org/</a> DNSControl. It's like Terraform for DNS but it doesn't suck like Terraform.<p>Version v5.0 just shipped. It's a major rewrite that makes it much more extensible.<p><a href="https://github.com/DNSControl/dnscontrol/releases/tag/v5.0.0" rel="nofollow">https://github.com/DNSControl/dnscontrol/releases/tag/v5.0.0</a>