Close! The full syntax for using the DNS challenge (which disables HTTP and TLS-SNI challenges for that site) is this:
tls {
dns cloudflare
}
Credentials must be provided as env variables. (I’m trying to move sensitive info out of the Caddyfile.)
Great question. It’ll be an import statement so all plugins are plugged in like the others. Not sure of the details yet. Hmmm.
I’ve been with Linode since dirt was discovered, seemingly. I did not take any time or energy to glean whether the Linode API would work for the DNS interactions required here.
I need to perhaps take a look at some of the other providers already listed, in case Linode is only a “thing” for the getOffMyLawn generation.
The only issue I see with env vars for credentials is if I have domains on separate cloud flare accounts or something that I want to serve from a shared caddy instancet
@captncraig Here’s what I’m thinking for the implementation of a DNS provider for Caddy:
func init() {
caddytls.RegisterDNSProvider("digitalocean", NewDNSProvider)
}
func NewDNSProvider(credentials ...string) (acme.ChallengeProvider, error) {
switch len(credentials) {
case 0:
return digitalocean.NewDNSProvider()
case 1:
return digitalocean.NewDNSProviderCredentials(credentials[0])
default:
return nil, errors.New("invalid number of credentials")
}
}
And the caddytls package just keeps a map of the registered providers. This allows it to scale up to any number of providers, given their own packages. Each provider is just a plugin like any other plugin.
The credentials ...string argument is only a little bit hacky. Each DNS provider type has different ways of authenticating; some accept 1 argument like an API key, some accept 2 like an ID/secret, and others accept more. But so far, every type of credential is a string. And I bet most other types of credentials could be converted from a string if absolutely necessary. So I think this will work for the vast majority of providers.
I know it would be nice to have them just “work” but I am not sure we can do that without changing the actual provider packages to integrate with Caddy. So this “adapter” package will have to do. We can host them at a repo like caddyserver/dnsproviders.
that would probably work. It feels odd to have to build in a plugin to make it work, but it is a rather advanced feature.
Okay. Will ship Caddy without any DNS providers by default; users can plug them in easily enough, though.
Just completed my first DNS challenges with Caddy 0.9 WIP. 
Sure is slick – assuming your DNS provider is really quick, it doesn’t require opening a socket so you can use this challenge almost everywhere, even behind hardware load balancers.
would love for DNSMadeEasy and it’s younger sibling Constellix DNS be added About | Constellix 
as late as this is, dnsmadeeasy gets my vote as well. still not on the list as far as i can tell.
@dhylton Contributing a DNSMadeEasy provider plugin should be easy enough. Here are the instructions: https://github.com/mholt/caddy/wiki/Writing-a-Plugin:-DNS-Provider
just following the links provided, i see that dnsmadeeasy was merged into lego trunk in 2016.
Yep, now it just needs a Caddy plugin.
I’d get your list from DNSPerf.com. Specifically, I’d pull up the best 12 or so DNS providers in the world, and separately, the top 12 in North America. Any DNS provider that made either of those lists would be in my list for inclusion in Caddy.
(DNSPerf.com reports and ranks DNS provider performance, and offers a dropdown filter that defaults to World, and includes North America, Oceania, Europe, etc.)
That said, I don’t see any config info in your code snippet, just the names of DNS providers, so I probably don’t fully understand what’s involved here. In any case, choosing the best DNS providers seems like the way to go (the best will roughly correspond to the most widely used, though imperfectly.)