Skip to Content
CUSTOM DOMAIN

Education

Why custom domains are hard

Everyone who ships bring-your-own-domain learns the same lesson: the DNS isn’t the hard part. The hard part is who has to do it.

The gap between an application that knows its DNS records and the DNS host that can write them

The three-actor gap

Your app knows exactly which records it needs. Their DNS host can write them.

Today the integration layer between those two systems is your customer.

SYSTEM

Your app

Knows every record, byte for byte.

HUMAN, THE FAILURE POINT

Your customer

Copy-pastes between two tabs, once, under no supervision.

SYSTEM

Their DNS host

Can write any record, if asked correctly.

Two machines that agree perfectly, bridged by a person doing an unfamiliar, unforgiving task in an interface they’ve never seen. That’s the architecture, and no amount of documentation changes it.

The cost, in numbers

25+

DNS hosts to support, each with its own control panel and record syntax

4+

records in a full apex, www, and ownership-verification setup

2

cases every host does differently: apex flattening and wildcards

1

wrong character and the certificate silently fails to issue

0

of it your users should ever have to see

Every one of these is a place a real setup goes wrong. Custom Domain handles all of them behind a single API call.

Where it goes wrong

The five failure classes

Manual DNS setup doesn’t fail randomly. It fails the same five ways, at every provider, every day.

  1. 01

    Host vs. full domain

    Providers disagree on whether the Host field takes the label (app) or the whole name. Guess wrong and the zone happily saves app.acme.com.acme.com.

  2. 02

    The trailing dot

    Some zone editors require it, some forbid it, none explain it. Leave it off where it’s required and the editor appends the zone: edge.customdomain.ai.acme.com instead of edge.customdomain.ai.

  3. 03

    TTL misunderstanding

    TTL reads like “time until it works,” so customers set TTL 86400 and wait a day for it to “activate” , or give up during a delay that a correct record never needed.

  4. 04

    Record-type confusion

    CNAME wants a name; A wants an address. Instructions written for one get pasted into the other: A  app  edge.customdomain.ai , a hostname where an IP belongs, saved without complaint.

  5. 05

    Conflict collisions

    The new record is perfect, and an old record at the same name still answers. Customers keep the old A record “just in case”, and the stale value wins or the zone editor rejects the pair outright.

The apex problem

DNS forbids a CNAME at the root.

The instruction that works for app.acme.com , “add a CNAME”, is illegal at acme.com itself, because the zone root must carry records a CNAME can’t coexist with. Every DNS host invented its own workaround, each with different names and different behavior, and customers without one end up pinning an A record to an IP address that will eventually change out from under them.

And while everyone is busy with the root, www.acme.com gets forgotten, the visitors who type it land on nothing, and the leak goes unnoticed until someone important is on the wrong half of it.

Closing the gap

How Custom Domain replaces the human middleware

  • DETECT

    We fingerprint the DNS provider as your customer types their domain.

  • WRITE

    Records are injected via provider sign-in, provider-hosted one-click setup, their API token, or guided manual with a one-click check, 25+ providers auto-configured.

  • VERIFY

    Ownership is proven and propagation is watched, no “check back in 24 hours.”

  • SECURE

    The certificate is issued before the first request arrives, and renews without touching their DNS again.

  • SERVE

    Traffic is routed at the edge, apex and www included, every path to the product ends in HTTPS.

See the gap closed, live.

Read how the pieces fit, or watch a domain go live on a real provider.

Read the docs Book Call

See it end to end: How it works