DNS Standalone

[geek-at]

What provider would you like to see added to NPM? certbot standalone DNS

Have you checked if a certbot plugin exists? Certbot comes with dns standalone

This script for example will generate a cert for example.com and *.example.com and all you need to do is point port 53 to the server which hosts certbot/nginxproxymanager

#!/bin/bash

certbot --non-interactive --agree-tos --email webmaster@example.com certonly \
  --preferred-challenges dns --authenticator certbot-dns-standalone:dns-standalone \
  --certbot-dns-standalone:dns-standalone-address=0.0.0.0 \
  --certbot-dns-standalone:dns-standalone-ipv6-address=:: \
  --certbot-dns-standalone:dns-standalone-port=53 \
  -d example.com -d *.example.com

You only need a cname called _acme-challenge.example.com pointing to the A record of example.com to make it work

It should be (kinda?) trivial to integrate this into nginx proxy manager and allow users to forward port 53. The beauty of this is that port 53 is dead when certbot is not listening as standalone dns so no chance of being the target of a DNS amplification attack

[the1ts]

I personally like the idea since NPM may no longer have to hold the credentials for DNS changes. I do have a few thoughts on putting it into NginxProxyManager which calls itself a very simple solution for SSL.

1. Not sure that inbound UDP/TCP port 53 is open to a large enough portion of home users which I guess are a fair number of NPM users. Many users would be running docker on a system with perhaps port 53 already used. So should we pick another port or allow it to be picked on the UI? Allowing picking seems overly complex and more difficult to give simple instructions.
2. Does this different DNS authentication method allow wildcard SSL certs? If not does this mean we need to visit DNS every time we create a new hostname? If so then is it going to be automated by NPM removing the main benefit of no DNS credentials being held by NPM.

[geek-at]

Thanks for your thoughts @the1ts

1. Not sure about the US but in Europe I have personally never seen a consumer internet connection that didn't allow port forwards (including DNS). Also if a user wouldn't use the standalone DNS feature, they just don't need to forward the port in the container. Sure you can use port traversal in docker it wouldn't matter if the external request was NAT'ed correctly from the firewall I'm doing the same thing. My firewall has port 53 open and forwards it to my docker host on port 5353 which then could forward it to nginxproxymanager port 53 again

2. Yes the example above is a working example for a wildcard cert. I've copy-pasted this code from the script I use to generate my wildcard certs. Setup is very easy as you just need one additional DNS record pointing to your server: _acme-challenge.example.com. Bonus as you stated is that you don't need to store dns credentials or api keys on your server

[the1ts]

Good to hear that wildcard certs are supported.

Perhaps I wasn't clear on point 1, I'm not talking about port forwarding from a consumer grade router, the problem is some consumer ISPs block some unsolicited incoming packets to some ports to stop uncontrolled servers and some virus activity on their networks. This started with blocking Windows file sharing ports and some ISPs do others ports including DNS on port 53 which are thought to be only used for bad purposes or left open by end users in error. So the inbound port for this temp DNS server needs to take that into account. There isn't a list of blocked ports per ISP (never seen it advertised, just discovered) so we have to default to a good working config that takes into account this known, but opaque blocking.

Again not saying it isn't a good method, I just want to limit the number of unnecessary problems due to config appearing here in the issue tracker. Indeed with its one off DNS change and lack of credentials inside NPM its a preferred solution for security, it may also mean the number of certbot dns plugins needed to be added is reduced as its a built in DNS based solution.

[geek-at]

Yes I can see your concerns as half of the open tickets are with specific DNS providers. But since certbot already supports DNS standalone out of the box I think it will have less issues as other (third party plugin) DNS providers. Would you agree?

[github-actions[bot]]

Issue is now considered stale. If you want to keep it open, please comment :+1: