Add support for additional DNS records to Fermyon Cloud's custom domains feature.

[luca-aurelia]

Is your feature request related to a problem? Please describe.

Let's say you have the domain example.com, and that you've set up a service like Google Workspace to receive email at hi@example.com.

If you connect example.com as the domain for a Fermyon Cloud app, it breaks your Google Workspace installation.

Why does this happen?

Google Workspace (and many other services) need TXT, MX, and similar DNS records associated with a domain to function.

Currently, Fermyon Cloud works by adding NS records to your domain, pointing your domain at Fermyon's name servers.

When this happens, your domain registrar's name servers no longer handle your domain, and the additional TXT / MX / etc. records you've set through your registrar no longer take effect.

Describe the solution you'd like

In my experience, other hosting services don't use NS records to connect custom domains. Instead, they usually use CNAME or A records.

Another approach would be to continue using NS records and instead allow users to inform Fermyon's name servers about what additional DNS records should be associated with a domain. This feels a little clunky to me -- it starts requiring you to build out domain registrar type functionality which I don't think makes sense for your business. But it's technically an option.

There might also be some technical way to continue using NS records, but have Fermyon's name servers somehow automatically detect the TXT / MX / etc. records set with your registrar and replicate them. I don't know enough about DNS to say whether this is possible or practical, but might be worth looking into.

Describe alternatives you've considered

You can work around this by hosting your Fermyon Cloud app on a subdomain. For instance, example.com for Google Workspace and app.example.com for your Fermyon Cloud app.

Unfortunately, this means you can't use Fermyon Cloud to host marketing / landing pages where visitors go to example.com and expect to email you at hi@example.com.

[PeterMHammond]

Just asking as I'm setting up a custom domain to be used on Fermyon Cloud. I've setup a Cloud Flare domain with an email forwarder. If I use this root domain on Fermyon Cloud, the email forwarding will no longer work?

[rajatjindal]

If I use this root domain on Fermyon Cloud, the email forwarding will no longer work?

that is my understanding as MX records will no longer be found for the domain as Fermyon Cloud does not support additional DNS records for now.

[PeterMHammond]

If I use this root domain on Fermyon Cloud, the email forwarding will no longer work?

that is my understanding as MX records will no longer be found for the domain as Fermyon Cloud does not support additional DNS records for now.

This is a major issue.
What are optional workarounds or what is the timeline to resolve it. I asked in discord, if SMTP was going to be a new trigger option and we'd have a SPIN email component like the kv-explorer or file-server.

[macolso]

@PeterMHammond, unfortunately DNS records and trigger types beyond HTTP are not on the immediate roadmap for this quarter. We will certainly re-evaluate the requests in upcoming planning cycles later this summer. Apologies for the inconvenience this gap may have introduced. In the meantime, the recommended mitigation to maintain functionality in existing DNS records would be to keep your root domain on another provider and use a subdomain on your Spin app deployed on Fermyon Cloud.

That being said, your SMTP suggestion is an interesting one. I wonder if an external SMTP listener could trigger a Spin App with a standard HTTP trigger... Will move conversation over to Discord to continue brainstorming 👍

[bacongobbler]

I was able to find a workaround for those who have a Cloudflare account. This workaround will allow you to manage a custom domain without needing to delegate DNS records to Fermyon. This works with both root TLDs as well as subdomains.

Step 1: deploy your app to Fermyon Cloud. Take note of its hosting URL. In this example I'll use my-spin-app.fermyon.app.

Step 2: create a root CNAME record to your fermyon app. Make sure it is set to "proxied" mode. It should look something like this:

Step 3: Create a Cloudflare worker with the following code:

export default {
    async fetch(request) {
        const proxyDomain = "my-spin-app.fermyon.app";

        const url = new URL(request.url);
        url.hostname = proxyDomain;

        return await fetch(url.toString(), request);
    },
};

Step 4: create a worker route with Route = mydomain.com/* and Worker = the cloudflare worker you just created.

What's going on here?

When a request for https://mydomain.com is requested, the request is passed to Cloudflare's proxy. The domain matches the worker route, which executes the cloudflare worker. The worker renames the request's host header to match the name that Fermyon's load balancer expects. The request is then passed along to Fermyon Cloud.

Full (strict) TLS encryption works with this solution. Cloudflare's certificate is served to the client, and the backend's (Fermyon Cloud) TLS certificate is verified by Cloudflare.

What if I don't use Cloudflare?

You could perform something similar using nginx's proxy_pass and proxy_set_header rules. All that is required is the ability to rewrite the host header in-transit to Fermyon Cloud.

Note that Cloudflare does have an official host header origin rule which could be used to the same effect. However this is a feature that is available only on the Enterprise plan.

I did want to take a moment to recognize that this issue is something our engineering team is well aware of, and as @macolso mentioned, we will certainly re-evaluate these feature requests in upcoming planning cycles later this summer. We apologize for the inconvenience this feature's initial roll-out may have caused.

[migsar]

Just leaving a comment to let you know this a major issue for me as well. This is the second time I try to deploy some small project to prod in Fermyon and have to find an alternative because of the DNS. I am not an expert in DNS and probably there is a workaround, but in my case one of the reasons for moving the project to fermyon was to have everything (serverless functions, sqlite, key-value) in the same place, if I have to keep another service just for the DNS proxy it doesn't make much sense.

I think @PeterMHammond suggestion would be really nice, to have a mail service, like serverless AI, key-value and sqlite, the SMTP trigger would be the cherry on top of the cake.