Managing DNS records

DNS is the address book of the internet: it tells the rest of the world where yoursite.com lives, where your post should go and who may send on your behalf. This page shows how to look at those entries and change them.

Screenshot — Panel → Hosting → Accounts → your account → DNS. At the top is the DNS for picker, which switches between the domains of your account. Screenshots are captured with openwolf designqc into .wolf/designqc-captures/.

Looking at the zone

The top of the page carries what you need to know about the zone:

• Zone — its name.
• Backend — where the zone actually lives. That is this server's PowerDNS, or an outside party such as Cloudflare.
• Kind and Serial — the sequence number that goes up on every change. A secondary nameserver that sees a higher number fetches the zone.
• DNSSEC — signed, or off. See below.

Under that is the table of every record: Name, Type, Value, TTL.

corectl dns zone list
corectl dns zone show yoursite.com
corectl dns record list yoursite.com

Adding a record

1. Click Add record, or use the + A, + CNAME and + MX buttons above the list when you know which type you need.
2. Name — empty or @ means the domain itself. www means www.yoursite.com; the part the panel adds for you is shown inside the box, so you can see which name you are about to make.
3. Type — pick one from the list. There are twenty; type the first letters to find one. Each type carries a one-line note about what it is for.
4. The fields below change with the type. Choose MX and the panel asks for a preference and a mail host instead of one box that has to contain both. Choose SRV and it is priority, weight, port and target; CAA asks for a flag, a tag and a value.
5. Under the form is the line the zone will hold. It comes from the server itself and appears while you type. If something about the value is wrong, the reason is there and the save button stays off — so you never have to save first to find out whether it was right.
6. Under Advanced are the TTL and, on backends that have one, the proxy switch. Pick a TTL from the set values (five minutes to a day) or type your own; the defaults are nearly always right.
7. Click Add.

corectl dns record add yoursite.com www A 203.0.113.10
corectl dns record add yoursite.com @ MX "10 mail.yoursite.com."
corectl dns record add yoursite.com @ TXT "v=spf1 a mx ~all" --ttl 3600

# the same answer the panel puts under the form, on the command line
corectl dns record preview yoursite.com @ MX "20 backup.yoursite.com"
    zone     yoursite.com
    before   yoursite.com 3600 IN MX 10 mail.yoursite.com.
    after    yoursite.com 3600 IN MX 10 mail.yoursite.com.
    after    yoursite.com 3600 IN MX 20 backup.yoursite.com.

Changing a record is adding the same one with --replace, which replaces every value of that name and type in one go:

corectl dns record add yoursite.com www A 203.0.113.55 --replace
corectl dns record remove yoursite.com www A

When the value does not fit the fields

Beside Value is a Raw value switch. It shows the record as one line, exactly as it is stored. Two moments where you want it:

• You are pasting a value from somewhere — a DKIM key, a line out of a service's instructions. Paste it into the raw box and you are done.
• An existing record does not fit the fields. That happens: a record set by hand or by another panel need not have the shape the fields expect. The panel opens such a value as a raw value on its own and says so. Nothing is ever rewritten that the panel did not understand.

Going back to the fields works too, as long as the value fits them. When it does not, the panel stays where it is rather than throwing your input away.

Several values on one name

Two MX records on your domain are not two separate records: they are one answer with two lines in it, and a mail server delivering to you reads both. So the panel shows them as one row in the list, with × 2 beside the type, and you edit them together:

• Click the row and you see each value on its own, each with Change and Remove beside it.
• Add a value puts another one in.
• Remove record at the bottom takes the whole answer away.

On a record with one value you can also change the TTL and the proxy switch under Advanced. With several values at one name you cannot: the TTL belongs to the whole answer, and the panel would have to take the answer apart and rebuild it. It says so where the TTL would have been.

The types you need

Three things that often go wrong:

• A CNAME on the domain itself (@) is not allowed. The domain also needs an MX and an SOA, and a CNAME excludes everything beside it. Use an A record there.
• A name that points at a name ends in a dot. yoursite.com. is absolute; yoursite.com without the dot reads as yoursite.com.yoursite.com.
• The TTL is a memory, not a setting. Set a TTL of 24 hours, then change the address, and some visitors keep seeing the old one for a day. If you are moving soon, lower the TTL to 300 first and change the record after.

Those are the seven you need in practice. The panel offers twenty; the other thirteen are there for whoever knows them and needs them:

What you cannot change: the SOA record and the nameservers of the zone itself. Those belong to the zone and the server keeps them in step; they are in the list, but they open without editable fields. NS below your domain and DS ask for a reseller, because both hand a name to somebody else.

If your zone runs at Cloudflare it is eighteen: Cloudflare has no ALIAS (use a CNAME on the domain itself, which Cloudflare flattens) and no separate SPF type (use TXT). The panel shows those two with the reason instead of a button whose only outcome is an error.

The MX when a mail gateway stands in front of your server

If a mail gateway handles a domain's mail (see Mail that is held back), that domain's MX points at the gateway instead of at the mail server. Two things are worth knowing:

• It is per domain. With three domains and the gateway on for only one of them, only that one MX changes. The other two keep pointing at the mail server.
• A gateway may be more than one machine. Then you see several MX lines, each with its own number in front — the lowest number is tried first and the rest are the fallback.

dig +short MX yourdomain.com

10 pmg1.srvnl.nl.
20 pmg2.srvnl.nl.

If we host your DNS these records are there for you and are updated the moment the switch is flipped. mail.<your domain> always keeps pointing at the mail server: that is where your mail program signs in.

Records for a subdomain

A subdomain website (staging.yoursite.com, shop.yoursite.com) deliberately has no DNS zone of its own. Its records belong in the zone of the main domain — otherwise you would have two zones drifting quietly apart, and you would need delegation records at the registrar for something that simply sits next to your site.

So to give shop.yoursite.com an address, you add a record in the yoursite.com zone with Name shop:

corectl dns record add yoursite.com shop A 203.0.113.10
corectl dns record add yoursite.com staging CNAME yoursite.com.

The same rule holds for text records of a subdomain:

corectl dns record add yoursite.com _acme-challenge.shop TXT "…"

If you do want a subdomain as a zone of its own — because a customer manages it themselves, say — that is a separate zone with delegation; ask your administrator for it.

There is no zone yet

If the page says No DNS zone yet, this server does not manage the DNS of this domain. Two possibilities:

• The zone belongs here — click Create zone. The server fills it immediately with the records that follow from your website and mail configuration.
• The zone belongs at your registrar or at Cloudflare — leave it there and change it there. A zone that lives in two places drifts apart quietly.

corectl dns zone add yoursite.com --from-domain
corectl dns zone export yoursite.com        # the whole zone, as text
corectl dns zone remove yoursite.com

Do not forget that the nameservers at your registrar have to point at this server; without that nobody ever asks this zone anything. Which names those are:

corectl dns nameserver show

DNSSEC — and why it is off by default

DNSSEC puts a signature under your DNS answers so nobody can substitute a different address along the way. Good idea — but it only works once the last step is taken too: the DS record at your registrar. Without that step your zone is signing into thin air.

That is why DNSSEC is off by default here. Switching it on is a deliberate act in two steps:

1. In the panel, turn on Sign this zone with DNSSEC. The backend makes the keys and publishes the DS record.
2. Copy the DS record for the registrar that is shown into the control panel of your domain name.

corectl dns dnssec enable yoursite.com     # signs, and prints the DS record
corectl dns dnssec show yoursite.com
corectl dns dnssec disable yoursite.com

Switching it off goes in the opposite order: remove the DS record at your registrar first, wait until that has expired everywhere, and only then stop signing. A DS pointing at keys that no longer exist makes your whole domain unreachable — the classic way to remove yourself from the internet.

Secondary nameservers

One nameserver is one outage. A second server serving the same zone keeps your domain up while the first is under maintenance. In CoreCP you register it on the primary, after which zones are transferred automatically and every change is announced with a NOTIFY.

# on the primary
corectl dns secondary add ns2.yoursite.com --ip 203.0.113.20,2001:db8::20
corectl dns secondary list
corectl dns secondary join-command          # the line to run on the secondary
corectl dns notify yoursite.com             # transfer now instead of later

Then register both names at your registrar. Before publishing a zone the primary asks every registered secondary whether it knows the domain yet — which catches the failure where the second nameserver is listed in DNS but serves nothing.

How fast is a change on both? Within seconds. The primary announces every change with a NOTIFY and the secondary fetches the zone straight away. If you see a change on the first nameserver and, minutes later, still not on the second, the announcement was refused on the way: a secondary accepts a NOTIFY only from the address at which it knows its primary. Ask the secondary — it writes the refusal down together with the address it saw — and put that beside the address the primary is registered with. Without the announcement the second nameserver waits for its own round past the primary, which is three hours by default.

When something is not right

Always check at the source:

dig +short A     www.yoursite.com
dig +short MX    yoursite.com
dig +short NS    yoursite.com @1.1.1.1
dig +short TXT   _dmarc.yoursite.com

A subdomain has no DNS zone of its own

If you have a website on, say, staging.test300.com, you will look for its DNS settings under that subdomain in vain: those records belong in the zone of test300.com. That is deliberate. Two zones for one domain is a delegation, and a delegation nobody asked for is an outage waiting on a TTL.

The panel now takes you there itself. Open the DNS page of such a subdomain and the parent's zone opens, with a chip above the list reading Records for staging.test300.com in test300.com. While it is on you see only the records that belong to that subdomain — its own address, its www, its mail host, its DMARC and MTA-STS lines and its DKIM key. Click the chip away and the whole zone is back.

Add a record while the filter is on and the name field already starts with the subdomain — so "add an A record here" means what the filter says it means.

From the server it is one line, and you can ask for a subdomain's whole set at once:

corectl dns record add test300.com staging A 185.117.226.123
corectl dns record list test300.com --under staging.test300.com

Until the round-2 final check a technical error stood here (no such endpoint). That was not the subdomain: the page asked its question before it knew which domain you were looking at. A second one stood here after that — powerdns does not have this zone, the server reporting a missing zone that was never meant to exist. That one is gone too: the server now says which zone does hold the records, and the page takes you there.

An extra name does get a zone of its own

Unlike a subdomain, an extra name is a main domain in its own right, so it does get its own DNS zone on this server — with the same records as any other website: the domain itself, www, and the mail records if the name carries your main domain's mail.

corectl domain alias add mycompany.com mycompany.co.uk
dig +short @<server> mycompany.co.uk SOA

That zone is then left alone. There is deliberately no automatic sync from your main domain's zone: it would overwrite every change you make in the extra name's zone, and "my TXT record was gone this morning" is a nastier problem than "I had to enter it twice".

If that name's DNS lives somewhere else and you want to keep it there, use --no-dns (or leave the Create a DNS zone switch off in the panel).

The value column is a column again

In the record table the Value column was squeezed to a single character wide for a while, so a long TXT record stood vertically and the VALUE and TTL headers fell over each other. The cause was in the table itself: two columns each claimed the leftover width. Exactly one is elastic now, every other column is one line with an ellipsis, and the whole value is one row-click away.

# the measurement that keeps it that way
node corecp-panel/web/scripts/check-tables.mjs --url=http://127.0.0.1:5199 --route=/accounts/acc-1/dns
#   1 table(s) measured, 0 finding(s)

"No website yet" — and what to do about it

DNS records belong to a website: the zone they live in is a domain's zone, so without a domain there is no zone to manage. On an account with no website the DNS screen explains that — it used to show a red error instead, because the page asked for a zone with no name.

1. Go to Accounts → your account → DNS.
2. Press Add website and add the website.
3. Come back to DNS. The zone has been created with its default records in it, and the domain switcher above the page points at it.

If you may not add a website yourself you get the same explanation with a View websites link.

Does your domain point here? The DNS preflight

A website that is ready here while its name still points somewhere else is the best-known reason for "my site does not work". So the panel asks the question itself, in two places: in the Add website form as soon as you have typed a name, and on the account's overview, as an advisor row.

The question has two halves: does the name point at this platform, and if not, which nameservers belong here. The answer is one of four:

It is a statement, not a lock. You can always add a website, also when the check is amber — that is exactly what you do when you move a domain: put the website here first, then switch the nameservers. The Add website button keeps working.

Under the verdict are the findings themselves, in the same list as when you change a record: a short headline in your language and the server's own sentence under it. That sentence names the nameservers the domain is delegated to now.

The check asks at the source — the nameservers of the zone above (.nl, .com), and then the nameservers those point to — and not a resolver in between. A resolver answers with what it remembered, and right after a delegation was changed that is the old answer.

From the terminal

# corectl dns preflight example.net
elsewhere  example.net
  belongs    ns1.corecp.dev, ns2.corecp.dev
  delegated  betty.ns.cloudflare.com, hugh.ns.cloudflare.com
  answers    104.20.21.8, 172.66.175.59
  warning   example.net is delegated to betty.ns.cloudflare.com, hugh.ns.cloudflare.com, not to this platform, …

Several names at once works (corectl dns preflight a.nl b.nl), and with --account <name> the check uses that account's nameservers for a name that is not there yet.

See also

• Making sure your email arrives — the four mail records, explained.
• SSL and certificates — wildcard certificates need your DNS zone.
• Making a test environment — why a staging subdomain lives in the parent zone.

Your own nameservers

If you sell hosting under your own name, your customers can see ns1.yourbrand.com instead of our nameservers — including the check on whether the registry knows where that name is. That is in Your own nameservers.

A zone at Cloudflare instead of with us

Not every zone has to be served by our own nameservers. If a domain lives at Cloudflare, the panel can manage that zone there — provided the server has an API token of yours.

Such a token is kept per server, and since August 2026 you can store one from the panel: Settings → Integrations → Cloudflare DNS. Pick the server, press Store a token, give it a name and paste it. Afterwards you see only the name, the provider and the Cloudflare account — the token itself never appears again, and there is no button or address that could read it back.

If the token is wrong or expired the form says so at once and nothing is stored: it is checked against Cloudflare first. The token needs Zone:Read + Zone:Edit and DNS:Read + DNS:Edit on the zones it manages.

Which zone uses which token is then chosen here, on the domain's own DNS page. More about the other couplings is in Integrations.

From the terminal the token goes in through the input, never as an option — an option is visible to everyone on a shared server while the command runs:

printf '%s' "$TOKEN" | corectl dns credential set default --token-stdin

Give --token and --token-stdin together, or send an empty input, and corectl refuses instead of storing an empty token.

Why webmail. is sometimes not there

The name webmail.yourdomain.com appears in your zone only while the server really offers your webmail. With webmail switched off, or on a server that cannot serve it for the moment, the record is not published — a name that leads to an empty page is worse than a name that is not there, and it would end up on your certificate as well.

Switch webmail on and the record appears by itself; ask for a new certificate once afterwards, so the name is inside the padlock too. You can see the record on the domain's DNS page, between mail. and the rest.

What leaves the parent zone when you remove a subdomain

A subdomain website keeps its records in the main domain's zone. Remove the subdomain and all of its records go with it — since August 2026 that includes the mail-security set (_mta-sts, mta-sts, _smtp._tls, mail., webmail.), so no promise to sending mail servers is left pointing at nothing. Records you added by hand yourself stay.

When your administrator moves the server's zone storage

The records you manage here live on the nameserver itself. On servers your administrator has converted, they now live in a store that belongs to the server instead of in the database server that also holds website databases.

Nothing changes on your side: the same records, the same buttons, the same wait before the world sees a change. What you may notice:

• During the move the nameserver is restarted once. A question that arrives at that moment is simply asked again — resolvers do that by default — and the rest of the internet answers from its cache.
• Servers are converted one at a time. A second nameserver that has not been converted yet goes on answering, so your domain is never off the air because one machine is busy.

To see for yourself whether a change has landed, ask both of your nameservers and compare the serial number:

dig +short @ns1.example.com example.com SOA
dig +short @ns2.example.com example.com SOA

If the two serials differ, wait a few minutes and ask again; the second nameserver fetches the new version on its own.

What a change means, before you save it

Under the form you already saw the line the zone will hold. Since September 2026 you also see what that change means, in the order of how much it weighs:

• The server refuses this. Something that works today would stop. A DMARC policy at a name no receiver reads it at; a second SPF policy (two count as none); an MX pointing at an alias; a CAA record that locks out the certificate authority this server renews with — that one fails weeks later, when you are no longer thinking about it.
• Careful. It goes through, and it takes something with it. "This website moves to another address." "Mail follows this record."
• Advice. It works, and there is a more usual way.
• For information. A fact about what happens.

It never says when the world will see your change — a nameserver cannot know that. What it does say is the TTL that was being served up to now: whoever already fetched the old answer keeps it that long. Anything another panel promises you about "24 to 48 hours" is a guess.

Removing now asks what it costs first

Pressing Remove used to do it straight away, with an undo in the message. That undo is still there, but it was half an answer: putting a record back restores the zone and not what went wrong meanwhile. Mail that bounced while the MX was gone does not come back with the record.

So the panel asks the server first, and shows you:

1. which lines leave the zone (struck through) and what stays;
2. what that costs, in the same four kinds as above.

If it weighs heavily — the last MX of a domain whose mailboxes are here, the DKIM key your mail is still signed with — the server refuses, and the dialog asks for a reason. That reason goes into the log beside the change. The exception stays a choice you can find again later, instead of something someone did with a terminal.

Cloudflare can do less, and it now says so

If your zone lives at Cloudflare, two things work differently there:

• ALIAS does not exist. Cloudflare resolves a CNAME on the domain itself (CNAME flattening), so put a CNAME there. The type is not offered, with that reason beside it.
• SPF as a separate record type has never been measured. The panel says so honestly instead of pretending to be sure: the type is still there, with the note that since 2014 an SPF policy belongs in a TXT record — which is what senders look up.

Put a name behind the proxy and you see two notes: your own address is no longer visible (anything that has to reach your server by name — an MX target, an SSH host — needs a name that is not proxied), and the TTL you filled in is not used: Cloudflare serves a proxied name with a fixed 300 seconds.