add goodroots.work caa_management

[colin-stubbs]

Description

Add the Good Roots Work Domain Connect template to support programmatic management of DNS CAA policy records.

Type of change

Please mark options that are relevant.

• New template
• Bug fix (non-breaking change which fixes an issue in the template)
• New feature (non-breaking change which adds functionality to the template)
• Breaking change (fix or feature that would cause existing template behavior to be not backward compatible)

How Has This Been Tested?

Please mark the following checks done

• Schema validated using JSON Schema template.schema
• Template functionality checked using Online Editor
• Template is checked using template linter
• Template file name follows the pattern <providerId>.<serviceId>.json

NOTE: Despite all of the Domain Connect documentation describing CAA record support the template linter did not support CAA records yet. I have added support via PR#17

dc-template-linter with added CAA support has no issues with our template,

user@box domain-connect-templates % dc-template-linter goodroots.work.caa_management.json
user@box domain-connect-templates % 

Example variable values

A set of examples whereby a registered domain (example.com) wishes to, by default, only have certificates issued by DigiCert and would like to receive issuance violation notifications via security@example.com. Yet they have delegated authority to issue a certificate for a specific subdomain name (sub.example.com) to Let's Encrypt only.

Example 1, apex domain, non-critical issue property with additional parameters,

host: @
flags: 0
tag: issue
value: "digicert.com; cansignhttpexchanges=yes"

Example 2, apex domain, critical issuewild property with additional parameters,

host: @
flags: 128
tag: issuewild
value: "digicert.com; cansignhttpexchanges=yes"

Example 3, apex domain, non-critical iodef property with additional parameters,

host: @
flags: 0
tag: iodef
value: "mailto:security@example.com"

Example 4, sub domain, critical issue property,

host: sub
flags: 128
tag: issue
value: "letsencrypt.org"

Results from https://domainconnect.paulonet.eu/dc/free/templateedit

NOTE: If using https://domainconnect.paulonet.eu/dc/free/templateedit it doesn't currently support CAA records at present, so this was generated as TXT records as they have the same basic format. TXT was substituted to CAA afterwards.

{
  "providerId": "goodroots.work",
  "providerName": "Good Roots Work",
  "serviceId": "caa_management",
  "serviceName": "CAA Policy Management",
  "version": 1,
  "logoUrl": "https://goodroots.work/goodroots.svg",
  "description": "Provides tooling to manage error free RFC compliant best practice CAA policy records for a domain, subdomain or specific hostname.",
  "variableDescription": "%flags%: flags for the CAA record, typically 0, or 128 to indicate critical; %tag%: tag for the CAA record; %value%: value for the CAA record;",
  "syncBlock": false,
  "syncPubKeyDomain": "caa.goodroots.work",
  "multiInstance": false,
  "warnPhishing": false,
  "hostRequired": true,
  "records": [
    {
      "type": "CAA",
      "host": "@",
      "data": "%flags% %tag% \"%value%\"",
      "ttl": 300
    }
  ],
  "testData": {
    "Apex-issue": {
      "variables": {
        "domain": "example.com",
        "host": "@",
        "flags": "0",
        "tag": "issue",
        "value": "digicert.com; cansignhttpexchanges=yes"
      },
      "results": [
        {
          "type": "CAA",
          "name": "@",
          "ttl": 300,
          "data": "0 issue \"digicert.com; cansignhttpexchanges=yes\""
        }
      ]
    },
    "Apex-issuewild-Critical": {
      "variables": {
        "domain": "example.com",
        "host": "@",
        "flags": "128",
        "tag": "issuewild",
        "value": "digicert.com; cansignhttpexchanges=yes"
      },
      "results": [
        {
          "type": "CAA",
          "name": "@",
          "ttl": 300,
          "data": "128 issuewild \"digicert.com; cansignhttpexchanges=yes\""
        }
      ]
    },
    "Apex-iodef": {
      "variables": {
        "domain": "example.com",
        "host": "@",
        "flags": "0",
        "tag": "iodef",
        "value": "mailto:security@example.com"
      },
      "results": [
        {
          "type": "CAA",
          "name": "@",
          "ttl": 300,
          "data": "0 iodef \"mailto:security@example.com\""
        }
      ]
    },
    "Sub-issue": {
      "variables": {
        "domain": "example.com",
        "host": "sub",
        "flags": "0",
        "tag": "issue",
        "value": "letsencrypt.org"
      },
      "results": [
        {
          "type": "CAA",
          "name": "sub",
          "ttl": 300,
          "data": "0 issue \"letsencrypt.org\""
        }
      ]
    }
  }
}  

[github-actions]

Linter OK:

Linter result for goodroots.work.caa_management.json
{"level":"info","template":"goodroots.work.caa_management.json","groupid":"","record":0,"type":"CAA","code":"DCTL1016","dctl_note":"unexpeceted record type","time":1755691483}

[kerolasa]

nit: The false boolean values can be removed, the default is false.

[kerolasa]

Looks good to me, this can be merged with or without the boolean nit fixed.

[pawel-kow]

@colin-stubbs 1 important question. Do you intend to set several CAA records for the same domain/host combinations?
I think it's not untypical to have issue/issuewild together with iodef.

If yes, please read the section Apply, Re-apply, and Multi-Instance of the spec and take a look if multiInstance flag would be needed.
Other approach would be to define multiple CAA records in the template and steer via groups which ones would be applied. This approach has an advantage of all records set in one flow.

[colin-stubbs]

Yep, multi record definitely needed, it's not uncommon for a domain to want say... 2 issue records, 1 issuewild's, an iodef and possibly some custom tags as well.

Thank you I'll read up on that and update.

[colin-stubbs]

OK, updated... I get the feeling that we're going to have to pretty extensively test sync vs async and the feature variances between DNS Providers anyway, but multiInstance=true does appear to to be the best approach for now.

[pawel-kow]

@colin-stubbs ok.