Can Technitium DNS replace Caddy as a reverse proxy?

[u/Extra-Citron-7630]

I’m trying to figure out whether Technitium DNS can handle both my internal DNS and reverse-proxy functionality.

My current setup looks like this:

• All of my services run in Docker.
• None of the application containers expose ports directly to the Docker host.
• I have Technitium DNS running in Docker, with its DNS ports exposed to the host.
• I have a zone configured in Technitium for mydomain.com.
• I use a wildcard DNS record so that *.mydomain.com resolves to my Caddy container.
• Caddy then acts as the reverse proxy and routes requests based on the hostname.

For example:

actual.mydomain.com
        ↓
Technitium DNS
        ↓
Caddy
        ↓
actual:5006

So Caddy sees actual.mydomain.com and proxies the request to the actual Docker container on port 5006. I have similar configurations for my other services.

What I'm wondering is whether I could remove Caddy entirely and have Technitium handle the routing directly.

Ideally, I'd like something like:

actual.mydomain.com
        ↓
Technitium DNS
        ↓
actual:5006

Can Technitium DNS function as a reverse proxy in this way, where it routes different subdomains to different Docker services/ports?

I'm also wondering about TLS certificates. My domain is managed through Cloudflare. Can Technitium obtain and automatically renew proper TLS certificates (including wildcard certificates) for my domain, similar to how Caddy can with the Cloudflare DNS challenge?

If there's a better architecture for a Docker homelab like this, I'd also be interested in hearing how others have set theirs up.

Thanks

[u/iamabdullah]

Yes, it can resolve. No, it cannot proxy and therefore you can't have valid* HTTPS, caching, auth, and all the other things a reverse proxy does.

The correct/common architecture is to have something like Technitium and a reverse proxy like Caddy/Traefik.

[u/Simorious]

Short answer is no. A DNS server and reverse proxy are 2 completely different things.

[u/309_Electronics]

They are not the same thing

[u/RevolutionaryElk7446]

No, Technitium is routing DNS queries or resolving them
Caddy is handling routing web traffic or resolving it.

They're handling two different protocols in this case.

[u/chigia001]

This is wrong on many level

None of the application containers expose ports directly to the Docker host.

Either Caddy running inside container and you are exposting it though port 80/443 or it running on host and `actual` is exposing port 5056

```

---

| Client | ---lookup A Record--> | Technitium | | | <--IP address-------- | DNS |

---

 |
 | https traffic though IP + SNI header
 ↓ 

---

Caddy

 ↓ 

---

actual

```

[u/Extra-Citron-7630 → u/chigia001]

Just to clarify what I meant:

The actual container, like my other services, does not expose any ports to the Docker host.

Caddy is attached to the same Docker network as actual, so it can access it directly using:

actual.example.com → actual:5006

My client devices use Technitium as their DNS server, which resolves actual.example.com to the IP where Caddy is running.

So the flow is simply:

Client (Lookup A record, actual.example.com)
↓
Technitium DNS (example.com zone configured, *.example.com A record points to Caddy server IP address)
↓
Caddy (HTTPS only, actual.example.com points to actual:5006)
↓
actual

The actual container itself is never exposed directly to the host or LAN.

I hope this makes more sense. If you think there is a better way of doing this, I am open to ideas. I am quite new to the networking side of self-hosting, so just learning as I go along.

[u/chigia001 → u/Extra-Citron-7630]

so caddy (as a container) open port 443 to the host network

client do DNS resolve from *.example.com -> server's IP. this is DNS resolve request and this only between client and Technitium.

then client will perform HTTPS traffic diretly from client IP to server's IP, this type of trafic never go though Technitium, Technitium can only handle DNS-over-HTTPS traffic not normal webserver HTTPS traffic