Domains, DNS and HTTPS

Nothing points your domain at us for you

Creating a site does not create a single DNS record, and the portal does not show you a target address anywhere. Until you set the records below yourself, your hostname resolves wherever it resolved before, the site serves nobody, and no certificate can be issued.

This is the step people miss.

Which hostnames a site may serve

A hostname is accepted only if it is already known to your account. Two cases qualify:

• A domain on your account. It becomes a primary domain of the site.
• A subdomain of a zone your account owns. It becomes an additional hostname. shop.example.com works as soon as example.com is on your account.

Anything else is refused when you save:

domain is not registered to this account and is not a subdomain of a zone you own: shop.example.net

Add the domain to your account first, or transfer it in. There is no way to attach a hostname whose parent zone we do not know.

The two fields are not interchangeable. Putting a subdomain into the primary domain field tells you so directly:

domain is not registered to this account and is not a subdomain of a zone you own: shop.example.com is a subdomain — add it as an additional hostname instead

A domain already serving another hosting site is refused too:

domain already attached to another hosting site

A site must end up with at least one hostname of either kind:

at least one domain or additional hostname is required

The records to set

Point every hostname the site serves at both addresses:

Type	Value
A	91.98.6.3
AAAA	2a01:4f8:1c1f:7bfa::1

Set both. IPv6-only visitors get nothing without the AAAA record, and an AAAA pointing somewhere else is worse than none at all, because clients that prefer IPv6 will use it.

If the domain's DNS is managed here, add the records in the domain's zone editor in the portal. If it is hosted elsewhere, add them at that provider.

Do not use a CNAME for the bare domain

example.com needs A and AAAA records. A CNAME at the zone apex is not valid DNS and most providers refuse it. Use the addresses above.

www is not automatic

Adding example.com does nothing for www.example.com. You decide which of the two is the real site, and you configure the other one. Both options need the www hostname to have its own A and AAAA records, pointing at the same two addresses.

Option 1, redirect www to the bare domain. This is what most sites want. Add a redirect on the site under Redirects: source www.example.com, target example.com, status 301. Visitors land on one canonical address and search engines see one site.

Option 2, serve both. Add www.example.com under Additional hostnames. Both names then serve the same files, which means duplicate content unless your application canonicalises them itself.

Redirects

A redirect answers one hostname with a 301, 302 or 308 to another, and 301 is the default. It is a hostname-level redirect: the path is preserved, and the redirect always goes to HTTPS.

Four rules, each with its own message:

• The target must be a hostname the same site already serves.

  redirect target must be a primary domain on the same site: www.example.com -> example.org

• The source may not also be served by the site. One hostname cannot both serve files and redirect.

  redirect source domain is already used elsewhere: www.example.com is also a primary domain on this site

• The source must be in a zone your account owns, like any other hostname.

  not authorized: www.example.net is not in an owned zone

• A hostname cannot redirect to itself.

  redirect target must be a primary domain on the same site: www.example.com redirects to itself

You also cannot remove a primary domain while a redirect still points at it. Remove the redirect first.

HTTPS

Certificates are issued and renewed for you. There is nothing to upload, nothing to configure and no separate charge, and plain HTTP is permanently redirected to HTTPS for every hostname on the site.

Order matters: DNS first, then the certificate

Issuance validates over HTTP against the hostname itself, so the record has to resolve here before a certificate can be issued. If you create the site and check immediately, the browser shows a certificate warning. That is the expected state, not a fault.

Set the records, wait for them to propagate, and allow up to an hour between the hostname resolving here and HTTPS working.

Move an existing live site in this order, and the visible downtime is the DNS propagation only:

1. Create the site and upload the files.
2. Lower the TTL on the existing records, a day ahead if you can.
3. Point the records here.
4. Wait for the certificate, then test.

What's next

• Runtime and PHP settings to choose PHP version and web server
• Troubleshooting if the hostname resolves but serves the wrong thing