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.
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.
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.
Both DNS and S3 or any filesystem really... they're just key/value stores.
DNS also has considerably higher reliability and compatibility than almost anything else
I think its best usecase can be in agentic automation from what I can understand so far. I don't know if this is the correct read on the design choice.
If models/agents don't have to learn the various Route 53 & DNS API, and (with some guardrails) execute DNS jobs looking at it like a filesystem, it could make deployment automation quite simpler - and less prone to looping over wild esoteric solutions. FWIW a lot of the final knob pushes still require someone using a browser & clicking bunch of buttons. This simplifies it. "Everything is a file in UNIX" idea, but carried over to DNS & resource management
> cperciva has internalized the AWS blog style guide better than most Amazonians
A little bit of Canadian/non-American English slipped in (eg. enrol, behaviour), which AFAIK would have been flagged for a real Amazon post because as Americans we were brave enough to get rid of the 'U' in a lot of British words, like 'colour' and 'armour'. But by God, we kept the British 'U' in the word 'glamour'.
Yeah, I was aware of those... but I just couldn't bring myself to write American, especially in the current political climate. You can consider those a non-tariff trade barrier.
As a heavily disaffected American (who still can't wrap his head around the fact that we let this happen twice) I support any form of protest against us.
This is just the era of AWS (and amazon APIs). A lot of them look like SOAPy xml rpc because thats how they started, based on internal service frameworks. Check out SQS or S3 for similar examples.
Around 2010-11 there was a shift towards RESTish structures and json for serialization. A lot of methods and payloads still feel SOAPy, but look like json. I think it was DynamoDB which had the most unfortunate API with a literal xml-json transform live in the API service.
And then somewhere around 2015 you started seeing more well defined RESTish APIs with better tooling and adoption for smithy (and some openapi, iirc).
This is FANTASTIC! I laughed so hard I nearly fell out of my chair.
Have you seen DNSControl?
If you want a serious alternative to the Route53 API, there's an open source project called https://dnscontrol.org/ DNSControl. It's like Terraform for DNS but it doesn't suck like Terraform.
Version v5.0 just shipped. It's a major rewrite that makes it much more extensible.
I'll recommend dnscontrol as well, although the post is an unseasonal April fools joke, so helpful suggestions may be out of place.
The is-a.dev project uses dnscontrol to manage a subdomain registration service in GitHub, which is really clever. See https://github.com/is-a-dev/register
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.
And route53 makes DNSSEC very easy to enable so all the DNS data is cryptographic signed. This makes putting public keys and certificates in DNS much more sensible.
I knew of GPG key signing parties, but never anything at this scale or impact. Might try booting the "Signing Computer Operating System Image Release coen-2.0.1" ISO in a VM and checking it out.
> If the same record is changed in the file system and in Route 53 at the same time, we aim for last-write-wins. This is not strictly possible, since Route 53 does not expose modification timestamps on records
Except route 53 provides a fully ACID transactional API you can build your own locks with!
33 comments
[ 0.87 ms ] story [ 73.3 ms ] thread[0]https://banner.triweb.dev [1]https://news.ycombinator.com/item?id=39502097
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.
Both DNS and S3 or any filesystem really... they're just key/value stores.
DNS also has considerably higher reliability and compatibility than almost anything else
If models/agents don't have to learn the various Route 53 & DNS API, and (with some guardrails) execute DNS jobs looking at it like a filesystem, it could make deployment automation quite simpler - and less prone to looping over wild esoteric solutions. FWIW a lot of the final knob pushes still require someone using a browser & clicking bunch of buttons. This simplifies it. "Everything is a file in UNIX" idea, but carried over to DNS & resource management
A little bit of Canadian/non-American English slipped in (eg. enrol, behaviour), which AFAIK would have been flagged for a real Amazon post because as Americans we were brave enough to get rid of the 'U' in a lot of British words, like 'colour' and 'armour'. But by God, we kept the British 'U' in the word 'glamour'.
As a heavily disaffected American (who still can't wrap his head around the fact that we let this happen twice) I support any form of protest against us.
Stealing this. Gold lies at the intersection of cperciva and quinnypig.
Around 2010-11 there was a shift towards RESTish structures and json for serialization. A lot of methods and payloads still feel SOAPy, but look like json. I think it was DynamoDB which had the most unfortunate API with a literal xml-json transform live in the API service.
And then somewhere around 2015 you started seeing more well defined RESTish APIs with better tooling and adoption for smithy (and some openapi, iirc).
Have you seen DNSControl?
If you want a serious alternative to the Route53 API, there's an open source project called https://dnscontrol.org/ DNSControl. It's like Terraform for DNS but it doesn't suck like Terraform.
Version v5.0 just shipped. It's a major rewrite that makes it much more extensible.
https://github.com/DNSControl/dnscontrol/releases/tag/v5.0.0
The is-a.dev project uses dnscontrol to manage a subdomain registration service in GitHub, which is really clever. See https://github.com/is-a-dev/register
Not at all. Route 53 Files is a completely real service.
https://doug.sh/posts/route53-as-a-key-value-store-2026-edit...
https://www.iana.org/dnssec/ceremonies/62
I see you are following the Dyna53 [1] steps ;) What a school of thought you have sparked, Corey!
[1]: https://dyna53.io/
Except route 53 provides a fully ACID transactional API you can build your own locks with!