Contents

GitOps for DNS

⁶/Jan 2022

Domain Name Service (DNS) is the fundamental building block of every service. Operators love traditions: intranet IPv4 addresses, creating subnet, VLAN, and final octet conventions documented on the NetOps wiki before delegating DNS. When DNS is maintained through pet operations via a help desk API, developers become frustrated. Hence the long standing need for DNS GitOps.

DNS Represents Operational Maturity

The era of on-demand cloud resource expectations reveals problems with traditional network management.

Workaround abound, such as intranet IPv4 addresses, creating subnet, VLAN, and final octet conventions documented on the NetOps wiki
- These traditions break down when IPv6 is adopted; it is not practical to type in IPv6 addresses manually even once. We’re are trained with bad habits because typing in a IPv4 address is not too painful, but one could not fathom typing in a MAC address.

DNS must be adopted to solve this problem for network and service maturity, but DNS is treated as a hugely valuable pet. Because domain addresses are a part of corporate identity, the next set of problems are encountered:

Of course, this becomes a fight for control: who owns and manages DNS?
- The IT, Network team, the Windows Server team, the Active Directory team, the Linux team, etc.?
- This is compounded with any external, public, or cloud hosted DNS providers and with delegated administration to the above or separate cloud teams.
- How fragmented is DNS ownership, auditing, and reporting?
Pet traditions continue:
- Very few DNS software packages provide an API, hence files and server operations are handled by Operators.
- Developers have to tolerate because they don’t own the infrastructure or they escape to the cloud.
- Everyone outside of DNS adminstrators is forced to go through a process, typically IT help desk tickets, for an audit trail and pet Ops.

The novel solution of DNS GitOps is overdue: it advances operational maturity by delegating DNS to make developers happy! When you consider every operator and business person a developer of business value, then the entire organization is accelerated by DNS, the fundamental building block of every service.

DNS GitOps

GitOps principles is that everything is code and the user interface is git. Let me share a pilot I’m using for my home lab: home.lavi.us. BIND is an open source Unix and Linux based name server, well known and deployed for decades, so the BIND zone file format will be used.

Find a DNS hosting provider with an API and git interface.
- I’ve found exactly one: http://www.luadns.com/help#git-integration
Configure a new, dedicated Git repository.
- Considerations:
  - GitHub, BitBucket, and GOGS/Gitea are documented; I’m sure GitLab could be utilized.
  - It seems you should create a dedicated Git repository for your public hosted DNS zone files, unless you are comfortable with any additional information potentially being leaked by misconfiguration or hosting bugs. I suggest minimal exposure with a single repo, all zone files in the root, top directory of the repo.
  - I chose to create a dedicated, private GitHub repository, e.g.: mlavi/zones
  - Create, commit, and push zone BIND file(s):
    - vi home.lavi.us.bind
```
$TTL 60         ; 3600 secs = 1 hour
; The system will generate and maintain domain's SOA record automatically,
	NS	ns1.luadns.net.
	NS	ns2.luadns.net.
	NS	ns3.luadns.net.
	NS	ns4.luadns.net.
;
@	A	24.55.41.146
www	A	24.55.41.146
my	CNAME	www
```
    - git add home.lavi.us.bind && git commit -a -m 'Zone apex' && git push
Configure LuaDNS:
1. Register for a free account (you can administer three public domains) and log in to the administrative web console.
2. Home > Account Settings:
  1. Git Repository: Add your SSH Git URL, e.g.: git@github.com:mlavi/zones.git
  2. TTL: change to 300 (seconds = 5 minutes Time to Live)
    - You may want to make it shorter during development, I used the $TTL of 60 seconds in the bind file, above to override the account settings TTL.
  3. Copy the Deploy key
  4. “Show Token” and copy the API token
  5. API Access: Check the “Enable API Access” checkbox
  6. Optional: enable 2FA, because you love TOPT like me!
3. Home > Zones > Bulk Create:
  1. Enter up to three domains, then “Add Zones” to initialize.
    - This could be done via API. I wonder if there is a and cURL or Postman example somewhere?
Add a DNS deploy key and webhook to your Git repo according to documentation:
1. YourRepoName > Settings > Deploy keys: “Add deploy key”, give a title like “2022-LuaDNS” and paste the LuaDNS SSH deploy key, then “Add key.”
2. YourRepoName > Settings > Webhooks: “Add webhook”
  1. Substitute your API token value for the your_api_token portion of the URL in the examples for the webhook.
3. Outside of your LuaDNS web console credential, there are two secrets that will need RBAC and lifecycle consideration:
  1. Deploy key for SSH read only access to git repo
  2. API token from LuaDNS settings (seems to be only one at free tier?), used by the Git webhook with API token in URL
Test a DNS update operation!
1. Commit and push a zone file update: home.lavi.us.bind
  1. Check zone field with bind tool?
2. dig home.lavi.us
3. Review/troubleshoot:
  1. webhook should show API body reponse of {"message":"OK"}
  2. DNS web console: Home > Zones
    1. Check for new queries and DNS records

Benefits

This example of DNS GitOps is remarkable because it achieves a higher level of network, operations, and DNS maturity while democratizing DNS to developers and providing for the reality of short-lived, ephemeral services and their operations, which are:

Easy:
1. CLI: update zonefile.bind && git add zonfile.bind && git commit -a -m 'commit note' && git push
2. Using a GitHub webUI is even easier for non-developers and faster!
Safe and fully delegatable with auditable change control:
1. Delegate only a subzone of a domain, e.g.: home.lavi.us, not lavi.us.
2. Provide write access to each repo for the authorized git users and groups in your organization that share updates for zones
3. Revision control for every change also allows easy reversion via git!
4. Audits via CLI: git log and GitHub webUI
  1. GitHub: YourRepoName > Settings > Webhooks: https://api.luadns.com/notifications/… > “Recent Deliveries” tab > pick most recent from top of list > “Response” tab (hopefully with a HTTP status code of 200 = Success), see the Body field, look for {"message":"OK"} JSON formatted response.
5. See PaaS considerations for next steps.
Agile, fast, and free!
1. Updates can be done faster than making a ticket or even the manual pet ops
  1. However, the TTL is 300 seconds = 5 minutes for a potential update
2. DNS updates can be made part of build and deploy processes, CI/CD pipelines.

Further Considerations

Of course, there are enterprise considerations that should to be addressed:

LuaDNS service uptime (pet DNS host):
1. Administrator account, Deploy Key, and API token are all pets
2. The credential lifecycle of the above requires pet operations (unless leveraging APIs?) and potential human error and downtime during updates
3. Could another DNS account or higher level paid service tier or additional DNS provider solve this?
  - LuaDNS can also limit API rates and queries
  - Ideally solved through cattle DNS providers, added as additional authoritative NS records to all zones and additional git remote.
GitHub service uptime (pet Git host):
1. Shared responsibility for all zones in the repo, therefore one repo per zone is the worst case scenario. (No granularity for zones inside repo or subdirectories)
2. Easily solved by having multiple git hosting providers, setting them up with API access, and then pushing to any remote.
The pilot DNS GitOps example should evolve to a DNS PaaS experience:
1. DNS record lifecycle (removals) should be required in any automated provisioning.
2. This points towards git review cycles and potential automated governance rules on pre-commit and notifications on post-commit.
The BIND file format is text, not the best data format.
1. There are CLI validation tools and the DNS API should also validate for bad BIND configurations, but could this be improved? Certainly.
2. Would IaC and Lua Templates and their validation improve the situation?

Tags// dns, gitops, version-control, git,