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)
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??)
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.
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.
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!
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)?
That 20MB is a 100% increase in the size of the software. In nano-environments that have a low network throughput such as AWS t2.nano that feature would increase software download time by almost 30%.
In my opinion It should stay as an addon, but if it gets added I’m sure some hero will step up to gut it and release a leaner flavor of Caddy.
I’m intrigued – can you elaborate on this? (My Internet connection at home is regularly about 512 Kbps - 1 Mbps, so I know the pain of slow networks.) Caddy is usually only downloaded once, and in the course of provisioning a cloud instance, I feel like downloading software is an insignificant amount of time.
For what it’s worth, we have no plans to do away with provider plugins in the near future.
That’s the wonder of open source! Wouldn’t be the first time someone’s reflavoured Caddy to their liking somehow.
So basically double the size means a non-insignificant amount of extra network transfer time in your case. If you’re doing a lot of downloading of Caddy binaries, yeah, I guess that could add up a lot in massive aggregate… Like, once upon a time, Google used to shave bytes off their homepage by not including certain HTML tags when they could get away with it and it wouldn’t break the page. (I don’t think they take those kind of measures anymore, though.)
A server that is networked through a NAT network. (usually it uses non-80 ports)
Administrators need to register or renew SSL certificates through DNS challenges. Usually use third-party software or scripts. The more software and scripts you use, the greater the probability of problems.
When I visit other people’s websites occasionally, I see that the digital certificate has expired. This situation is decreasing, but it is still happening.
Voting can express the situation of most people.
I hope that the maintenance team can understand the situation of a few people.
I respect the decision of the maintenance team.
Thank you.
