Make provider usage easier

[TomOnTime]

Currently dnsconfig.js looks like this:

var REG_GANDI = NewRegistrar("gandi_main");
var DSP_GANDI = NewDnsProvider("gandi_main");

D("example.com", REG_GANDI, DnsProvider(DSP_GANDI),
    A("@", "192.0.2.1")
);

Problems:

• Users find it confusing to define the same provider twice
• ....and then use it a 3rd time with DnsProvider()
• The name DnsProvider() is confusingly similar to NewDnsProvider
• The 2nd parameter to NewRegistrar/NewDnsProvider isn't needed. That info is in creds.json now.
• The "New" in NewRegistrar/NewDnsProvider is odd. It makes sense from a CS perspective but not typical users.

Wouldn't it be easier if dnsconfig.js looked like this?

var SVC_GANDI_MAIN = PROVIDER("gandi_main");  // `gandi_main` is the entry in creds.json

D("example.com",
    REGISTRAR(SVC_GANDI_MAIN),
    DNS_SERVICE(SVC_GANDI_MAIN),
    A("@", "192.0.2.1")
);

I think it would.

However the names SVC_GANDI_MAIN and DNS_SERVICE aren't my fav. However I can't think of better ones.

Do you like this? What names would you suggest?

CC @cafferata @chicks-net @labrown @eliheady @fm for visibility

[TomOnTime]

PR #4955

[x70b1]

That looks easier.

I would also remove DNS_ from DNS_SERVICE. Because the word DNS is somehow used everywhere in a tool like dnscontrol.
But I would also call it SERVERS, not SERVICE.

SERVERS would be more technical. But maybe thats just my opinion because thats my dnscontrol use case.

[TomOnTime]

That looks easier.

I would also remove DNS_ from DNS_SERVICE. Because the word DNS is somehow used everywhere in a tool like dnscontrol. But I would also call it SERVERS, not SERVICE.

SERVERS would be more technical. But maybe thats just my opinion because thats my dnscontrol use case.

Interesting. I do like removing the "DNS_". SERVER() might be confused with NAMESERVER()

[chicks-net]

Why do we need the wrappers REGISTRAR() and DNS_SERVICE()? What's wrong with something like:

var SVC_GANDI_MAIN = PROVIDER("gandi_main");  // `gandi_main` is the entry in creds.json

D("example.com",
    SVC_GANDI_MAIN,
    SVC_GANDI_MAIN,
    A("@", "192.0.2.1")
);

I get that you were trying to do a named-paramater sort of thing, but if you're not happy with the names for these, what's wrong with treating them as positional parameters instead?

[TomOnTime]

You can 0 or more DNS servers (only one registrar). The current D() is positional: D(zoneNamew, reg, ...)

[TomOnTime]

Thinking out loud.

Ideally we'd remove the "PROVIDER(name)" call, and just have

D("example.com",
    REGISTRAR("gandi_main"),
    DNS_SERVICE("gandi_main"),
    A("@", "192.0.2.1")
);

The problem with that is the PROVIDER function allows options. For example:

foo = PROVIDER("bind", { default_ns: [ "foo", "bar" ]};

That metadata would be lost. Well, I guess we could require people to repeat it in each instance. That seems like a PITA.

Alternatively, we could (breaking change alert!) move that metadata to the creds.json file.

Actually, I think making people repeat the metadata wouldn't be so bad.

[TomOnTime]

Thinking out loud.

Ideally we'd remove the "PROVIDER(name)" call, and just have

D("example.com",
    REGISTRAR("gandi_main"),
    DNS_SERVICE("gandi_main"),
    A("@", "192.0.2.1")
);

The problem with that is the PROVIDER function allows options. For example:

foo = PROVIDER("bind", { default_ns: [ "foo", "bar" ]};

Or...

The number of providers that accept metadata when they are defined is pretty small.

How about...

D("example.com",
    REGISTRAR("gandi_main"),
    DNS_SERVICE("gandi_main".WithConfig( { field: value ; field: value } ),
    A("@", "192.0.2.1")
);

or just have a way to add the metadata:

ConfigureProvider("gandi_main", { field: value ; field: value } );

In this case, we should pass the variables with names like credsMetadata and dnsconfigMetadata so that its obvious where it came from.

[x70b1]

Coud work, but booth configs are very hard to read. Looks way to complicated.
If you compare this to your ADD_OPTION idea, that looks a lot cleaner.

[x70b1]

As long as you can choose between the two ways you can decide if you want to repeat that that or not. The question is if you want to support booth ways in the future.

I dont want to open a new discussion here, but for me we have already to much in the creds.json. I see the point that we want to get credentials to dnscontrol. But why is the provider config also in the creds.json?

Do we need a single place for provider configuration?

[TomOnTime]

Good point.

Background: Originally dnscontrol only generated zonefiles for BIND. When we added Cloudflare, we added creds.json as a place to put the secrets so they weren't in Git. That was many years ago.

Do we need a single place for provider configuration?

Ideally secrets should be in one place and everything else should be in dnsconfig.js

[TomOnTime]

Random thought:

What if creds.json was just for credentials/secrets (things that shouldn't be in Git) and dnsconfig.js had a way of adding other info to the provider:

ADD_OPTION("gandi_main", "key", "value");
ADD_OPTION("gandi_main", "key2", "value2");
ADD_OPTION("gandi_main", "key3", "value3");

D("example.com",
    REGISTRAR("gandi_main"),
    DNS_SERVICE("gandi_main"),
    A("@", "192.0.2.1")
);

[x70b1]

Much better, the config goes to dnsconfig.js and the credentials are still in creds.json.
Would be awesome!

Not sure if the box is to large that I want to open here. What about objects for REGISTRAR and SERVICE.

R("gandi_main",
   OPTION("TYPE", "gandi"),
   OPTION("USERNAME", "jeff")
);

S("dnsservice",
   OPTION("TYPE", "dnsservice"),
   OPTION("API", "https://api.dnsservice.org")
);

D("example.com",
    REGISTRAR("gandi_main"),
    SERVICE("dnsservice"),
    A("@", "192.0.2.1")
);

// creds.json

{
  "gandi_main": {
    "password": "abc123"
  },
  "dnsservice": {
    "token": "xyz987"
  }
}

This could be even backward compatible. You can decide if you want to define the OPTION in your object or in your creds.json. They are just mapped together somehow.

But I dont like reusing the OPTION in the objects.

[timkgh]

Trying the new syntax, but REGISTRAR('none') does not seem to work, I get an error registrar named none expected for example.com, but never registered. I even tried adding "none": {"TYPE": "NONE"} to creds.json which I didn't have before with the old syntax and I still get the same error. Is this a bug or my error somewhere?

[timkgh]

Ah I see, still need PROVIDER for now, as in REGISTRAR(PROVIDER('none')), I got a bit ahead seeing REGISTRAR("gandi_main") in the examples above.
It would be a nice shortcut to simply provide a REGISTRAR_NONE and maybe PROVIDER_NONE out of the box though.

[timkgh]

+1 to the idea of having only credentials in creds.json, all config/options belong in dnsconfig.js

[TomOnTime]

Trying a different format

The release coming out today supports this syntax. (The original NewDnsProvider/NewRegistrar commands still work, of course!).

OLD:

var DSP_GANDI = NewDnsProvider("gandi_main", {setting: "value"});
var REG_GANDI = NewRegistrar("gandi_main");

D("example.com",
    REG_GANDI,
    DnsProvider(DSP_GANDI),
    A("@", "192.0.2.1")
);

NEW:

D("example.com",
    REGISTRAR("gandi_main"),
    SERVICE("gandi_main", ALL_NS, {setting: "value"}),
    A("@", "192.0.2.1")
);

The win here is that you don't have to declare variables. Also notice that the optional metadata on NewDnsProvider() has moved to SERVICE().

But I like variables!

What if you really love using variables? Well, sure, you can still do that.

Here's how we use a variable so we don't have to repeat the metadata:

MY_METADATA = { setting: "value" };

D("example.com", REGISTRAR("none"),
    SERVICE("gandi_main", ALL_NS, MY_METADATA),
    ...
);
D("example.net", REGISTRAR("none"),
    SERVICE("gandi_main", ALL_NS, MY_METADATA),
    ...
);

You can even store the output of SERVICE() and re-use it:

var MY_SERVICE = SERVICE("gandi_main", ALL_NS, {setting: "value"});

D("example.com", REGISTRAR("gandi_main"),
    MY_SERVICE,
    ...
);
D("example.net", REGISTRAR("none"),
    MY_SERVICE,
    ...
);

The result of REGISTRAR() can be stored and re-used the same way.

Thoughts?

[labrown]

I like it!  It's compact and yet has the expressive power to do most whatever customization is needed.

…

--[Lance] Tom Limoncelli wrote on 10/9/2026 10:26 AM:

The release coming out today supports this syntax. (The original NewDnsProvider/NewRegistrar commands still work, of course!). OLD: var DSP_GANDI = NewDnsProvider("gandi_main", {setting:"value"}); var REG_GANDI = NewRegistrar("gandi_main"); D("example.com", REG_GANDI, DnsProvider(DSP_GANDI), A("@", "192.0.2.1") ); NEW: D("example.com", REGISTRAR("gandi_main"), SERVICE("gandi_main", ALL_NS, {setting:"value"}), A("@", "192.0.2.1") ); The win here is that you don't have to declare variables. Also notice that the optional metadata on NewDnsProvider() has moved to SERVICE(). But I like variables! What if you really love using variables? Well, sure, you can still do that. Here's how we use a variable so we don't have to repeat the metadata: MY_METADATA = { setting:"value" }; D("example.com", REGISTRAR("none"), SERVICE("gandi_main", ALL_NS, MY_METADATA), ... ); D("example.net", REGISTRAR("none"), SERVICE("gandi_main", ALL_NS, MY_METADATA), ... ); You can even store the output of SERVICE() and re-use it: var MY_SERVICE = SERVICE("gandi_main", ALL_NS, {setting:"value"}); D("example.com", REGISTRAR("gandi_main"), MY_SERVICE, ... ); D("example.net", REGISTRAR("none"), MY_SERVICE, ... ); The result of REGISTRAR() can be stored and re-used the same way. Thoughts? — Reply to this email directly, view it on GitHub <#4949?email_source=notifications&email_token=AAASQLDO23U67CLRBDZZI6L5TDYS5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBYGM3TCMZRUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-18837131>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAASQLEXLXCGTPWZKWEAB7T5TDYS5AVCNFSNUABHKJSXA33TNF2G64TZHM3DMOJWGM3TCNR3IRUXGY3VONZWS33OHMYTAOJQG43DQM5BOYBA>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAASQLCH7D7AP4IIUFENBLL5TDYS5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBYGM3TCMZRUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/AAASQLGYUTAOFALY3S5PSAD5TDYS5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBYGM3TCMZRUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[x70b1]

@TomOnTime Thanks for this! Works great.

Now it would be awesome to remove configs from the creds.json.