Tracking DNS Records in Version Control

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 Atlantis internally)
• The content of the Terraform files is clearly defined in the documentation

Here is the main zone for businessinsider.com (one zone per Terraform file)

Here is how www.businessinsider.com is defined

The tricky part of the initial implementation was how to import the existing NS1 domains into the Terraform resources (remember that that we have hundreds of DNS records across almost a dozen domains).

The solution for this? Automation! I wrote a Python script import the existing resources into the Terraform state. It automates adding the resources to the Terraform files, too.

The script can be found in this gist.

Terraform Execution

Internally, we use Atlantis to automate the process of running terraform plan and apply. The process works as follows:

1. An engineer opens a pull request that updates a terraform file
2. Atlantis automatically runs terraform plan and shows the result as a comment in the PR
3. After getting the pull request code reviewed and approved, the engineer will comment atlantis apply
4. Atlantis will run and show the output of a terraform apply and automatically merge the pull request

Conclusion

While the initial implementations weren’t ideal, I think it’s difficult to argue with the end result. Updating DNS records has gotten so easy that even individuals on different teams have gotten in on it.

Looking for a new job opportunity? Become a part of our team! We are always looking for new Insiders.