Changelog v3.16.0

creds.json file format change

Feel free to skip to "How do I convert?" if you don't care about the details.

Starting in v3.16 the "provider type identifier" (PTI) will be located in creds.json instead of dnsconfig.js. The PTI is the all caps string like ROUTE53 or CLOUDFLAREAPI used to identify a provider's type.

V3.16 will enable a syntax that is backwards and forwards compatible. The old syntax will be removed in v4.0. There's no planned release date for v4.0 but it is expected to be after Dec 31, 2022.

The change was discussed in Request for Comments: Include the provider type in creds.json, remove it from dnsconfig.js where we decided "Plan A" would be selected.

What does this mean to you?

In a nutshell, NewRegistrar() and NewDnsProvider() will lose the 2nd parameter:

dnscontrol.js

var REG_GANDI = NewRegistrar(
-   "gandi",
-   "GANDI_V5"
+   "gandi"
);
var DSP_CF = NewDnsProvider(
-   "cloudflare_tal",
-   "CLOUDFLAREAPI"
+   "cloudflare_tal"
);

The second parameter (GANDI_V5 and CLOUDFLAREAPI in the above examples) has moved to creds.json instead. It will be in a TYPE field, which all providers have. It can appear in both places for backwards compatibility for now.

creds.json

{
  "gandi": {
+   "TYPE": "GANDI_V5",
    "apikey": "reacted"
  },
  "cloudflare_tal": {
+   "TYPE": "CLOUDFLAREAPI",
    "apikey": "reacted",
    "apiuser": "reacted"
  }
}

In the past, a provider didn't need an entry in creds.json if there were no credentials to be stored. Starting in v4.0 all providers must have an entry in creds.json. To aid the transition, starting in v3.16 warnings will appear on stdout that direct you to convert to the new format.

Also to help in the conversion, if no provider named "none" or "bind" exist, ones will be added for you. They look like this:

creds.json

{
  "none": { "TYPE": "NONE" },
  "bind": { "TYPE": "BIND" }
}

Command line tools

How does this affect command line tools?

The following subcommands require the PTI a parameter on the command line:

• get-zone

• get-zones

• check-creds

In 3.16, that parameter can be changed to - as a placeholder, or removed entirely if it is the last parameter on the command line. When you omit this parameter, DNSControl will find the value in creds.json instead.

In 4.0, that parameter will be removed, though a - is permitted for backwards compatibility.

In other words, if you add the TYPE field to creds.json, you no longer need to specify it on the command line. You can specify - instead, or leave it out entirely starting in v4.0.

For check-creds:

Starting in v3.16 these forms are valid:

dnscontrol check-creds myr53
dnscontrol check-creds myr53 -
dnscontrol check-creds myr53 ROUTE53

Starting in v4.0 this is the only valid form:

dnscontrol check-creds myr53

For backwards compatibility, these are valid until at least v5.0:

dnscontrol check-creds myr53 -

For get-zones/get-zone:

Starting in v3.16 these forms are valid:

dnscontrol get-zones gmain GANDI_V5 example.comn other.com
dnscontrol get-zones gmain - example.comn other.com
dnscontrol get-zones cfmain CLOUDFLAREAPI all
dnscontrol get-zones cfmain - all
dnscontrol get-zones --format=tsv bind BIND example.com
dnscontrol get-zones --format=tsv bind - example.com
dnscontrol get-zones --format=djs --out=draft.js glcoud GCLOUD example.com
dnscontrol get-zones --format=djs --out=draft.js glcoud - example.com

Starting in v4.0 these forms are valid:

dnscontrol get-zones gmain example.comn other.com
dnscontrol get-zones cfmain all
dnscontrol get-zones --format=tsv bind example.com
dnscontrol get-zones --format=djs --out=draft.js glcoud example.com

For backwards compatibility, these are valid until at least v5.0:

dnscontrol get-zones gmain - example.comn other.com
dnscontrol get-zones cfmain - all
dnscontrol get-zones --format=tsv bind - example.com
dnscontrol get-zones --format=djs --out=draft.js glcoud - example.com

How do I convert?

Step 1: Upgrade

Upgrade to v3.16 or later. If DNSControl is installed in many places, do not continue until they are all at v3.16 or later.

Step 2: Edit creds.json

Now that all uses of DNSControl are on v3.16 or later...

For each creds.json entry, add a field "TYPE" set to the provider type identifier. This is the all-caps name such as ROUTE53, GCLOUD, or CLOUDFLAREAPI.

For example, here is a new-style creds.json file with TYPE fields added:

creds.json

{
  "bind_inside": {
+   "TYPE": "BIND",
    "directory": "inzones"
  },
  "cloudflare_tal": {
+   "TYPE": "CLOUDFLAREAPI",
    "apikey": "redacted",
    "apiuser": "redacted"
  },
  "gandi": {
+   "TYPE": "GANDI_V5",
    "apikey": "redacted"
  }
}

Step 3: Cross-check

Run dnscontrol preview as one normally would. Fix any errors, warnings, or informational messages that appear on stdout.

Here are some examples:

If you see something like...

WARNING: For future compatibility, update the "namedotcom_main" entry in `creds.json` by adding: "TYPE": "NAMEDOTCOM", (See https://docs.dnscontrol.org/commands/creds-json#missing)

...it means that the TYPE field is missing from that entry in creds.json.

If you see something like...

ERROR: Mismatch found! creds.json entry "namedotcom_main" has "TYPE" set to "ROUTE53" but dnsconfig.js specifies New*("namedotcom_main", "NAMEDOTCOM") (See https://docs.dnscontrol.org/commands/creds-json#mismatch)

...it means your dnsconfig.js and creds.json specify mismatched values. Fix one or the other.

After you correct some warnings, you may receive information messages like...

INFO: In dnsconfig.js New*("namedotcom_main", "NAMEDOTCOM") can be simplified to New*("namedotcom_main") (See https://docs.dnscontrol.org/commands/creds-json#cleanup)

...which is a message that will disappear as you update dnsconfig.js in the next step.

Step 4: Edit dnsconfig.js

Remove the 2nd parameter to any NewDnsProvider() or NewRegistrar() functions.

dnsconfig.js

var REG_NAMEDOTCOM_TAL = NewRegistrar(
-   "namedotcom_tal",
-   "NAMEDOTCOM"
+   "namedotcom_tal"
);
var DNS_GANDI_TAL = NewDnsProvider(
-   "gandi_v5_tal",
-   "GANDI_V5"
+   "gandi_v5_tal"
);

Again, run dnscontrol preview to verify you setup still works as expected.

Step 5: Update any shell scripts

Any shell scripts or documentation that uses the subcommands get-zone, get-zones or check-creds should be updated. The "provider type" parameter should be changed to -. If it is the last parameter on the command, it can be removed.

It's unlikely you have scripts that use these commands. However you may have documentation that refers to them and needs to be updated.

Step 4: Test

Run dnscontrol preview as one normally would. Fix any errors, warnings, or informational messages that appear on stdout.

Step 5: Done

That's it!