DNS YAML is infrastructure of code for the management of authoritative DNS records. It allows its users to create yaml files describing the desired state of their authoritative DNS records, which can then be applied to their DNS server. DNS YAML does this through a concept called "mappers", which are adapters that are able to interact with different types of authoritative DNS solutions. The currently supported mappers are:
| powerdns | Maps to a powerdns mysql database. |
| scaleway | Maps to the scaleway DNS service. |
| dry | Reads in the document and checks if it's valid without actually mapping to anything. |
The software can be obtained from the source code repository or as a docker image from docker hub.
If you're just managing your personal infrastructure and want to have a way to manage the state of your DNS within the same version control repository as your ansible scripts, DNS YAML will be the missing piece of the puzzle for you.
While it hasn't been tested in large deployments, I think that this DNS YAML could be a great addition for large bodies of people who work on applications within the same infrastructure. Traditionally, DNS records are managed by sysadmins who edit zone files by hand, or through self-service UIs that some employees are allowed to acces. If one were to, in stead, use version controlled DNS YAML documents in combination with CI/CD, the following things would be achieved:
- Employees can create pull requests with DNS record changes that their projects require. These could be reviewed and merged by employees who are responsible for infrastructure, after which they can be applied to staging/production environments through the CI/CD system.
- The state of the DNS is reproducible. If the DNS service were to fail and its state was lost, it would be trivial to replace it and reapply its state with the DNS YAML document.
- Changes to DNS records are autidable through version control.
- Lastly, but not unimportantly, automated CI jobs could be setup for DNS YAML repositories to scan for stale DNS records that point to infrastructure that is no longer under the companies control. This is important, because leaving stale records unattended can be a security risk. Take A records that point to IP addresses that are not controlled by the company anymore for example. Those could be abused by bad actors who want to impersonate the company if they were to get their hands on that old IP address.
To help you get an idea, here is an example of a DNS YAML document, with below
it a Done CI file that could be used to check the document for validity and
apply it to production. The document contains examples of the different types
of record values that DNS YAML allows to be configured, which
are raw, file or round-robin.
domains:
example.com:
records:
- type: A
name: example.com
content:
type: raw
value: 127.0.0.1
- type: A
name: example.com
content:
type: round-robin
value: http-cluster
mail.example.com:
records:
- type: MX
name: mx.mail.example.com
content:
type: round-robin
value: mail-exchange
- type: TXT
name: _dkim.mx.mail.example.com
content:
type: file
value: dkim/mail.example.com.txt
round_robins:
http-cluster:
- 127.0.0.1
- 127.0.0.2
- 127.0.0.3
mail-exchange:
- mxa.examplemail.com
- mxb.examplemail.com
Below is a Drone CI pipeline configuration that validates the documents by
using the dry mapper and then applies the document to production
through the scaleway DNS service API using the scaleway mapper.
kind: pipeline
type: docker
name: default
steps:
- name: validate
image: hugotty/dns-yml:latest
commands:
- /dns-yml -mapper dry ./dns.yml
- name: publish
image: hugotty/dns-yml:latest
environment:
DNS_YML_SCW_ORG_ID:
from_secret: scaleway_org_id
DNS_YML_SCW_ACCESS_KEY:
from_secret: scaleway_access_key
DNS_YML_SCW_SECRET_KEY:
from_secret: scaleway_secret
commands:
- /dns-yml ./dns.yml
when:
branch:
- master
event:
- push
Last edited: Wed, 25 May 2022 07:03:35 +0000