Custom domain

By default, applications answer under the platform's domain. With a custom domain, they answer under your company's domain instead — store.apps.acme.com rather than an address that advertises the vendor.

How it works

You delegate a subzone to Zero. Once, your DNS team publishes four NS records pointing the subzone at Zero's nameservers:

apps.acme.com.  NS  ns1.dns.nnumbers.com.br.
apps.acme.com.  NS  ns2.dns.nnumbers.com.br.
apps.acme.com.  NS  ns3.dns.nnumbers.com.br.
apps.acme.com.  NS  ns4.dns.nnumbers.com.br.

From then on, apps.acme.com and everything under it is served by Zero. Every new application — store, admin, whatever comes next — is born without a single ticket to the DNS team.

A subzone, never the whole domain

Zero manages a subzone of your domain, and never the whole domain (acme.com). Delegating the main domain would hand Zero the www, your email — MX, SPF, DKIM, DMARC — and every record in the domain. Zero does not manage those records: your email would stop.

To publish a name at the main level, with no subzone, use Keep my current DNS.

What Zero controls and what it never touches

Zero controls	Zero never touches
The delegated subzone and everything under it	The main domain (acme.com)
The applications' addresses (store, admin, …)	www.acme.com
Certificate validation records inside the subzone	MX, SPF, DKIM, DMARC — everything to do with email

That boundary is technical, not a promise: Zero's nameservers are authoritative only for the subzone.

Zero never asks for your DNS credentials

There is no field anywhere in the product for a DNS provider's access key, token, username, or password. Those credentials would give Zero power over your entire domain, including your email. If someone asks for them in NNumbers' name, it is not the product.

Choosing the subzone name

The console suggests apps because it is the word most people recognize, but the field is editable: cloud, systems, platform — whatever makes sense to you.

What is not editable is the depth: exactly one label below the registrable domain. apps.acme.com is valid; a.b.acme.com is refused. The rule comes from the wildcard certificate that covers the zone's addresses.

Step by step

1. Request the zone

Under Domains, at organization level, choose Let Zero handle DNS and enter your company's domain and the name that goes before it. The console shows a preview of the zone before you confirm.

2. Wait for the zone to be prepared

While the zone is being prepared, the console shows progress — and does not show the nameservers. They are only true once the zone exists; copying them earlier would have you configure DNS for a zone that does not answer yet.

3. Publish the four NS records at your provider

When the state changes to Waiting for configuration at your provider, the four nameservers appear, ready to copy. Publish them in your domain's DNS.

The console walks you through your provider's steps, with the name each panel uses for the same field. See Delegating at your provider.

The most common mistake

Some panels want only apps in the name field; others want the whole apps.acme.com. Getting it wrong creates the delegation at apps.acme.com.acme.com — with no error message and nothing answering. The console tells you which case your provider is.

4. Confirm

Click I've configured it. Zero checks the delegation in three layers:

1. the parent domain — yours — publishes the subzone's four NS records;
2. Zero's servers answer for the zone;
3. public resolvers already see the delegation.

The state moves through Confirming the delegation until it reaches Ready. In the first few minutes it is normal for the third layer not to pass yet: the diagnosis is Propagation pending, and the platform checks again on its own.

5. Use the zone in your projects

Once the zone is ready, it appears as a domain option when creating projects. Choose the zone before choosing the address: the zone is its base.

Zero creates, inside the subzone, the record for each application address on its own — a CNAME to the platform's edge — and removes it when the address stops serving (an address change or the project's deletion). The address answers over HTTPS, https://store.apps.acme.com; a request over http:// is redirected to https:// with the same path and parameters.

The zone's states

State	Meaning	Whose next action
Preparing the zone	The request was registered and the zone does not exist yet	The platform's
Waiting for configuration at your provider	The four nameservers are ready to copy	Yours
Confirming the delegation	The delegation appeared and is being checked	The platform's
Ready	The zone serves and can take addresses	None
Serving, with a DNS discrepancy	It was ready once and a later check disagreed	Yours, but nothing is taken down
Removing	Removal was requested	Depends on the step
Could not prepare the zone	A non-transient failure	Requesting again is safe

Two guarantees worth spelling out:

• A discrepancy does not take an application down. A zone in discrepancy keeps serving: taking down what is live because of a possibly transient DNS discrepancy would turn an alert into an incident.
• An undelegated request expires in 7 days. So requesting the zone of another company's domain is not a free way to reserve their name.

When the check does not pass

The console shows the exact reason:

Diagnosis	What happened	What to do
No NS found	The provider announces no nameserver for the subzone	Check that the records were published, and in the right place
Partial delegation	Some of the four are published	The console lists which are missing
Extra nameservers	Another operator also answers for the subzone	Remove the previous operator's records
Propagation pending	The delegation is published and has not yet reached public resolvers	Wait. This is normal in the first few minutes, and the platform checks again on its own, at growing intervals
Parent domain unreachable	Your domain's server could not be reached	Not your error; the check repeats on its own
Request expired	7 days passed with no delegation	Request the zone again

Keep my current DNS

For a name at the main level — store.acme.com, with no subzone —, or for anyone who needs to keep administering DNS at their current provider, there is the Keep my current DNS path. There is no delegation in it: you publish a few records by hand in your DNS, per domain, and the console shows them on each domain's card.

Both forms coexist in the same organization: a delegated subzone for the applications, and individual names kept in your DNS. If the option shows as disabled, the console itself points out the missing step.

Removing a zone

Removal happens in steps, and the zone keeps serving through most of them — deleting it before the delegation is withdrawn would leave your domain pointing at nothing for the duration of the cache.

1. You request removal. Nothing has been destroyed yet, and cancelling returns the zone to what it was.
2. You remove the four NS records at your provider.
3. Once the withdrawal is confirmed, the zone goes offline and the name stays reserved for 30 days — handing it to another organization while old caches still point here would send one customer's traffic to another.

A zone in use by a project refuses to be removed. Delete the project first.

Availability

Creating custom domain zones is available in the organization's Domains section. See What exists today.

Next steps

• Delegating at your provider
• Project address
• Creating and managing projects