
Enabling DNS split authority with OctoDNS - samlambert
https://githubengineering.com/enabling-split-authority-dns-with-octodns/
======
anthony_franco
If you're looking to simply keep two DNS providers in sync, you can just set
one up as a Secondary DNS. Dyn provides this as a feature and that keeps our
DNSMadeEasy and Dyn accounts synchronized without having to think about it.

~~~
rwmcfa1
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...](http://www.zdnet.com/article/github-open-sources-
octodns-new-tool-for-managing-dns-records/) that does a good job of covering
some of the reasons for it that is probably relivant to this.

------
zimbatm
Why not use an existing tool like terraform?

Terraform is able to manage resources from dyn, route53 and other DNS
providers fairly easily.

~~~
rwmcfa1
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.

~~~
zimbatm
Thanks, that makes sense.

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

------
kensey
This is great if all your DNS is done via cloud providers like Dyn and
Route53, but can I use this to manage zones in traditional DNS instances? I
don't see a BIND/dnsmasq/djbdns provider or any code referencing those or
other traditional name servers.

~~~
rwmcfa1
There is support for sourcing data from djbdns config files,
[https://github.com/github/octodns/blob/master/octodns/source...](https://github.com/github/octodns/blob/master/octodns/source/tinydns.py),
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...](https://github.com/github/octodns/blob/master/octodns/provider/powerdns.py)
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.

------
mdekkers
What is the benefit of using a yaml format as opposed to the ubiquitous bind
zone file format?

~~~
rwmcfa1
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.

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

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

~~~
mdekkers
Sounds awesome!

