Pointing your own domain at a tagging server: the CNAME, the certificate, and Cloudflare error 1014

Two reasons, and they are different. To an ad blocker, a request is third-party if its hostname is on a list, and signalhost.io is not on any list today but could be tomorrow; yoursite.com will never be. To a browser, a cookie set by a response from metrics.yoursite.com is a first-party cookie for yoursite.com, with the longer lifetime that implies, while a cookie from another domain is capped or refused. The tagging server is the same either way. The hostname is what changes how it is treated.

One CNAME, at your DNS provider, pointing the subdomain you chose at our DNS-only endpoint:

metrics.yoursite.com.   CNAME   tenants.signalhost.io.

Not at your random tenant hostname, and not at a wildcard. tenants.signalhost.io is a name we publish specifically for this, and the reason it has to be that name is the next section.

If your own domain is on Cloudflare, create the record with the proxy OFF — the grey cloud, "DNS only". A proxied record would route your visitors' requests through your Cloudflare account to us, and the certificate step below cannot complete through it.

Our own hostnames sit behind Cloudflare. If a customer points their CNAME at one of our proxied names — the wildcard, or a tenant hostname — their traffic arrives at Cloudflare for a hostname that belongs to a different Cloudflare account than ours. Cloudflare refuses that with error 1014, "CNAME Cross-User Banned". The page that shows it is Cloudflare's, mentions neither of us, and nothing in your DNS, your site or your browser explains it.

tenants.signalhost.io is unproxied on purpose: it resolves straight to our servers, so a CNAME at it simply works. The dashboard's DNS check recognises the proxied-target case by name and says what to change, but it is faster to never make it.

Once the record resolves, we request a Let's Encrypt certificate for your hostname. The validation is HTTP-01: Let's Encrypt fetches a specific path over plain HTTP on port 80 from the name, and we answer it. Plain HTTP because there is no certificate yet — that is what is being obtained — and this is the only unencrypted path our edge answers at all. It is a nonce comparison; nothing else is reachable that way.

Expect a few minutes. The dashboard shows three steps in order: the CNAME resolves, the certificate is issued, the hostname is serving. A step stuck on the certificate with the CNAME green almost always means a proxied record on your side — Cloudflare answers the validation request with its own certificate and its own page, and Let's Encrypt sees the wrong thing.

The Google tag in your web container carries the server container URL, and we rewrite it to the custom domain and republish the container when the hostname starts serving — and rewrite it back to the tenant hostname if you remove the domain. Your site's snippet does not change; it loads the container, and the container knows where to send.

Which is why the order of removal matters. Remove the domain in the dashboard first, then delete the DNS record. Delete the record first and, until the dashboard notices, the container is still pointing your visitors at a name that no longer resolves.

• Error 1014 in the browser: the CNAME points at a proxied name of ours. Change the target to tenants.signalhost.io.
• CNAME green, certificate pending for more than fifteen minutes: your record is proxied. Turn the cloud grey at your DNS provider.
• CNAME never goes green: check for a conflicting A or AAAA record on the same name — a CNAME cannot coexist with them — and give propagation up to an hour.
• Serving, but the container page shows no traffic from the new name: the web container has not republished yet. It happens within a couple of minutes of the hostname going live; the container page shows which hostname the tag currently points at.