🚨 traefik.me wildcard DNS is globally unreachable (SERVFAIL) — apps inaccessible without fallback

[huseyincenik]

To Reproduce

Description

The traefik.me wildcard DNS service is currently globally unreachable (SERVFAIL).
All Dokploy-generated URLs of the form *.traefik.me fail to resolve, making deployed
applications completely inaccessible to end users — even when the underlying containers
are healthy and running.

⚠️ This is not the first occurrence. The same outage happened in December 2025 (see #3201).

---

DNS Verification

Tested against three independent global resolvers — all fail:

Resolver	Command	Result
Google	dig @8.8.8.8 traefik.me SOA	SERVFAIL — No Reachable Authority
Cloudflare	dig @1.1.1.1 traefik.me SOA	SERVFAIL — Network Error
Quad9	dig @9.9.9.9 traefik.me SOA	SERVFAIL — No Reachable Authority

This confirms the issue is on traefik.me's authoritative DNS infrastructure, not on our side.

---

Impact

Any team relying solely on Dokploy-assigned traefik.me URLs has zero access to their
environments until the external service recovers. There is currently no built-in fallback in
Dokploy to handle this scenario.

---

Suggestions

1. Show direct IP:port links in the Dokploy UI
   Display the raw http://<server-ip>:<host-port> link alongside the traefik.me URL,
   so teams can always reach their services even when DNS is down.

2. Add a traefik.me health indicator to the dashboard
   Proactively warn users when the external DNS dependency is failing, instead of leaving
   them to debug a seemingly healthy stack.

3. Provide a self-hosted DNS alternative
   Consider supporting a nip.io-style pattern or a configurable custom domain, reducing
   dependence on a third-party free service with no SLA.

---

Workaround

Find the exposed port of your nginx container:

docker port <your-nginx-container-name>
# Example output: 80/tcp -> 0.0.0.0:32805

### Current vs. Expected behavior

**Current behavior:**
All Dokploy-assigned `*.traefik.me` URLs return DNS resolution failures (`SERVFAIL`) 
globally. Applications are completely inaccessible to end users despite containers 
being healthy and running. There is no fallback mechanism or warning in the Dokploy 
UI to indicate the issue.

**Expected behavior:**
Either the Dokploy UI provides a direct IP:port access link as a fallback, or it 
displays a warning when the `traefik.me` DNS dependency is unreachable — so teams 
are not left debugging a healthy stack with no indication of the real cause.

### Provide environment information

```bash
OS: Ubuntu 24.04 (x86_64)
Dokploy version: latest (self-hosted)
VPS Provider: Google Cloud Platform (GCP Compute Engine)
Applications: Full-stack app — Next.js (web), NestJS (API), FastAPI (ML backend), PostgreSQL, Redis, Nginx

Which area(s) are affected? (Select all that apply)

Application

Are you deploying the applications where Dokploy is installed or on a remote server?

Same server where Dokploy is installed

Additional context

This is a recurring issue — the same traefik.me outage was reported in December 2025 (#3201).

Verified unreachable from the server itself using three independent global DNS resolvers
(Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9) — all return SERVFAIL, confirming
this is traefik.me's infrastructure failing, not a local misconfiguration.

The workaround is to access apps via http://<server-ip>:<host-port> after finding the
exposed port with docker port <nginx-container>, and manually updating CORS_ORIGIN
and AUTH_TRUSTED_ORIGINS env vars. This is non-trivial for most users and should not
be necessary.

Since traefik.me is a free third-party service with no SLA, Dokploy should not rely on
it as the only access method.

Will you send a PR to fix it?

No

[dosubot]

This has already been addressed. PR #4368 was merged (May 8, 2026) replacing traefik.me with sslip.io for all auto-generated domains. The sslip.io service uses the same IP-in-subdomain format but has better reliability [1].

Additionally, PR #4291 is in progress to add multi-DNS provider support with fallback across traefik.me, nip.io, sslip.io, and backname.io — which would address your suggestion #3 about reducing dependence on a single third-party service.

Immediate workaround: As you noted, docker port <container> to find the exposed port and access via http://<server-ip>:<port>. Alternatively, configuring a custom domain with an A record pointing to your server IP bypasses the wildcard DNS dependency entirely.

See also the duplicate issue #4365 which was filed yesterday for the same outage.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Siumauricio]

Duplicate #4368