Ask an endpoint if a hostname is valid - just like on_demand_tls does

1. The problem I’m having:

Our platform allows tenants to configure custom domain names for their accounts so that they can embed the application in their domain space, and I wonder if there is any mechanism similar to what Global options (Caddyfile) — Caddy Documentation does with its ask endpoint.

Long story short, we want to support wildcard hostnames, but we don’t want to support all hostnames, only those considered valid.

We do ask customers to register a domain name, prove ownership and all that jazz, and then we use the on_demand_tls to only issue certificates for those domains, and that indirectly blocks any requests to unauthorised domain names, but only after the http->https redirect trips: If someone contacts our server under http://bogus.com, the request gets upgraded/redirected to https://bogus.com and because the TLS certificate creation is rejected, the request hangs.

I’d love to not do that redirect at all. I want to either return a 404 straight up, preferably with a customizable 404 page, where we could show a branded message informing the person that the domain name is not configured/enabled on our end.

I didn’t find any plugin and the docs don’t mention anything. So, am I missing something? Or WDYT? Is it a reasonable feature request?

2. Error messages and/or full log output:

None.

3. Caddy version:

2.x

4. How I installed and ran Caddy:

N/A (via official FrankenPHP Docker image)

4a. System environment:

N/A (Docker @ AWS ElasticBeanstalk)

4b. Command:

N/A

4c. Service/unit/compose file:

N/A

4d. My complete Caddy config:

N/A

5. What I already tried, and links to relevant resources:

Went through the docs, looked online for a plugin.

Assistance disclosure

No AI used.

The ask endpoint is currently only part of on-demand TLS certificate issuance, not a general host-authorisation matcher. For this use case, I would disable automatic redirects and implement the HTTP redirect yourself:

{
    auto_https disable_redirects
    on_demand_tls {
        ask https://your-platform.example/check-domain
    }
}
http:// {
    forward_auth https://your-platform.example {
        uri /check-domain?host={host}
    }
    redir https://{host}{uri} permanent
    handle_errors {
        respond "domain is not configured" 404
    }
}
https:// {
    tls {
        on_demand
    }
    reverse_proxy ...
}

That lets your platform reject unknown hosts on plain HTTP before redirecting them to HTTPS. If you want this as a built-in matcher, then yes, that would be a reasonable feature request but today forward_auth or a small plugin is probably the practical route.