So like, Google Domains.

I liked Google Domains. I had a bunch of domains registered there. I registered them with Google Domains because whatever Google's faults, they have an outstanding record on security, because they hire some of the best people in the world. It was a very well-designed, easy-to-use service that did what I wanted it to and nothing more which is exactly the sort of thing Google likes shutting down.

Of course I was notified that Google sold it to Squarespace, which I was sad about. I intended to do something before my domain was moved to Squarespace, and also that was effort, so I procrastinated and forgot about it, i.e. didn't do it. Because I didn't do it, I was automatically moved onto Squarespace, which didn't work out well.

I used Google Domains because of Google's security posture, and the fact the domain registry industry is a security tyre-fire. Ironically, the sale to Squarespace resulted in a massive security problem which allowed anyone to hijack any account. This proved past-me right, but only in the most irrelevant way possible; using Google Domains directly resulted in a time window where anyone could have hijacked all of my domains.

Squarespace also lacked basic functionality for DNS. I know why they did this; it's because their target market is non-technical people, a category which does not include me. But I do not consider complete inability to set a TTL on DNS records to be normal. I also don't consider inability to export a zone file to be normal either.

Squarespace does what it needs to do for the market it targets. It is nerfed as a DNS management tool. That plus a catastrophic security hole on day one made me want to switch to something else, which I did, eventually.


So, I made the obvious error of being on Google Domains in the first place, despite Google's history of randomly killing shit off even if you are paying for them. And I didn't migrate to something else before the Squarespace switchover, because I couldn't be bothered and/or procrastinated. Both of those things were entirely self-inflicted.

Why did I procrastinate over moving somewhere else? Because moving over DNS records was effort. That seems like an insanely trivial reason, because it is. But I have lots else to do, and that one thing to do fell by the wayside. Maybe I could have solved this for the longer term by divorcing my DNS management from my domain registrations, but that too would be effort, and then I would be paying for two things, either of which could disappear like Google Domains did. How, then, could I make moving DNS records between registrars easier?

What would be really neat is if I could manage my DNS configuration as a text file on my computer. That text file on my computer would be the source of truth, to be pushed to whatever DNS provider I am using at the time, so I can swap out providers at will. As with all text files on my computer, it could be managed as a Git repository, so I have the complete history of it available, so if I break something I can easily roll back to an earlier version. Wouldn't that be cool?

WELL IT JUST SO HAPPENS

...that this exists, and also that I eventually get to the point. It's called DNSControl, and I like it.

I make a text file called dnsconfig.js which looks like this:

// These two things are defined in my other config file, `creds.json`, which
// contains my API keys.
//
// The names in the files below do not have to correspond to provider names;
// they map to entries in `creds.json`. It's less effort to make them match
// though.
var REG_GANDI = NewRegistrar("gandi");
var DSP_GANDI = NewDnsProvider("gandi");

D(
    "lewiscollard.com",
    REG_GANDI,
    DnsProvider(DSP_GANDI),

    // Records for the apex domain and www.
    A("@", "138.68.161.203"),
    A("www", "138.68.161.203"),
    // all my other records go here
)

OK, not a text file; it's actually JavaScript with some stuff shoved into the global namespace to make it look like a DSL. Someone could mumble something about Turing-complete configuration files, and I'd mumble something back like "yeah innit". I mean, all programmers dislike the idea of writing configuration files in a programming language in theory, and then we're all secretly thankful that we get variables and loops and conditionals and stuff when someone else implements their configuration file with a programming language. And then we all go around with guilty consciences! I recommend sitting on your hands till they go numb before writing your config file; that way it'll feel like someone else is doing it.

Anyway, there's also a creds.json which looks like this:

{
  "gandi": {
    "TYPE": "GANDI_V5",
    "token": "XXXX",
    "sharing_id": "YYYY"
  }
}

This tells DNSControl which provider I want to use, and has API keys for it. I moved my domains and DNS to Gandi, because they exist, they were easy to migrate to, and they're probably as good as anyone for all I know. The "awesome" comes in when I can switch this to use any one of over 50 providers, meaning that moving my DNS records somewhere else is entirely automated (other than creating API keys for them). Awesome!

Squarespace is notably absent from that list of providers, because they don't have an API for managing DNS records. If it wasn't for this I might have even stayed with Squarespace for my domain registrations, because it is less effort. The security hole was forgivable; all software has flaws. But now that I know DNSControl exists, I don't want to manage my DNS records via a web interface ever again, so I won't.

After I changed my configuration, I run dnscontrol preview to see what things will be changed, then dnscontrol push to push them to Gandi. I could make things even fancier than this. I could set up CI, so that pushing changes to my remote Git repository automatically pushes changes to Gandi, which would save me having to run DNSControl manually after each change. That would eliminate the risk of my Git repo not reflecting reality. But for now I am happy enough that I can manage my DNS with version-controlled text files; maybe I'll do the CI thing some other day (and here I was to write "this is a magic spell which disappear forever", then I realised I used that joke before).

I like that DNSControl stops you from making mistakes. It could have been a straight translator from zone files to API calls, and fortunately it is not. It has opinions, and those opinions are good because they stop you doing stupid things.

I like that DNSControl is a single binary, which is also a thing I like about Hugo. That means that I can check the binary into the repo via LFS and it'll probably work for as long as I'm using an x86-64 Linux system, which might be as close to "forever" as I care to look.

Also, finally, the documentation. It has it! Lots of it! I never had to Google anything, nor copy-paste magic spells from random GitHub issues and Stack Exchange posts as I do with most other config file formats.

Anyway, this post is really about me and things I like, because that's what this site is, rather than being any kind of useful introduction to DNSControl. But if someone somewhere reads this who hasn't heard of DNSControl might consider using it now, I wouldn't mind that at all.