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.

[Boscop]

What if we install the Spin runtime on a Hetzner VPS? https://www.felipecruz.es/how-i-built-my-own-wasm-cloud-with-fermyon-platform/

Can me make use of all possible DNS records in that case (in other words, having email at hi@example.com etc.)?

---

From that blog post:

Also, I must admit that the most difficult part was to configure the DNS records in AWS Route 53 to get Traefik to serve the requests to the WASM app with TLS - something that I decided to skip in this post to keep it simple.

@felipecruz91 Could you please elaborate what you had to do for that? 🙂

[kunjee17]

This is serious issue for me as well. Any kind of sending email from a domain that is mapped to fermyon will not work. If this is not in near roadmap then at least put a work around in document. Something like @bacongobbler mentioned.

Something that works with Namecheap and Go Daddy. This make things difficult to take to production. For my specific issue, I am having resend api integrated. All things work but I can't send email from domain that is mapped to fermyon, just because I can't modify TXT or MX records.

@macolso It would be great if you can provide any ETA for this. Even if it will not going to be done in near future. So, it will give us idea on if we can continue with fermyon or not or find some work around to continue.

[macolso]

Thanks all for the use-case feedback on this thread. Unfortunately we do not have an ETA for support for additional DNS records at this time. I will circle back early 2025 to provide an update on the ETA (unless anything comes up sooner). Apologies for the inconvenience this may cause, but hopefully the update in timeline will aid with your planning efforts.

In the meantime, we'll work on improving the documentation for custom domains to highlight potential workarounds that might help in the interim such as the nginx's proxy_pass approach @bacongobbler suggested above.

[Boscop]

@bacongobbler Does your workaround also work if we have a CloudFlare account but our domain's registrar is not CloudFlare, e.g. porkbun?

[Boscop]

@macolso Yes please include workarounds in the official docs for common reverse proxies such as nginx and also traefik 🙏

[bacongobbler]

Does your workaround also work if we have a CloudFlare account but our domain's registrar is not CloudFlare, e.g. porkbun?

The workaround I described requires the use of Cloudflare's "proxied" mode, which means your domain must be transferred to your Cloudflare account for it to work. I'm not aware of any documentation that suggests how to use Cloudflare workers with another DNS provider - you'd have to transfer the domain from porkbun to Cloudflare for this to work.

Here's an article describing how to transfer the domain from porkbun to another DNS provider like Cloudflare: https://kb.porkbun.com/article/22-how-to-change-your-nameservers

[Boscop]

@bacongobbler I have registered domains on CF in the past, but I moved over to porkbun (for different reasons). So it's unfortunate that this workaround doesn't work for me then :/

---

Here's an article describing how to transfer the domain from porkbun to another DNS provider like Cloudflare: kb.porkbun.com/article/22-how-to-change-your-nameservers

Hm, that article is not about transferring the domain from porkbun to CF but only point the nameservers to CF. Are you saying that would make this workaround work, without having to transfer the domain? :)

[bacongobbler]

Perhaps we're conflating the term "transferring the domain". When I mean "transfer" I mean that you'd be transferring DNS management from porkbun to Cloudflare. porkbun will continue to be the domain registrar.

In the example provided above, I have my domain registered with namecheap, but I "transferred" all of my DNS records to Cloudflare by pointing namecheap to a different nameserver.

Does that help clarify things?

[Boscop]

Ah yes, thanks for clarifying, I can do that, so I'll try this workaround :) So then custom DNS records such as MX etc. will work fine, right?

[bacongobbler]

Yes.

[kunjee17]

Even though Cloudflare worker is having a quite a good amount of free quota but with @bacongobbler 's solution, one has to pay for Cloudflare and Fermyon both per request charge. Just to note here.

[laskinner]

+1 for this. My use-cases were:

1) SaaS app 2) Landing page/donations/contact page for an NPO

Not sure those kinds of use-cases are the audience for Fermyon, but if so this is unfortunately a showstopper.