Easy Wildcard: One command to rule them all


#1

Hi all,

Would love some input on this project before I put it up on Docker HUB. The idea is that it’s an extension of certbot that includes bind, and allows you to use a server, even one on a dynamic IP, as a way to validate DNS challenges without altering your root DNS by using a CNAME to the dynamic host.

It’s intended to be that “one command” that novice users can run.

I’ll make the docs way more friendly later, but the README is pretty straight forward for most here in this community:

edit Reflect the removal of fork from certbot for the cleaner HUB from use.


Wildcard Domain Step-By-Step
#2

Hi @fmstrat,

Thanks for working on this project!

Is there any chance that you might get this to work with acme-dns instead of BIND?

(It’s meant to be more secure by implementing much less of the DNS protocol—and in Go.)


#3

So I had considered acme-dns first, but it actually added complication for what I was trying to do. Perhaps I’m missing something. For instance, integrating bind was easy, because I just add bind to the Dockerfile, and then the hook just needs to create a named.conf, a zonefile, and fire up bind. No API calls, etc. If I integrated acme-dns, it would require configuration at start, then API calls, etc. To me, they’re two different use cases:

  • Acme-dns: If you want a server out there always running in the world to act as a central resource for ACME challenges for multiple domains and potentially multiple users, likely better for scaled networks.
  • EasyWildcard: If your joe-shmoe who doesn’t know much about Let’s Encrypt, and doesn’t want a separate DNS server running

edit
Hit Reply too soon. So given the above, am I missing something or would it be better to incorporate acme-dns for another reason?


#4

That might be right—it’s a very plausible argument. I would still be more comfortable with a more minimalist DNS server written in a safer language, but that might be more of a challenge to pull off here.


#5

Thanks for the input! I’m not sure of the security risk here? Bind is open source, and an extremely popular DNS solution, potentially the most widely used on the internet.


#6

Most people don’t currently run a nameserver on their web server, so you’re running a different kind of service that didn’t already exist—albeit super-ephemerally.


#7

It’s also fixed a million security vulnerabilities… Running the latest version is fine but running some out-of-date BIND is not the safest idea.


#8

Well, not sure if I’m quoting correctly (link? blockquote with no inclusion? Odd UI), but let’s see how this goes

Totally agree. They’ve fixed a ton of security vulnerabilities, but as they’re so widely used that’s not really surprising. I consider this good since security experts have focus on it. I’m running BIND9, latest package out of alpine, and I rebuild my containers on the HUB monthly to ensure they’re always running new packages.

True, but it’s a docker container, so there’s no real impact to alternate services. And you could always run it on a separate machine if desired, same way you would acme-dns. The acme-dns model is WAY more flexible, but I’m thinking bind works well in this application.


#9

Cool, I look forward to hearing how your users like it. If you do come across some more minimalist DNS server implementation, you could also consider swapping it in.


#10

I’ve been migrating our wildcards setup to acme-dns and one of the design specs I decided on was to wrap the validation within a toggle of the firewall rules. 53 is off by default, enabled for the validation, then immediately shut off.

This looks to be essentially doing that - but it’s running in a docker container, as what looks to be an unprivileged user. that should be as-safe, if not safer. (though toggling 53 would still be a good idea here too, IMHO)

I don’t understand why this is a fork though. why not have this pull the latest (or a “–repo=”) version of certbot in the build as an external project, and work off that? It would essentially be up-to-date until it breaks (at which point, someone specifies a version tag into the repo=)


#11

Ahh, this is how you quote.

So, for the firewall rule: I’m not sure of the benefit of toggling the firewall rule in this use case. When the container is running, something is listening on the port, when it’s not, nothing is. So basically bind is listening for a few seconds once every two months, the rest of the time, nothing is. Would toggling a firewall rule impact this? If so, I could add something that allows uses to run an external script to do something like that.

Is there a benefit to that? I basically run a script of something like (this is purely example, cut/paste from another projects monthly build that I created):

cd /tmp
ssh-agent bash -c 'ssh-add /data/system/keys/github; git clone git@github.com:Fmstrat/easywildcard.git'
cd easywildcard
git checkout master
git pull --no-edit https://github.com/certbot/certbot.git master
ERROR=0
if [ $? -eq 0 ]; then
	ssh-agent bash -c 'ssh-add /data/system/keys/github; git push origin master'
	curl -s -H "Content-Type: application/json" --data '{"build": true}' -X POST https://registry.hub.docker.com/u/<EVENTUALBUILDHOOKURL> > /dev/null
else
	ERROR=1
fi
if [ $ERROR -eq 1 ]; then
	/data/system/bin/send-email "EASYWILDCARD build fail" "Errors in merge.\n\n"
fi

Based on my code layout there should really never be a conflict for a merge unless there are some serious changes to certbot. I’ve never done things the way you describe, but if it’s a better methodology, I’m open to it.

I will keep my eye out!


#12

It’s largely just ‘good practice’ and keeping users from hurting themselves. Not having a service listening is essentially the same as a DROP (or REJECT - I forget).

The problem isn’t merging, it’s versioning and maintenance. If there’s a critical update to certbot or ACME, users are dependent on this repo to be updated. You’re the bottleneck, so if you’re not responsive, go on vacation, move on to other projects, etc - users are stuck. There was an immediate TLS-SNI-01 deprecation a while back, so sudden changes are possible (though unlikely).

Correct me if I’m wrong, but from the commits it looks like your build doesn’t really do anything to certbot itself. You have some scripts that work as hooks, and then just augment the certbot docker container. It seems to me like your repo could just be a docker container that has your hooks, and sets up bind + the certbot master repo.


#13

Good point. I will add in a feature to allow an external script to execute before/after starting DNS that users can use to open/close ports/etc. That work?

I had not thought of this. I decided to fork so that if Certbot ever updated their requirements (Dockerfile) they would get pulled in automatically, vs things breaking. I’d like to keep this small and contained in alpine, but unfortunately:


There doesn’t look like a package will exist for it, and with certbot-auto being deprecated, that probably isn’t the best route, either.

I’m wondering if keeping the fork, with a daily merge script, and then linking the eventual Docker HUB repository to the official Certbot and Alpine repositories would work. This way when one of them rebuilds, so will mine.


#14

Perhaps this is what you’re getting at, but bmw had a good suggestion when I reached out to him: https://github.com/Fmstrat/easywildcard/issues/1

I’m going to repackage the Dockerfile as a “FROM” certbot. Simplifies things drastically.


#15

yeah, from my experience with docker (which is limited) i think that’s basically it. that gives you the cerbot, builds in bind, and then you just have your easywildcard scripts as a plugin or manual hooks. you shouldn’t need to update/change anything until certbot’s integration breaks.


#16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.