You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: pages/serverless-containers/how-to/add-a-custom-domain-to-a-container.mdx
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -54,7 +54,7 @@ Read this section if you want more details about how custom domains are handled
54
54
When adding a custom domain, the following tasks will be performed on Scaleway's side:
55
55
56
56
1. Configure the custom domain on our gateways, so that they can handle traffic for that custom domain.
57
-
2. Ensure that the custom domain points to one of the Serverless Container existing endpoints: either the default one `....containers.fnc.<region>.scw.cloud`, or an existing custom domain.
57
+
2. Ensure that the custom domain points to one of the Serverless Container existing endpoints: either the default one `....functions.fnc.<region>.scw.cloud`, or an existing custom domain.
58
58
3. If step 2 is OK, generate a dedicated TLS certificate for that custom domain so it can answer to HTTPS requests.
59
59
60
60
<Messagetype="note">
@@ -73,7 +73,7 @@ HTTP-01 challenge failure (and by extension, a custom domain in `error` status)
73
73
74
74
| Issue | Description | How to fix or avoid this? |
75
75
| ----- | ----------- | ----------- |
76
-
| DNS record is not correctly configured. | If the DNS record (mostly CNAME) is misconfigured on your DNS provider side, and the custom domain to the Serverless Container default endpoint, we will not be able to configure the custom domain. | Ensure that on your DNS provider, a CNAME record links your custom domain to the Serverless Container. To test, you can run the following command: `dig <your_custom_domain>` (or `nslookup`), and make sure that the value returned is a `CNAME` record to `<your_container>.containers.fnc.<region>.scw.cloud`. |
76
+
| DNS record is not correctly configured. | If the DNS record (mostly CNAME) is misconfigured on your DNS provider side, and the custom domain to the Serverless Container default endpoint, we will not be able to configure the custom domain. | Ensure that on your DNS provider, a CNAME record links your custom domain to the Serverless Container. To test, you can run the following command: `dig <your_custom_domain>` (or `nslookup`), and make sure that the value returned is a `CNAME` record to `<your_container>.functions.fnc.<region>.scw.cloud`. |
77
77
| DNS record is not available yet. | This can be the case if the custom domain is created immediately after the CNAME is configured on your DNS provider side. | Wait a few minutes after creating the CNAME on your DNS provider, or at least wait until the DNS record is available on main resolvers (`1.1.1.1`, `8.8.8.8`). |
78
78
| DNS cache is stale (still pointing to an old endpoint). | If the custom domain was pointing to another endpoint before adding the CNAME record to the Serverless Container, and if the TTL is greater than the maximum time of the check (3 min), it can sometimes happen that the custom domain still resolves to the old endpoint, thus making the challenge fail. | Wait until DNS entry is available and use a smaller TTL. |
79
79
| Negative DNS cache is stale | If the initial check fails (DNS record is not available yet), and the negative TTL configured on your DNS provider side is high, the negative TTL will prevent subsequent checks from querying the nameserver again, until it expires. Depending on the negative TTL configured, this can take more or less time. | Either reduce the negative TTL in your DNS provider configuration, or just wait until you are sure DNS record is available. If you already tried to add the custom domain and faced this issue, you likely have to wait for the negative TTL to expire before making another attempt (so the cache can also expire on our side). |
@@ -93,14 +93,14 @@ To clarify, let's take a concrete example:
93
93
- you own a domain `mydomain.com`
94
94
- an `A` record is configured on `website.mydomain.com` and points to `51.15.x.x`
95
95
- when a client accesses `http://website.mydomain.com`, the request hits your Instance IP `51.15.x.x:80`
96
-
- you also have a running version of your website hosted as a Serverless Container (only accessible using `example-website.containers.fnc.fr-par.scw.cloud`), and now you want your users to access this version from `http://website.mydomain.com`
96
+
- you also have a running version of your website hosted as a Serverless Container (only accessible using `example-website.functions.fnc.fr-par.scw.cloud`), and now you want your users to access this version from `http://website.mydomain.com`
97
97
98
98
Before adding the custom domain on your Serverless Container, you must change the DNS record to point to the Serverless Container endpoint:
99
99
100
100
- before: `website.mydomain.com` is an A record to `51.15.x.x`
101
-
- after: `website.mydomain.com` is a CNAME record to `example-website.containers.fnc.fr-par.scw.cloud`
101
+
- after: `website.mydomain.com` is a CNAME record to `example-website.functions.fnc.fr-par.scw.cloud`
102
102
103
-
By doing this, clients that already have the `website.mydomain.com` DNS record cached locally will continue to hit `51.15.x.x`, until the TTL expires. New clients (or those whose cache has expired) will start to hit `example-website.containers.fnc.fr-par.scw.cloud`. **However**, as long as the custom domain is not configured on the Serverless Container, these requests will end up in 404, because `website.mydomain.com` is not (yet) known in our infrastructure. Depending on your downtime tolerance (clients receiving 404) for a few minutes, there are 2 cases:
103
+
By doing this, clients that already have the `website.mydomain.com` DNS record cached locally will continue to hit `51.15.x.x`, until the TTL expires. New clients (or those whose cache has expired) will start to hit `example-website.functions.fnc.fr-par.scw.cloud`. **However**, as long as the custom domain is not configured on the Serverless Container, these requests will end up in 404, because `website.mydomain.com` is not (yet) known in our infrastructure. Depending on your downtime tolerance (clients receiving 404) for a few minutes, there are 2 cases:
104
104
105
105
- downtime is acceptable or can be planned (e.g. during the night or when there is less traffic on your website). In that case, after creating the CNAME record, and once you are sure DNS is available everywhere, create the custom domain on the Serverless Container. Once ready, requests to `http://website.mydomain.com` will hit your Serverless Container (no more 404).
106
106
- downtime is not acceptable. Unfortunately, this is not possible right now out-of-the-box. To serve requests from `website.mydomain.com`, our infrastructure must know it, so a custom domain has to be configured. However, for the custom domain to be configured, the DNS record must point to the Serverless Container endpoint, resulting in a chicken-and-egg problem. To handle such scenarios, a CDN can be configured to serve a cached version of your website while the domain is being reconfigured (for example with [`stale-if-error`](https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/Cache-Control#stale-if-error) option). If you choose this solution, be sure to disable caching on routes starting with `/.well-known/acme-challenge` to avoid issues described in the "Technical details and troubleshooting" section.
0 commit comments