Secure Delegation for Service Hosting Across Domains

Feature Requests
1

Let's imagine a service that uses the combination of localpart and domain as identifiers (e.g., user@example.com), similar to XMPP, email, and Matrix. An organization wants to use its own domain (example.com) for user identities, but delegate the actual hosting to a third-party provider.

Traditionally, this delegation is done using SRV records, such as:

_xmpp-client._tcp.example.com. ...
_xmpp-server._tcp.example.com. ...

_matrix._tcp.example.org. ...

However, this approach lacks a secure mechanism to link the identity domain (example.com) with the hosting provider’s infrastructure. Since DNS is not secure by default, an attacker could manipulate SRV record responses and perform a man-in-the-middle (MITM) attack, redirecting users to a malicious server.

Obtaining certificates for each customer domain is often not practical for hosting providers. It would typically require either access to the customer's web server (to place validation files) or control over their DNS (to insert validation records) -- neither of which is feasible or scalable.

This problem has been considered before. One proposed solution is described in RFC 7711, which involves placing a file in the .well-known directory of the domain to indicate delegation. Matrix, for example, supports delegation through either SRV records or files placed under .well-known. While this method can be secure against MITM attacks, it has notable drawbacks: any vulnerability in the domain’s web server (e.g., via a compromised CMS) could allow an attacker to modify the .well-known file and silently redirect clients to a malicious server—intercepting credentials and communication.

At present, there appears to be no widely adopted, secure, and practical solution to this delegation problem that doesn't introduce new risks or infrastructure complexity.

Proposed Idea: Service-Specific Certificates

One possible solution could be the introduction of a new type of certificate—restricted to a specific service (e.g., XMPP, Matrix, etc.). This certificate would include a dedicated field indicating the service it is intended for.

Validation would work the following way:

  1. The client first resolves the SRV record for the service, retrieving the target domain of the hosting provider.
  2. The client then connects to the hosting provider's server and verifies that the presented certificate is valid and includes a trusted delegation assertion for the original domain and service.

This would leverage the existing certificate infrastructure, while allowing secure, service-specific delegation without needing control over the customer's web server or DNS.

2

Let's Encrypt and ACME do not use SRV records for delegation (uses NS or CNAME).

But, I think you would find the below thread helpful. I linked to post #21 by Aaron Gable so you can see comment from an LE staff person. The entire thread is full of informed and useful info by other volunteers so I recommend that after reading Aaron's post to start at the top

3 Likes
3

I was referring to how clients for protocols like XMPP locate their servers. In those cases, SRV records are typically used to map the identity domain (like example.com) to the hosting provider’s infrastructure.

4

Maybe it's me, but what is your proposal fixing exactly? Which issue?

Because for unsecure DNS there's already DNSSEC, DNS over HTTPS, DNS over TLS et c.

1 Like
5

I'm confused. This is exactly what the vast majority of managed service providers who offer custom domain integration for web services actually do today.

Is the difference here that what the hosting provider is trying to secure is not a typical web service?

3 Likes
6

If authenticated DNS was widely available, CAs wouldn’t be that necessary. We could publish certificate hashes in DNS records, similar to DANE, letting clients verify them directly.

However, DNSSEC adoption remains low (Cloudflare, SIDN), with many TLDs and registrars still not supporting it.

As for DoH and DoT, they’re supported by OSes, but require manual configuration. An app could use a built-in resolver, but then the user would need to accept the ToS and privacy policy of that hardcoded resolver. This would delegate full trust over authentication to that resolver, which is a separate problem.

7

Let’s say a corporation wants to use the same domain (example.com) for web hosting, email, XMPP, and Matrix, each hosted by a different provider. That’s entirely possible -- SRV records (and MX records for email) exist for exactly this purpose. For instance, the A record could point to the web host, MX (and possibly IMAP SRV) records to the mail host, XMPP SRV records to the XMPP provider, Matrix SRV or well-known delegation to the Matrix provider, and so on.

The challenge is that there’s no straightforward way to secure this setup, because only the web hosting provider can obtain a certificate for example.com.

9

I think that @petercooperjr summarized the issue well:

There are two possibilities here:

  1. The client expects a certificate for example.com. If some-other-host.example.net is third-party hosted, that brings the practical challenges of obtaining such a certificate that I described in my initial post.

  2. The client expects a certificate for some-other-host.example.net. In this case, a MITM attack could simply redirect the client to evil.com, and it would connect without complaint.

Also, there was no further comment from @aarongable in that thread.

10

Let’s take email as an example. Suppose the example.com domain has an MX record pointing to example.net. If you want to use STARTTLS, which domain should you expect to see in the server’s certificate when you connect?

11

Actually, there is already an RFC with a very similar ude: RFC 4985 - Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name