Zone file & SOA
The Interface page covers how a panel's screen represents a record. This page covers what's actually sitting behind that screen: a zone file, a plain text file with one line per record, that your panel is really just a friendlier way of editing. Every record explained elsewhere on this site, an A record, an MX record, a TXT record, is really just one such line.
SOA: the record that always exists
SOA stands for Start of Authority, and unlike every other record on this site, you never add one. A zone has one SOA record at its apex, generated automatically the moment the zone itself is created, and normally written first in a zone file. What you can do, on most panels, is view it; on some, you can edit a handful of its numbers, covered field by field below.
| Field | What it means | Can you change it? |
|---|---|---|
| MNAME | The primary master for this zone: the server its data originates from. | No, managed by your provider. |
| RNAME | The administrative contact, written as a dotted name instead of an email address: hostmaster.example.com. means hostmaster@example.com, the same "notation differs, meaning doesn't" pattern as the apex on the Interface page. |
No, managed by your provider. |
| Serial | A version number that goes up by at least one whenever any record in the zone is added, changed or removed. A secondary nameserver compares this number against the last one it saw: a newer serial means its own copy is now stale and it needs to fetch a fresh one. | No, managed by your provider. |
| Refresh | How often a secondary nameserver should check the primary for updates. | Technically yes, in an advanced zone editor. Almost nobody ever does. |
| Retry | How long to wait before trying again if a refresh check fails. | Technically yes. Almost nobody ever does. |
| Expire | How long a secondary keeps answering for this zone if it can't reach the primary at all, before it gives up entirely. | Technically yes. Almost nobody ever does. |
| Minimum | How long a "no such record" answer (a lookup that came back empty) may be cached. Often called the negative caching TTL. | Technically yes. Almost nobody ever does. |
The pattern in that last column is deliberate, not an oversight: three of these fields are entirely out of your hands, and the other four are only editable in theory. In day to day use, the SOA record is one you'll see far more often than you'll ever touch.
The serial is genuinely worth checking when troubleshooting a site that isn't showing up properly somewhere. Look up the SOA record on each of the domain's nameservers, and if the serial numbers don't match, that mismatch on its own explains what you're seeing: one nameserver is still answering with an older version of the zone. Nothing more exotic is going on. The mismatch remains until that nameserver successfully refreshes its own copy, it doesn't fix itself on any fixed schedule, so if it persists it's worth investigating directly rather than waiting it out.
What a zone file looks like
Here's a small, generic zone file, the kind of thing you'd see if you asked your provider for the raw zone rather than looking at it through their panel. The SOA record is written first, as it normally is, followed by the same NS, A and MX records covered on their own pages elsewhere on this site:
$TTL 3600
example.com. IN SOA ns1.dns-provider.example. hostmaster.example.com. (
2026092701 ; serial
7200 ; refresh
3600 ; retry
1209600 ; expire
3600 ) ; minimum
example.com. IN NS ns1.dns-provider.example.
example.com. IN NS ns2.dns-provider.example.
example.com. IN A 192.0.2.10
www.example.com. IN A 192.0.2.10
example.com. IN MX 10 mx.mail-provider.example.
The trailing dot, and why it's there
Every name in that example ends in a dot (ns1.dns-provider.example. rather than ns1.dns-provider.example). That's not a formatting quirk, it represents the root zone itself, and it lines up with the order a lookup actually happens in: a domain name is read from right to left, ending at that final dot.
That's roughly the order a resolver works through it, too. It starts at one of the root servers, whose contents are managed by IANA. Those servers know nothing about your domain, but they do know which organisation runs the registry for your domain's extension, Verisign, for instance, for every .com. That registry's own servers don't know your records either, but they do know which nameservers are authoritative for your domain itself, and those are finally the ones that hand back the actual records this site explains, the A, MX, TXT and the rest.
Your panel hides all of this, and rightly so, nobody needs the root zone in mind while adding an A record. It's worth knowing here because it's the reason a zone file writes names the way it does.
Moving a domain to a new registrar
Moving a domain to another registrar usually means moving its DNS as well, and that is where most moves go wrong: not the transfer itself, but a zone that is missing, incomplete or out of reach for a few hours or days. What follows is based on experience with many registrars, and almost all of it varies from one registrar to the next, so read it as what to ask about, not as how it always works.
Writing down what you have
A small zone, ten records or so, can be written down by hand or captured with a screenshot of the panel. One catch: many panels shorten long values in their overview, a DKIM key for example, so open those records one by one, or copy the value as text. For a larger zone, or a site that matters, ask the current registrar for an export of the zone file, usually in the BIND format shown above. Do that before the move starts, not after.
Then ask the new registrar whether it can import a zone file. Not every registrar can, and if yours cannot, every record has to be typed in again, which is exactly where a typo or a forgotten record slips in.
What happens to the old zone
Once the domain has left, the old registrar deals with its zone in its own way. Some delete it within a fixed period, often around 24 hours. Others never delete it at all. That second case sounds safe, but often is not: the domain name is commonly the key to managing its DNS at a registrar, and once the domain is no longer there, the zone may still exist and answer queries, while nobody can change it any more.
The same key works against you at the other end. If the new registrar only lets you manage the DNS of a domain it actually holds, you cannot build the new zone until the transfer is complete.
Moving with the old nameservers
The way around both problems is to transfer the domain while it still points at the old registrar's nameservers. The zone stays live and unchanged during the transfer, you build the new zone at the new registrar once the domain has arrived, check it, and only then switch the nameservers. This only works as long as the old registrar keeps the zone after the domain has gone, so find out how long that is first. If it is 24 hours, that is also how long you have.
DNSSEC: switch it off first
If the zone is signed with DNSSEC, the registry holds a DS record that points at the old DNS provider's keys. Switch nameservers while that record is still there and the keys at the new provider will not match it, and resolvers that check DNSSEC will treat the domain as broken, which for many visitors means it simply stops working. Switch DNSSEC off, so the DS record is removed, about 24 hours before the move, and switch it on again at the new provider once the new nameservers are in use.
The time in between
After the nameservers have changed, resolvers keep using the old ones for a while, because the registry's own record of which nameservers serve the domain is cached too. In most cases that gives you time to set up at least a basic zone at the new registrar before the old servers stop being asked. Leave the old zone untouched in the meantime, and if something has to change, change it in both places.
Talk to both
Before contacting anyone, look up the domain's registration data: whether a transfer lock is set, which nameservers the registry has on file, and whether DNSSEC is registered there, see RDAP / WHOIS. Most of the uncertainty above then disappears with two questions asked before the move: the old registrar how long the zone stays after the domain leaves, and whether it can be exported; the new registrar whether it imports a zone file, and whether you can build the zone before the transfer completes. Contact with both registrars is the one step no move should skip.