It seems strange to make a sites DNS zone public as I have with Planet PowerShell, I put it all in a public Git repo. I thought long and hard about it, these entries are public after all, and you could easily discover all the information contained with 5 to 10 DNS queries. I just didn’t see any reason to keep the information private.

One of my goals with Planet PowerShell is to run and maintain it as a learning and teaching platform. I’ve learnt so much maintaining it, there's more to learn in the future too. I want the community to have the same opportunity to learn as I have. If this journey and this post helps just one other person, then it’s totally worth it.

There are some things that I can’t make public. Obviously, I can’t make the API credentials public, but I also want to protect the underlying Azure App Service infrastructure. I deliberately run Planet PowerShell behind CloudFlare, so the IP addresses of the Azure App Services needs to remain private. As with API credentials, I use tokens within the DNSControl files to protect these entries.

You can find everything in the Planet PowerShell Infrastructure repository on GitHub.

Components

So how should you manage your DNS? In this post we will put together a bunch of tools:

DNSControl: Defines the format of our zone configuration, checks it's valid, validates potential changes and then pushes the changes.

CloudFlare: My DNS provider of choice.

DNSimple: Who I buy domains from.

Git: Version control system of choice. We will store the zone configuration in a Git repository.

GitHub and VSTS: GitHub hosts the repository and VSTS the build and release pipelines.

Azure Key vault: Stores our sensitive credentials.

Docker: well why not?

Let’s investigate each with a little more detail.

DNSControl

The Stack Overflow team originally developed DNSControl to manage all their domains. After the DYN DDOS attack of 2016, many organisations were looking for better ways to manage their DNS and mitigate the next DNS attack, DNSControl is the result of Stack Overflows efforts.

DNSControl supports managing domain registrars, those who we buy domains from, and DNS providers, those who provide our DNS services, providing end-to-end management.

Support for registrars includes:

You can use DNSControl with a registrar that isn’t supported, for instance, GoDaddy. The none provider will allow you to manage a zone that you have purchased from a registrar who isn’t supported. Word of warning, some of DNSControl’s features may not work.

Support for DNS providers includes:

There's a few more providers (DYN, DNS Made Easy, Hexonet) waiting for their pull requests to completed. There is planned support for: Azure DNS, ClouDNS, Dns.he.net, GoDaddy, NameSilo, and Internetworx. You can always contribute if your favourite provider is missing.

At Readify, we have been using DNSControl to manage our own domains for a bit over a year. Anyone in Readify can propose a DNS change, and our Platforms team can then review and approve those requests. This empowers our developers and consultants to build new applications and systems without requiring complex changes from an infrastructure perspective.

You write the structure of your domain(s) using JavaScript, and then let DNSControl will handle the rest. Don’t worry, you don’t need any experience with JavaScript to be able to use DNSControl. If I can do it, anyone can! Later in this article I'll dive into the structure of a DNSControl configuration file.

One of the most powerful features of DNSControl is the ability for you to see what changes it will make before they occur. DNSControl makes use of a three-step process, first you check that a file has the correct syntax. Next you preview the changes including any additions, removals or modifications. Finally, you can push the changes to your provider.

Now I can hear you saying, “but surely migrating to DNSControl is really hard and risky?”. Here is the trick, the power of DNSControl makes migrating easy! If your DNS provider allows you to export your zone as a BIND file, there's a handy utility ( convertzone ) to convert BIND files to DNSControl files. With DNSControl’s ability to preview changes before pushing them, you'll be confident that everything will work as expected.

DNSControl also allows you to maintain a DNS zone across multiple providers. This gives you availability across different providers as well as to simple way to migrate between DNS providers. I recently used DNSControl to migrate a domain from Amazon’s Route 53 to Cloudflare. Zero down time, and zero stress.

If you don’t like DNSControl, I recommend looking at OctoDNS from the GitHub team. OctoDNS uses YAML to define the structure of the DNS zone, and supports an array of DNS providers. DNSControl can also integrate with OctoDNS.

CloudFlare

There are plenty of quality DNS providers, and for most users they differ little. Most within the IT community know CloudFlare for DDoS protection, and infamously for protectingLulzSec’s website. CloudFlare does more than just protecting a site from attacks. They can optimise your site’s content, add TLS, distribute content via their CDN and reduce the costs of running your site. CloudFlare provides all this through their extremely reliable and resilient DNS service.

CloudFlare don’t host your website, rather they route traffic through server servers. This routing allows them to make decisions over which connections get through, which connections hit cache, and which connections to reject. The thought of routing your websites traffic through a provider you might not know often makes people worried. It's a valid concern that CloudFlare might see your plaintext traffic, but I think the benefits outweigh the risks. Troy Hunt discusses the risks and benefits of CloudFlare in his post, “CloudFlare, SSL and unhealth security absolutism”.

I’ve used CloudFlare since it’s foundation in 2009, migrating my own domains, friends and even several workplaces to CloudFlare. For most people and organisations, the free tier will provide enough services and protection. If you want extra options, like custom certificates, you might need to upgrade to Pro or Business. If you're running large websites, reach out to CloudFlare and discuss their Enterprise plan.

When selecting a DNS provider, you really need to look at their reliability and availability over the past few years. Have they suffered any major outages? Did these outages impact customers? I find duckduckgo.com to be the best research tool. A good starting point would be providers that DNSControl support.

DNSimple

DNSimple are a relative new player to the domain registry and DNS provider market. In the last 8 years they've made a significant impression on the industry. DNSimple boasts a fantastic API, Slack integration, a great certificate purchasing experience, a range of TLDs and an excellent team support. I particularly like their sandbox environemnt to help developers work with their API.

At Readify, we have used DNSimple for domain registration, DNS hosting and particularly for SSL certificates for a few years. I recently made the decision to move from Namecheap, who I joined in 2003 over to DNSimple. I had some issues with my migration, I'll put together a write up later.

Don’t believe me? There are plenty of big names using DNSimple including Scott Hanselman and Troy Hunt, who provides an entertaining comparison of GoDaddy and DNSimple.

If you want to give DNSimple a go, use my referral code and get some credits on your subscription.

Git, GitHub and VSTS

Using a version control system is a core piece of this puzzle. Git provides us with history of all changes and who performed each change. Git encourages collaborative work; multiple people can make changes to a DNS zone without interfering with each other. Git branches are cheap and easy to merge, allowing for developers and engineers to make changes, verify them and them push them into production.

Platforms like GitHub, Bitbucket and Visual Studio Team Services (VSTS) extend Git with Pull Requests. Pull requests allow a person to ask another to review their changes and push them into a different branch or repository. The pull request process encourages discussions around work and changes, and we use rules to control who can review and approve changes. Pull requests are like change requests in ITIL, but they occur more quickly and more often, and don’t require a meeting to complete.

VSTS also provides a rich build and release pipeline experience. Automation of build, testing and release processes has accelerated the delivery of software and given rise to DevOps.

For this article, I host the DNSControl repository in GitHub and the build and release pipelines are in VSTS, but you could set this up using GitLab, AppVeyor, Travis CI or TeamCity.

Azure Key Vault

Key Vault helps you to protect cryptographic keys, certificates and secrets used within your cloud applications and within your CI/CD processes. Hardware Security Modules (HSMs) can be optionally used to protect keys and secrets, access policies can also be used to control access to Key vault.

Why is this important for a project like this one? DNSControl will need access (via API keys/tokens) to your DNS Provider(s) and your domain registrar. These are obviously sensitive credentials! An attacker with these could change your DNS, hijack our domains, buy other services or even take control of our domains.

Using VSTS variable groups, we can access Key Vault as part of the build and release pipeline.

I recommend storing your API tokens, in this case those for DNSimple and CloudFlare, in Key Vault.

With Planet PowerShell I also stored the Azure App Service IP address and URLs in Key Vault. This is purely a personal preference, I just wanted to keep all my application settings in a single place.

If you don't have an Azure Subscription, you can use the private/encrypted option within the VSTS variable groups to store your sensitive information.

Docker

There are 2 benefits for using the containerized version of DNSControl.

Releases are more frequent for the Docker container. Whenever code is pushed to master and successfully built, the docker image ( latest tag) is updated. This provides a faster release cycle and you'll get bug fixes and new features faster than the Windows, MacOS or Linux releases.

Another advantage of using Docker is that we don’t need to install anything on your system (provided you have Docker). I'm trying to keep my installed application base smaller on my personal laptop fleet (MacBook, Dell Precision and Razer Blade Stealth). By using Docker, I don’t have to install Go or DNSControl onto laptios or VSTS Agents.

If you want to join the Cult of Docker, we now have t-shirts!

Working with the DNSControl file

There are two files that we need to define to manage your DNS zones with DNSControl. The first is dnsconfig.js ; this is a JavaScript file that will contain the definition of your zone(s). You define the credentials for accessing your domain registry and DNS provider in the creds.json file.

I recommend starting by setting up your creds.json file. The required entries are going to be different for each provider, look at the DNSControl documentation for more help. For Planet PowerShell, we have 2 entries, one for CloudFlare and one for DNSimple. It looks like:

{ "cloudflare.com":{ "apikey": "#{cloudflareapikey}#", "apiuser": "#{cloudflareapiuser}#" }, "dnsimple": { "token": "#{dnsimpleapitoken}#" } }

It's important that you don’t put any of your credentials into this file and then place it into a public Git repository. If you do that, someone might be able to hijack your domain! To support automated build and release, I use tokens within the creds.json file. The Replace Tokens task will replace any entries surrounded by #{ }# . For instance, #{cloudflareapikey}# will be replaced with the contents of the cloudflareapikey variable in VSTS.