[FEAT] Multiple DNS validation in the same container

[SirLouen]

Is this a new feature request?

• I have searched the existing issues

Wanted change

Currently, only one DNS validation can be set up per Swag container

Ideally multiple DNS of multiple providers but minimally both HTTP and DNS validation of one provider at the same time.

Reason for change

In the case we would like to use different DNS validation on the same server, there will be issues running multiple Swag containers at once with conflicting ports, unless I get multiple IP for the server

The thing here is that, say for example, we are using multiple CDN providers for different domains running under the umbrella of Swag. For example, Cloudflare and Bunny
. Some of these only let you use their CDN if you use their DNS.

Moreover, let's say we have a domain using cloudflare and a subdomain of another domain in the same server. We cannot use DNS validation for the CF one and HTTP for the subdomain

I'm being inspired by the Caddy system where I have some caddy servers with this kind of configs (but I've always prefered to stick to nginx)

Proposed code change

No response

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[mauro2306]

Hi everyone, using SWAG since a while already, i wanted to promote this feature as well from my side as we sometimes have customers hosting their domains in different companies and if you want to rely on dns validation rather than HTTP, that's the only way to do it through multiple validation method.

[j0nnymoe]

Just to start with, this tool isn't aimed at businesses. We love that our containers can be useful within businesses environments but primarily it's aimed for homelab environments.

With the question of multiple DNS validations, this is similar to other things we've been requested before (another example is separate SSL certs per domain rather than sharing the same one).

We're not able to come up with a way that it can be automated in a way that it's reliable / easy to use for the end user. Plus if this was something that was added, it increases support bandwidth and development complexity.

[mauro2306]

Understood and accepted, for sure for small businesses, it is rather the same "load" as homelab environments, especially for businesses that aren't mission critical (such as simple website).
I would be ok with the separate SSL certs approach, but i don't think SWAG supports the request of separated certificate for specific domains, am i wrong ?

[j0nnymoe]

The separate SSL certs was just another example of something that would over complicate the automations & support.

[SirLouen]

We're not able to come up with a way that it can be automated in a way that it's reliable / easy to use for the end user. Plus if this was something that was added, it increases support bandwidth and development complexity.

What is support bandwidth?

You mean that the idea of SWAG is to shoot low with just a minimal set of configurations to keep things maintainable?

I've been using Caddy (very common also in homelabs) for two years, and since I discovered SWAG, I'm liking it more. Caddy obviously supports all of these treats, the problem is that it has failed me too much, so I prefer to stay with the old trustworthy friend Nginx. But the certificate administration is a pain in the ass for proxied setups.

But at least is good to know what are the future limitations of SWAG, to understand and better limit its use.

[j0nnymoe]

Sorry, when I use the term bandwidth, it's more on how much time/resource it would take within the team.

The idea is to give people a good starting point of an nginx reverse proxy out the box, then user can build upon it.

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.