This post has been copy-edited by doppler. Thanks!
Most research nerds either start writing Unix hagiographies or start stapling a 99-point thesis at the doors of Murray Hill. This is the latter kind of post; I’ll try to cover ideas for systems that could be meaningfully different from current systems. I’ve done a lot of research on existing concepts and existing systems, particularly those that could have been the future. Existing systems can be extrapolated into something new.
A lot of the ideas have been percolating in my head for a while now and are rough ideas for what could be. Perhaps I’ll iterate on them further, or realize there’s a reason no one was doing these before. The main idea is a place to start off, and it iterates from there. Treat it like a buffet of ideas; caveat emptor for people who don’t like musing.
With the “infrastructure as code” renaissance, managing infrastructure has never been easier. Every change is easily recordable and reproducible and, because it’s all code, it’s never been easier to store a history of what’s changed to easily review in
But short of running your own DNS servers and running custom scripts to convert code into a BIND zonefile, it’s historically been hard to manage DNS in the same way – so often, even though the servers themselves are easy to change, managing DNS means connecting to Route53, or Cloudflare, or any of a myriad of different domain registrars and DNS providers and manually changing fields in their application with no easy way to propagate changes across multiple domains or to roll back to a historical record if a new change causes something to break.
Using a tool like DNSControl, which allows a provider-agnostic view of DNS records as code, along with automatic capabilities to update records at your provides, fixes all of this.