starred/nginx-proxy-manager-NginxProxyManager

Fork 0

mirror of https://github.com/NginxProxyManager/nginx-proxy-manager.git synced 2026-04-25 17:35:52 +03:00

[GH-ISSUE #2252] DNS Standalone #1604

New issue

Closed

opened 2026-02-26 07:31:44 +03:00 by kerem · 6 comments

kerem commented

2026-02-26 07:31:44 +03:00

Owner

Originally created by @geek-at on GitHub (Sep 5, 2022).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/2252

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

Originally created by @geek-at on GitHub (Sep 5, 2022). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/2252 **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 ```bash #!/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

kerem

2026-02-26 07:31:44 +03:00

closed this issue
added the
stale

dns provider request
labels

kerem commented

2026-02-26 07:31:45 +03:00

Author

Owner

@the1ts commented on GitHub (Sep 6, 2022):

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.

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.
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.

@the1ts commented on GitHub (Sep 6, 2022): 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. 3. 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.

kerem commented

2026-02-26 07:31:45 +03:00

Author

Owner

@geek-at commented on GitHub (Sep 7, 2022):

Thanks for your thoughts @the1ts

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
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

@geek-at commented on GitHub (Sep 7, 2022): 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

kerem commented

2026-02-26 07:31:45 +03:00

Author

Owner

@the1ts commented on GitHub (Sep 8, 2022):

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.

@the1ts commented on GitHub (Sep 8, 2022): 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.

kerem commented

2026-02-26 07:31:45 +03:00

Author

Owner

@geek-at commented on GitHub (Sep 10, 2022):

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?

@geek-at commented on GitHub (Sep 10, 2022): 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?

kerem commented

2026-02-26 07:31:45 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Feb 10, 2024):

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

@github-actions[bot] commented on GitHub (Feb 10, 2024): Issue is now considered stale. If you want to keep it open, please comment :+1:

kerem commented

2026-02-26 07:31:45 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Mar 26, 2025):

Issue was closed due to inactivity.

@github-actions[bot] commented on GitHub (Mar 26, 2025): Issue was closed due to inactivity.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/nginx-proxy-manager-NginxProxyManager#1604

No description provided.

Rows
Columns