Not having to deal with external state was one of the foundational design goals of octoDNS. The other being specifying a record once and pushing it to multiple providers. Those two in combination were the main reasons we didn't end up using Terraform to manage DNS and started octoDNS.

That did require making the initial decision that octoDNS would own the zone completely so that it could know it's safe to remove records that aren't configured, but later work with filters and processors does allow softening that requirement.

I've always had similar feelings about Terraform's state, in fact I started in on a prototype of an IaC system specifically to see if it was workable to avoid external state. The answer as far as that POC made it was yes. I was able to create VPCs, subnets, instances, to the point I stopped working on it. It was generally straightforward, but there was a hiccup for things that don't have a place to store metadata of some sort and the biggest issue was knowing when they were "owned" by the IaC.

I think some of the other issues that things would eventually run into would be around finding out what exists (again to be able to delete things.) The system would essentially have to list/iterate every object of every possible type in order to decide whether or not to delete them. Similar to octoDNS this could be simplified by making the assumption that anything that exists is managed, but that's not workable unless you're starting greenfield and it would still require calling every possible API to list things.

Anyway, I see why Terraform went the way it did, but I still wish it wasn't so. Thinking about it now makes me want to pick the POC back up...

(maintainer of octoDNS)

If you look through the octoDNS providers there's a number of cases where extra info is stored for "dynamic" records. The metadata is often things like the pool name or rule number. In other cases it's details about the health check config/version. The extra info is sometimes stored into a "notes" field, other times it's encoded into the ID or similar.

It's true that nothing extra is needed for simple/standard records, but once you start doing GeoDNS, failover, health check, etc. it's required.

In all cases thus far we've been able to find a way to store/indicate whatever we need.

(maintainer of octoDNS)

The main reason was the YAML config file could be easily understood. Since switching things over to use OctoDNS a couple months ago we've had nearly 75 PRs to make changes, mostly internal/testing/dev, but plenty of real stuff too. I don't have an exact number, but skimming over those there's probably ~25 people who have made those PRs.

In order to make it possible for anyone at the company to make PRs, not just SRE team members, we had to minimize or eliminate the learning curve and YAML was the best option for that we could think of. In the past those 75 PRs would have instead been issues asking an engineer on the infrastructure team to make the changes. It's been a huge and positive shift.

Thanks for explaining! So basically it comes down to "make this easier for non ops people to self-serve?

Yup! We review the PRs, but otherwise anyone at the company can submit them and deploy them out via chatops.

Sounds awesome!

Yeah. That's definitely something we looked closely at. I'd say the main difference is that OctoDNS abstracts away the details of the specific provider so that you write a single config that can be pushed to one or more places and changed over time without having to touch the records themselves.

Terraform requires creating a resource for each record and provider pair. It's good for orchestrating a single provider especially when you're otherwise creating associated resources with Terraform.

The custom DSL for each provider varies thought and I wasn't happy with my attempts at trying to abstract away which provider(s) things were going to using modules. The result wasn't simple enough that anyone at the company, not just engineers, could submit a PR for.

Thanks, that makes sense.

I wish that the terraform language was flexible enough to allow building such abstractions on top of it.

Secondary DNS functionality is usually implemented with AXFR which doesn't support advanced functionality like Geo DNS and also limits the providers you can choose as only a few offer it.

It also doesn't help with managing the records in the primary provider, requiring either working in a UI or writing using software like OctoDNS to manage it. It's definitely a good option for simpler and stable setups, neither of which is the case for us or many of the people I've talked to. If it fits a situation you have it's worth exploring.

There's an article on ZDnet, http://www.zdnet.com/article/github-open-sources-octodns-new... that does a good job of covering some of the reasons for it that is probably relivant to this.

There is support for sourcing data from djbdns config files, https://github.com/github/octodns/blob/master/octodns/source..., but not writing it out to that format currently. It shouldn't be too difficult for someone to add when they have a specific need it. Same goes for other software and providers.

There is a PowerDNS provider, https://github.com/github/octodns/blob/master/octodns/provid... which we use for some internal DNS purposes. We actually plan to talk about that in a future post to compliment this one's focus on our external DNS setup.

A lot of thought was put into making it relatively easy to add new ones. Writing the tests is generally the most involved part. There's a plan to add a doc on creating a new provider which I/we will hopefully get to soon.

thanks.

pixels of iPad screens: 768 * 7 = 5376 1024 * 3 = 3072 approximate dimensions: 51.75x27.5"

the booth is built with 3/4' laminated plywood, we'll have pics up soon (would already but the hotel wifi sucks.) the iPads sit on small metal L brackets fastened to the wall and are held in place heavy duty velcro. the L brackets have slots cut in them to allow the the connectors to pass through. everything is spaced and laid out such that the ipads are end-to-end horizontally and only have about 1/3" between them vertically. i'll try and get some close up pics tomorrow.

we used iPads b/c we're working on an app for iPads and it was a great way to instantly tell people what we're doing and it's just plain cool. most of your technical points are valid, but we wouldn't have enough power to run nine monitors at our booth. most importantly, no one would look twice at a massive monitor wall at comic-con. they're a dime a dozen and all of the big players have jumbo-tron style walls. we had loads of people comment on the iPad wall today and ask us how we did it. we even had the av guys from one of the big jumbo-tron companies come talk to us about how we built it.

looks pretty sweet