This blog originally appeared on the Business Insider blog, Insider Inc.
During my first month at Insider Inc, I was given my first real task — figuring out how to track DNS records in version control. Our company has hundreds of DNS records across half a dozen domains and managing them has become cumbersome, to say the least. To paraphrase our tech lead, “I don’t want to have to ever see the Dyn console for the rest of my life.”
The DNS infrastructure setup was simple enough. Dyn was in use as the primary provider, with NS1 as secondary. If someone wanted to make a DNS change, they would have to log into the Dyn console. Making this change seemed simple enough at first, so I got to work. (Note: More information about the primary-secondary DNS relationship here.)
First attempt: The Dyn API
Dyn provided what appeared to be a robust API with great documentation and it even had a Python package, as well.
Unfortunately, actually working with it was less than ideal. I had a lot of trouble making simple requests with the Python package, so I had to resort to making requests using the requests Python package.
The above code instantiated a Dyn Session. With it, I could make requests to update DNS records. Still, the API wasn’t the easiest to work with, so I turned my attention over to NS1.
Second attempt: NS1 as the primary
The NS1 API had much better documentation and, even better, included its own up-to-date Python package. This would require us to migrate NS1 as our primary provider, which this turned out to be a relatively trivial task.
The below code is a little proof of concept I quickly scratched together using our test zones in NS1.
Here’s the general structure for how the project as a whole would work:
- DNS records would be stored in a series of YAML files (one YAML file per domain stored in the ns1configs directory)
- Once DNS record was committed, a Jenkins Pipeline would be triggered
- The script would parse the YAML files and detect changes in the record in the YAML file against what NS1 currently had, and then make the appropriate update
Unfortunately, this proved cumbersome for a few reasons:
- We would need to maintain the Python script as well as the YAML files containing the DNS records
- There are a lot of moving parts and it would be very easy for something like this to break
- The YAML files themselves became a bit too much to handle
For the above reasons, this was shelved in favor of . . .
Final attempt: Terraform!
NS1 offers a Terraform provider!
This solves the above issues by
- Only the Terraform files need to be maintained (no external script necessary)
- Making DNS updates is as simple as a Terraform apply (we use Atlantisinternally)
- The content of the Terraform files is clearly defined in thedocumentation
Here is the main zone for businessinsider.com (one zone per Terraform file)
Here is how www.businessinsider.com is defined