Poll: We can end DNS provider plugins. Should we?


(Matt Holt) #1

Years ago when the DNS challenge was originally implemented in Caddy, compatibility with each DNS provider had to be a plugin, but that’s no longer the case.

We have the option of making all of lego’s ~50 DNS providers just work for all Caddy instances without needing special builds of Caddy.

However.

Doing this will approximately double Caddy’s binary size from ~19 MB to ~40 MB.

Advantages of eliminating DNS provider plugins

  • No need for custom builds just to support the DNS challenge
  • Less maintenance required
  • More immediate support for Lego’s DNS providers without needing to keep our own repo in sync (this is a bit of a burden, tbh, since I also have to deploy them on the caddyserver.com site and for every new provider, it becomes more tedious…)

Disadvantages

  • Much larger binary size (about 2x current size without plugins)

So…

Worth it? (i.e. “Eliminate DNS provider plugins?”)

  • Yes (no more DNS provider plugins! large binary size OK)
  • No (keep binaries as small as possible)

0 voters

If you feel strongly, please discuss!


(Matt Holt) pinned globally #2

(Matt Holt) made this a banner . It will appear at the top of every page until it is dismissed by the user. #3

(Matt Holt) removed this banner . It will no longer appear at the top of every page. #4

(Peter Passchier) #5

Voted No because I don’t use any, and a smaller binary is nicer, but I totally understand if you want to integrate this and cut down on work and infrastructure. But once you go that route, I guess there is no way back, and it will become very difficult for anyone to ever get a smaller binary size (unless Go supports something like compiletime-conditionals??)


(Carl George) #6

Seems like the polling is in favor of this (76% yes as I write this). What’s the timeline for a decision on this?


(Matt Holt) #7

I don’t currently have one, sorry. Been focused on a few other coming improvements. :slight_smile:


(Avinash H Duduskar) #8

I’m on the fence about this, although I am part of the 72% that don’t want DNS provider plugins. OTOH, the sheer doubling of the binary size can’t be good. Ideally, the ability to download and use whatever DNS provider is required post-install would be a good middle ground IMHO.


(Emmaly Wilson) #9

I would say that it’s not worth bloating the binary, but it really could save new users a lot of time. And it probably would encourage more users to use DNS challenge for internally served items instead of unnecessarily exposing their app to the Internet, which I’ve seen happen in a few places. I know at least one place where someone bought a cert from someone specifically so they didn’t have to deal with it, which didn’t even make sense to me.

But if people are licensing Caddy right, they’re either paying the fee for the precompiled version from the project site (or they’re actually doing personal use), or they’re self-building. And if they’re self-building, maybe all they need is better instruction?

For us, we already build our own in house that includes the DNS providers we need, so we don’t need any change here. But we also don’t care about 20MB in the grand scheme of things, so we’re good either way you go. In the end, I would recommend you do what makes it easier (and makes life happier) for the maintainer of the project.


(Matt Holt) #10

Both good feedback. Thanks both, @Strykar and @emmaly - I guess it comes down to just needing to make a decision.

I’m going to hold out for now because of the time investment needed to do it, and I have a lot pressing at the moment, but I will keep considering this for the future!


(Lewis De Payne) #11

I’m somewhat pragmatic when evaluating technical choices, probably as a result of my prior Silicon Valley experience. On the plus side, Caddy’s resident set size (RSS) is laughable… even if you double its size (even on a RAM-starved server). That leaves me with one final analysis - the perceived trade-off between bloat and simplicity.

Here are some simple facts (as I see them):

  • The simplicity of configuration (in most use-cases) is Caddy’s marketing point.
  • In particular, Caddy positions itself as an automatic solution to domain certificates.
  • Caddy wishes to make inroads into commercial use, where paying customers are.
  • Many larger commercial customers put stuff behind a proxy, load balancer, or scrubber.

In order to achieve its marketing (and growth) objectives, Caddy must support alternative means of automating the certificate issue, especially for customers with front-end appliances that interfere with the built-in method. Caddy has effectively done so, with the optional DNS add-ons. However, having to put together a custom-build of caddy is anathema to simplicity… but the mitigating factor here is that the large commercial customers requiring an optional DNS plug-in typically have a staffed IT department capable of dealing with such basic issues (especially given how simple it is to build a custom download via your website… thanks to golang being a self-contained executable!). Thus, it seems that stuffing all these modules into Caddy is, in reality, somewhat superfluous and not advantageous.

As an example, those who don’t know how to set an environment variable, or perhaps how to log into a shell account on their server, are likely not the audience Caddy wants to focus on. In the end, it’s a business choice… and that choice determines what audience you end up supporting going forward. Do you spend your time supporting “how do I get your download onto my server?” and “what’s sftp?” or do you instead focus on “how do I proxy this into a FreeBSD jail using ipfw?” (i.e., Netflix, TrueNAS, and similar customers)?