🚀
DNSControl
🚀
DNSControl
  • Introduction to DNSControl
  • Getting Started
    • Overview
    • Examples
    • Migrating zones to DNSControl
    • TypeScript autocomplete and type checking
  • Language Reference
    • JavaScript DSL
    • Top Level Functions
      • D
      • DEFAULTS
      • DOMAIN_ELSEWHERE
      • DOMAIN_ELSEWHERE_AUTO
      • D_EXTEND
      • FETCH
      • HASH
      • IP
      • NewDnsProvider
      • NewRegistrar
      • PANIC
      • REV
      • REVCOMPAT
      • getConfiguredDomains
      • require
      • require_glob
    • Domain Modifiers
      • A
      • AAAA
      • ALIAS
      • AUTODNSSEC_OFF
      • AUTODNSSEC_ON
      • CAA
      • CAA_BUILDER
      • CNAME
      • DHCID
      • DNAME
      • DNSKEY
      • DISABLE_IGNORE_SAFETY_CHECK
      • DMARC_BUILDER
      • DS
      • DefaultTTL
      • DnsProvider
      • FRAME
      • HTTPS
      • IGNORE
      • IGNORE_NAME
      • IGNORE_TARGET
      • IMPORT_TRANSFORM
      • IMPORT_TRANSFORM_STRIP
      • INCLUDE
      • LOC
      • LOC_BUILDER_DD
      • LOC_BUILDER_DMM_STR
      • LOC_BUILDER_DMS_STR
      • LOC_BUILDER_STR
      • M365_BUILDER
      • MX
      • NAMESERVER
      • NAMESERVER_TTL
      • NAPTR
      • NO_PURGE
      • NS
      • PTR
      • PURGE
      • SOA
      • SPF_BUILDER
      • SRV
      • SSHFP
      • SVCB
      • TLSA
      • TXT
      • URL
      • URL301
      • Service Provider specific
        • Akamai Edge Dns
          • AKAMAICDN
        • Amazon Route 53
          • R53_ALIAS
        • Azure DNS
          • AZURE_ALIAS
        • Cloudflare DNS
          • CF_REDIRECT
          • CF_SINGLE_REDIRECT
          • CF_TEMP_REDIRECT
          • CF_WORKER_ROUTE
        • ClouDNS
          • CLOUDNS_WR
    • Record Modifiers
      • TTL
      • Service Provider specific
        • Amazon Route 53
          • R53_ZONE
          • R53_EVALUATE_TARGET_HEALTH
    • Why CNAME/MX/NS targets require a "dot"
  • Provider
    • Supported providers
    • Akamai Edge DNS
    • Amazon Route 53
    • AutoDNS
    • AXFR+DDNS
    • Azure DNS
    • Azure Private DNS
    • BIND
    • Bunny DNS
    • CentralNic Reseller (CNR) - formerly RRPProxy
    • Cloudflare
    • ClouDNS
    • CSC Global
    • deSEC
    • DigitalOcean
    • DNS Made Easy
    • DNSimple
    • DNS-over-HTTPS
    • DOMAINNAMESHOP
    • Dynadot
    • easyname
    • Exoscale
    • Gandi_v5
    • Gcore
    • Google Cloud DNS
    • Hetzner DNS Console
    • HEXONET
    • hosting.de
    • Huawei Cloud DNS
    • Hurricane Electric DNS
    • Internet.bs
    • INWX
    • Linode
    • Loopia
    • LuaDNS
    • Microsoft DNS Server on Microsoft Windows Server
    • Mythic Beasts
    • Namecheap
    • Name.com
    • Netcup
    • Netlify
    • NS1
    • OpenSRS
    • Oracle Cloud
    • OVH
    • Packetframe
    • Porkbun
    • PowerDNS
    • Realtime Register
    • RWTH DNS-Admin
    • Sakura Cloud
    • SoftLayer DNS
    • TransIP
    • Vultr
  • Commands
    • preview/push
    • check-creds
    • get-zones
    • get-certs
    • fmt
    • creds.json
    • Global Flag
    • Disabling Colors
  • Advanced features
    • CI/CD example for GitLab
    • CLI variables
    • Nameservers and Delegations
    • Notifications
    • Useful code tricks
    • JSON Reports
  • Developer info
    • Code Style Guide
    • Documentation Style Guide
    • DNSControl is an opinionated system
    • Writing new DNS providers
    • Creating new DNS Resource Types (rtypes)
    • Integration Tests
    • Test a branch
    • Unit Testing DNS Data
    • Bug Triage Process
    • Bring-Your-Own-Secrets for automated testing
    • Debugging with dlv
    • ALIAS Records
    • TXT record testing
    • DNS records ordering
  • Release
    • How to build and ship a release
    • Changelog v3.16.0
    • GitHub releases
Powered by GitBook
On this page
  • DNSControl - Demo setup
  • GitLab CI - Preparation
  • GitLab CI - DNSControl preview
  • GitLab CI - DNSControl push
  • GitLab CI - Duplicate YAML configuration
Edit on GitHub
  1. Advanced features

CI/CD example for GitLab

PreviousDisabling ColorsNextCLI variables

Last updated 5 months ago

Before discussing the GitLab CI/CD setup, let's assume you already have a working DNSControl setup. Aren't you there yet? Then first check out the '' section.

DNSControl - Demo setup

For this tutorial, there is a ready with an example DNSControl setup/domain.

This is based on:

  • The domain cafferata.dev.

  • The DNS provider .

  • The TransIP account cafferatax.

For convenience, both configuration files are shown below.

dnsconfig.js
var PROVIDER_NONE = NewRegistrar("none");
var PROVIDER_TRANSIP = NewDnsProvider("transip");

D("cafferata.dev",
    PROVIDER_NONE,
    DnsProvider(PROVIDER_TRANSIP),
    DefaultTTL("1d"),
    TXT("spf", [
        "v=spf1",
        "-all"
    ].join(" ")),
);
creds.json
{
  "transip": {
    "TYPE": "TRANSIP",
    "AccountName": "cafferatax",
    "PrivateKey": "$TRANSIP_PRIVATE_KEY"
  }
}

GitLab CI - Preparation

You may have noticed that the creds.json file contains a variable $TRANSIP_PRIVATE_KEY. This variable is populated from the GitLab CI variables and contain the TransIP API key.

-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDgJjUQcUrijxul
NbbN+KD3tDISPDczuJW8HYZRafOc9BgHWuYiBcE+1+9mzHi7FOujuHuTBD84vvRN
x9buaOLoJNjCvtHDtotYQMhUWF8bnNYyoIIdJGXXcRG0G0+NNreVQiZ+5IQIvhRU
PXyjvUdQoIaRc9S5NxAMbGLJUHtZ4LEdJKa7HmCXAA5dBYaMMSZjpdBJImSJAtxj
msseUkc0EiznGgsBVMOkn3VMba2gjo5RDGbfXXLUX3DTOKdwY+hdWktG/gO/3D9l
hY/gnT/MmXXko3YAcI4eQL8=
-----END PRIVATE KEY-----

Example of variable $TRANSIP_PRIVATE_KEY contents.

GitLab CI - DNSControl preview

.gitlab-ci.yml

dnscontrol-preview:
  stage: 'test'
  image:
    name: 'stackexchange/dnscontrol'
    entrypoint: ['']
  script:
    - '/usr/local/bin/dnscontrol version'
    - '/usr/local/bin/dnscontrol check'
    - '/usr/local/bin/dnscontrol preview'
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      changes:
        - 'dnsconfig.js'

What does this YAML configuration mean?

  • Because the choice was made not to adopt a version, it's nice to know from the GitLab CI jobs which version DNSControl is running. We check and validate the DNSControl set-up dnsconfig.js.

  • Then we ask TransIP which DNS diff there is.

  • (!) This only happens in the context of a GitLab merge request and (very important) only when there is a change in the DNSControl configuration (dnsconfig.js).

Because the above GitLab CI configuration expects a diff, we apply this by (for example) adding the Google Workspace SPF include.

dnsconfig.js

var PROVIDER_NONE = NewRegistrar("none");
var PROVIDER_TRANSIP = NewDnsProvider("transip");

D("cafferata.dev",
    PROVIDER_NONE,
    DnsProvider(PROVIDER_TRANSIP),
    DefaultTTL("1d"),
    TXT("spf", [
        "v=spf1",
+       "include:_spf.google.com",
        "-all"
    ].join(" "))
);
/usr/local/bin/dnscontrol version
dnscontrol "3.20.0" ("8bb63be8f5ed996a7ae0a21091954fcab996621b") built 26 Aug 22 14:59 UTC
/usr/local/bin/dnscontrol preview
******************** Domain: cafferata.dev
1 correction
#1: MODIFY TXT spf.cafferata.dev: ("v=spf1 -all" ttl=86400) -> ("v=spf1 include:_spf.google.com -all" ttl=86400)
Done. 1 corrections.

GitLab CI - DNSControl push

.gitlab-ci.yml

dnscontrol-push:
  stage: 'deploy'
  image:
    name: 'stackexchange/dnscontrol'
    entrypoint: ['']
  script:
    - '/usr/local/bin/dnscontrol version'
    - '/usr/local/bin/dnscontrol push'
  rules:
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE == "web"'

What does this (new) YAML configuration mean?

/usr/local/bin/dnscontrol version
dnscontrol "3.20.0" ("8bb63be8f5ed996a7ae0a21091954fcab996621b") built 26 Aug 22 14:59 UTC
/usr/local/bin/dnscontrol push
******************** Domain: cafferata.dev
1 correction
#1: MODIFY TXT spf.cafferata.dev: ("v=spf1 -all" ttl=86400) -> ("v=spf1 include:_spf.google.com -all" ttl=86400)
SUCCESS!
Done. 1 corrections.

GitLab CI - Duplicate YAML configuration

This eventually brings us to the following GitLab CI setup.

.gitlab-ci.yml

.dnscontrol:
  image:
    name: 'stackexchange/dnscontrol'
    entrypoint: ['']
  before_script:
    - '/usr/local/bin/dnscontrol version'

dnscontrol-preview:
  extends: '.dnscontrol'
  stage: 'test'
  script:
    - '/usr/local/bin/dnscontrol check'
    - '/usr/local/bin/dnscontrol preview'
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      changes:
        - 'dnsconfig.js'

dnscontrol-push:
  extends: '.dnscontrol'
  stage: 'deploy'
  script:
    - '/usr/local/bin/dnscontrol push'
  rules:
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE == "web"'

Now it's time to apply the power of DNSControl within GitLab CI merge requests. We'll start by adding the basic GitLab CI setup. You can view the git diff online in the . The GitLab CI setup has also been added for convenience.

The dnscontrol preview is run within the GitLab CI test using the Docker image .

A conscious decision has been made to always use the latest version so that no maintenance is required. Of course you can choose to include a Docker image version. You do this by choosing from the , and including it in image: for example: name: 'stackexchange/dnscontrol:v3.20.0'

From that moment everything comes together! Within the , a with a starts running containing the command dnscontrol preview. The outcome of this job? The desired change that will be made within TransIP. Wow this is cool!

We just saw that we can view the DNSControl diff from the . Now it's time to make GitLab CI responsible for the command dnscontrol push.

From here several choices can be made. You can choose to have the dnscontrol push run as soon as a merge request is pushed to default branch (e.g. main), or from a GitLab pipeline trigger within the . We have opted for the so that it cannot happen that DNS changes are made from previous merge requests in default branch (e.g. main).

It will probably not surprise you that the basis of this GitLab YAML configuration corresponds for 90% with the DNSControl preview. See the here.

The dnscontrol push is run within the GitLab CI deploy.

This only happens when you start a GitLab pipeline from the for the default branch (e.g. main).

When we start the new from the , we see the GitLab job which makes the changes within the DNS provider TransIP.

We have a working setup at this point that includes a dnscontrol preview and a dnscontrol push command. Well done! You might consider cleaning up the duplicate GitLab YAML configuration. We can move the DNSControl image name and entrypoint to a GitLab YAML extends. Then we can also move the duplicate dnscontrol version command to a GitLab before_script. See the third (and also last) .

If you are unexpectedly unable to set up this setup, feel free to about it.

Getting Started
GitLab repository
TransIP
GitLab merge request #1
predefined stage
stackexchange/dnscontrol
available versions
GitLab merge request #1
GitLab pipeline
GitLab job
GitLab job
GitLab web interface
GitLab pipeline web interface
GitLab merge request #2
predefined stage
GitLab web interface
GitLab pipeline
GitLab web interface
dnscontrol-push
GitLab merge request #3
ask questions
GitLab CI/CD variables
Insert GitLab CI/CD variable TRANSIP_PRIVATE_KEY
CI/CD job output for DNSControl preview
Start new CI/CD pipeline from the GitLab web interface
CI/CD job output for DNSControl push