OPNsense Forum
English Forums => Development and Code Review => Topic started by: Stilez on March 01, 2019, 12:05:56 pm
-
I'm writing a short add-on for the ACME DNS-01 challenge.
The idea is that if you're using DNS alias/redirect, and a tiny "set and forget" type of domain (like one used just for your family website/email), and your provider doesn't provide an API for DNS record updates (web UI/email only), you could have an ACME challenge setup something like this, and not need to run BIND or anything else, if you're running unbound already as the main resolver.
Since many people could fall into that scenario, it seems a neat DNS-01 module to have, and its relevant to me as I'm squarely in that situation.
It also feels a neat solution from a security perspective, as it doesn't need any key or password, nor any software beyond unbound, since it's all based on local unbound.conf data that's secured by usual Unix permissions, and it doesn't risk exposing anything beyond the few text records, and then only for a few seconds (max 3-5 minutes) once every 2-3 months when DNS-01 is active. Note also, no external DNS provider API is involved or needs to propagate data, so the total start-to-end time for live data to be in the file should be the time taken for Let's Encrypt's queue to perform lookup after being notified of a DNS update, plus a fraction of a second. The workflow is:
Done manually by the user:
- Create the couple of DNS records with their provider, to redirect _acme_challenge.domain.name to the IP that unbound will listen on, during the DNS-01 challenge.
In the ACME plugin:
- add a directive in unbound.conf, to include "/var/unbound/unbound-dns-01.conf"
- add a suitable one-line system startup script so this exists and is empty at unbound config load
(these are probably too system specific to be in acme.sh itself and need to be in the acme plugin code or done manually. But they are trivial.)
In a new ACME DNS-01 challenge dnsapi shell module "dns_unbound_direct_access.sh" (both add and remove parts):- If Unbound isn't running, error + return (maybe an option to autostart/autostop if this isn't a problem for edge cases)
- before doing anything else, and regardless whether the call was to add or remove TXT records, set a cron job to empty the file of any records for that domain and autostop unbound if autostarted, in some amount of seconds (say 300 seconds). This is a failsafe to ensure the file is emptied and generally serves+contains nothing unless a DNS-01 query is actively in progress, which is only once every 60 - 90 days, even if something fails or exits prematurely within acme plugin or elsewhere, at any point.
- Create /var/unbound/unbound-dns-01.conf which exposes a new custom view. The view is set to "deny_non_local" + "view-first:no" (ie refuses/denies anything except local-data explicitly defined within that view in unbound.conf and subfiles), and also rejects non_WAN IPs. The contents of the file are, obviously, the local-data: DOMAIN TXT 'DATA' records that Unbound should serve for DNS-01, or empty for that domain when no longer needed
- direct Unbound to reload its config (better than restarting service)
- verify that new config was loaded by unbound and exit success
I've got almost all of this prototyped, and working, with one exception, which is the dumbest thing - I can't seem to work out reliably, the best/correct way to reload unbound.conf.
From examining the codebase I've found it uses the old legacy system (.inc files) and I've played with the following commands seen in its scripts, which seem to be relevant:
- ...
elif [ "${COMMAND}" = "load" -a -f "${CACHE}" ]; then
cat ${CACHE} | ${UNBOUNDCTL} load_cache
...
- /usr/sbin/chroot -u unbound -g unbound /
/usr/local/sbin/unbound-control -c "$unbound_main_conf_file" "$1" 2>&1
(gets permission denied for port)
- /usr/sbin/chroot -u root -g wheel /
/usr/local/sbin/unbound-control -c "$unbound_main_conf_file" "$1" 2>&1
(no obvious permissions issue but seems to hang up a lot of the time)
I think the problem is that with unbound-control running in chroot, and potentially being called both from console (for testing) and also from a script run by ACME-plugin (presumably running as privileged user of some kind?), that there are nuances of the command, or the user/group, which I'm not getting right. Help appreciated, and once it's working here, code review time? :)
-
This should work:
# configctl plugins configure dns placeholder
"placeholder" is needed on master but shouldn't be needed in 19.1.x I think....
Cheers,
Franco
-
I'll need to pass that from the plugin to the .sh file, or look for it in env , it's too specific for the main dnsapi. (More a note to myself not to forget and hard code it!)