Nameservers your whole fleet shares

Every zone you host has to be answered by at least two nameservers, and buying two machines per server is not how anybody runs a platform. One pair of nameservers serves the whole fleet: each of your servers publishes its own zones, and both nameservers copy them.

This page is where you say which machines those nameservers are, hand each of them a key, and see whether the copies are actually there.

Open it under Servers → Nameserver sets; the way back is in the top left: ‹ Servers returns you to the server list.

Step 1 — put the nameserver in the fleet

A nameserver is an ordinary CoreCP server. Add it the way you add any other machine, then give it the DNS role in secondary mode. It does not need to know anything about your other servers yet — that is what this page does for you afterwards.

Straight from the installer on a clean machine:

curl -fsSL https://get.corecp.dev | bash
corectl setup --roles dns --dns-mode secondary

Until you register a server with it, the machine is authoritative for nothing and answers nothing. That is correct: a nameserver waiting for its first server should not be answering questions about zones it has never seen.

Step 2 — make a set and put both nameservers in it

A set is simply the list of nameservers your servers share. Press Create a set, give it a name your colleagues will recognise, and tick Make this the default set for new dns servers so a machine you add next month lands in the right place without anybody remembering to do it.

Then press Add a nameserver once for each machine.

Adding a nameserver mints a transfer key for it — one key per nameserver, never one key for all of them. That is what makes taking a nameserver out of service an action with consequences for that machine only. You never see the key itself, and neither does anybody else: the page shows its name and a short fingerprint, which is all you need to check that two machines hold the same key.

Two locks or one: the switch per nameserver

A nameserver is allowed to fetch a copy when two things hold: its address is on the publishing server's list, and it signs its request with the key above. Two locks are harder to lose than one, and that is the default.

So every nameserver's row carries a switch, Key only. Turn it on and the address lock falls away and only the key counts. That is what you want when the nameserver's address is not fixed — a machine at a provider that changes IP — or when somebody spoofing that address is a threat you are modelling.

off (default):  key and address both grant access
on:             the key is the only way in

Two things to know. Flipping it applies to every server that replicates through this nameserver; the panel re-applies the registration on all the machines involved, and that is one action rather than a tour. And a nameserver whose switch you have never touched keeps exactly what is on the machine — if a colleague once set it strict by hand there, it stays that way until you choose something else here.

The switch sits at the end of every row, in the same place for each nameserver, so you do not have to look for it when you have three of them under each other.

Step 3 — register your servers

Press Register a server, pick a machine that publishes zones, and leave the set on Default set unless you have more than one.

Registering is two separate pieces of work: the nameserver has to learn about the server, and the server has to learn about the nameserver. The panel does both, one pair at a time, and it writes down which of the two landed. Press it again tomorrow and nothing happens — it only ever does the work that is still missing.

Step 4 — read the links table

The Links table has one row per pair, and the middle column shows the two halves of its registration:

• both halves landed — that nameserver has this server's zones;
• the half on the server is still missing — the nameserver is ready and the server has not been told yet, usually because it was unreachable at the time;
• did not land — neither half is in place, with the reason on the row.

When anything is unfinished, a Finish button appears above the table with the number on it. Pressing it redoes exactly the missing halves and nothing else, so it is safe to press at any time and on any number of servers.

Step 5 — check that the copies are current

Measure freshness asks every server what its nameservers are actually serving, and compares it against what that server publishes. The answer is a comparison of zone serial numbers, not a stopwatch: a nameserver is in step when it answers the same serial, and behind when it answers an older one — however long ago that happened.

A row that says "2 zones behind, for 31m" means those two zones have been out of date for half an hour, which is long past the seconds a normal transfer takes. The usual causes are the machine being down, or a firewall between the two that stopped allowing transfers.

The same measurement shows up on the server's own checklist as dns replication, so you do not have to be on this page to find out.

corectl dns replication status      # the same answer, on the server itself

Taking a nameserver out of service

Remove the links that point at it first, then take it out of the set. The panel refuses the other order on purpose: a nameserver removed from under a live registration would keep receiving zones nobody in the panel knows about.

Nothing disappears from the internet the moment you unlink: the zones a nameserver already holds stay until they expire, which is what gives you time to change the delegation at the registrar.

Which PowerDNS your nameservers run

Since this release a nameserver runs PowerDNS 5.1 from the project's own supported branch, mirrored into CoreCP's repository, instead of the 5.0 that came with the operating system. A nameserver never talks to the project's servers itself: it reads the copy CoreCP publishes, and it is held on that branch so that a nightly update cannot move it off.

Nothing about your zones changes — the same records, the same DNSSEC keys, the same transfer keys, and the copies keep arriving the way they did. If you want to check, the server's health check names the version and the branch it came from; a nameserver that has drifted off the branch says so there.

If something looks wrong

• A pair stays "did not land". Read the reason on the row. It is the answer the machine gave, in full.
• A nameserver answers nothing at all. Check that it is up and that its DNS service is running; the freshness column says "no answer" rather than pretending it is in step.
• A zone is on one nameserver and not the other. Press Finish, then Measure freshness again. If it persists, the transfer is being refused — the key or the addresses in between are what to look at.

A link that did not land

When registering a server with a nameserver failed, the link shows a heading in your own language — for example The server did not answer in time — with the message underneath as the server gave it. Press Finish to try again once the server answers.