Requesting DNS Record Changes
Find out whether you or CTO2B adds, changes or removes a DNS record in your zone, and what to send when you ask for a change.
Use this page when you need a DNS record added, changed or removed, for example
a domain-verification TXT record, email DKIM or SPF records, or a hostname for a
new application, and want to know whether you do it yourself or raise a request with CTO2B.
Who changes records in your zone
By default, you own your DNS zones and create records yourself. CTO2B
changes records only in a zone where you have explicitly given CTO2B access,
for example DNS permissions on your Cloudflare account.
| Your situation | Who creates the record |
|---|---|
| CTO2B has no access to the zone | You, in your DNS provider |
| You have granted CTO2B access to the zone | CTO2B, on request, or you |
| You are not sure | Ask in your dedicated Slack channel before changing anything |
Domain ownership, the registrar and the DNS provider account itself stay with
you in every case. See What You Can Do vs. What We Manage.
Records the platform creates for you
The platform does not create records in a zone it cannot reach. If CTO2B manages
the zone for you, records for new application hostnames can be created as part
of setting the application up.
Saving a hostname in SVIEW does not create a DNS record by itself. SVIEW adds
the hostname to your application's routing, but the record in your zone is
always a separate step, made by you or, where CTO2B manages the zone, by CTO2B
on request.
If you move a zone to a DNS provider CTO2B has no access to, records for new
applications are no longer created for you. For every new hostname you then
create the record yourself, pointing it at the load balancer address shown in
the SVIEW Environment view.
Everything else (verification, email, MX, and records unrelated to the
platform) is always a separate change, made by you or requested from CTO2B.
What to send in a request
Raise a request in your dedicated Slack channel with one line per record. Copy
values exactly from the provider that asked for them; a single wrong character
makes verification fail.
| Field | Example |
|---|---|
| Zone | example.com |
| Name | @ for the apex, or selector1._domainkey |
| Type | TXT, CNAME, A, MX |
| Value | the exact string from your provider |
| Priority | MX records only, for example 10 |
| Add, replace or remove | say which, and quote the existing record for a replace or removal |
For Cloudflare zones, say if the record must be proxied. Verification, DKIM and
MX records must be DNS only, not proxied.
Common requests
| Request | Record | Notes |
|---|---|---|
| Domain verification (search console, SaaS tools) | TXT on @ or on the name the provider gives | Several verification TXT records can sit on the same name |
| Email DKIM | CNAME or TXT on <selector>._domainkey | Providers often issue two or three; send them all in one request |
| Email SPF | TXT on @ starting v=spf1 | Only one SPF record per name is allowed. Adding a sender means merging it into the existing record, not adding a second one |
| Email DMARC | TXT on _dmarc | |
| Mail delivery | MX on @ | Include the priority |
| Hostname for a new application, or moving a hostname to a new Environment | CNAME for a subdomain, A for an apex | Value is the load balancer address of the target Environment. See Ingress, Custom Domains and TLS |
| Records that resolve only inside your network | A to an internal load balancer, or a private zone | Describe what should resolve and from where, so the options can be discussed with you |
| Cleaning up old email records | any | List the records to remove and confirm the sender is no longer in use |
Email forwarding and mailbox settings are configured in your email provider,
not in DNS.
Moving a zone to or from another DNS provider
A zone move changes which provider answers for every record in the domain, so
plan it before changing nameservers.
- Export or list every record in the current zone, not only the ones used by
the platform. - Recreate them in the new provider and compare the two with
digagainst
each provider's nameservers. - Change the nameservers at your domain registrar. This is done by whoever
holds the registrar account, normally you. - Tell CTO2B in your dedicated Slack channel, and say whether CTO2B should
have access to the new zone. Without access, new application hostnames
become a manual step for you (see the warning above).
Raise the request before step 3 if you want CTO2B to review the record list.
Verify the change with dig
Check which provider is authoritative for the domain:
dig +short NS example.comCheck the record itself:
dig +short TXT example.com
dig +short CNAME selector1._domainkey.example.com
dig +short MX example.com
dig +short myapp.example.comTo skip your local resolver cache, ask a public resolver or the authoritative
nameserver directly:
dig +short TXT example.com @1.1.1.1A change can take up to the old record's TTL to be visible everywhere. If the
authoritative nameserver returns the new value but your resolver does not, wait
for the TTL to expire. If the authoritative nameserver also returns the old
value, the change was not made in the zone that is actually live, which is
common right after a zone move.
Related articles
Updated 17 days ago