Module 5 · 5.3
NS, SOA and other records
Module 5: Other records · Reading time: 7 minutes
Learning objective: After this lesson you'll recognise the other records you come across in a zone, and know that you usually don't need to touch them.
Key concepts: NS in the zone, SOA (serial number, refresh, retry, expire, minimum), TLSA (DANE), HTTPS and SVCB, DS and DNSKEY
Records that are simply there
Open the DNS screen for a domain, and alongside A, CNAME, MX and TXT you'll often see a few records you didn't create yourself. Most of them are there for a good reason, and you leave them as they are. In this lesson you'll learn to recognise them, so you won't be alarmed and won't accidentally remove them.
| Record | What it does | Edit it yourself? |
|---|---|---|
| NS | Which nameservers manage the zone | Rarely |
| SOA | The technical header of the zone | No, the panel handles this |
| TLSA | Fingerprint of a certificate (DANE) | Only if you use DANE |
| HTTPS / SVCB | Hints for a faster, secure connection | Usually handled by your DNS provider |
| DS / DNSKEY | Parts of DNSSEC | No, via the DNSSEC button |
| PTR | From IP address back to name | Not in your own zone (lesson 4.6) |
NS: the nameservers in your own zone
In lesson 2.1 you saw that the registry records which nameservers your domain has. Those same nameservers also appear in your own zone as NS records:
example.com. 3600 IN NS ns1.hosting.example.
example.com. 3600 IN NS ns2.hosting.example.The two lists must match. If you change the NS records in your zone, nothing changes at the registry: you change nameservers at your registrar (lesson 2.3). So leave the NS records on the bare domain alone.
An NS record on a subdomain is something you can create yourself, though. This hands management of that subdomain to another party:
lab.example.com. 3600 IN NS ns1.otherprovider.example.Everything under lab.example.com is then looked up at that other nameserver. This is called a delegation, exactly what a registry does for your whole domain.
SOA: the technical header
Every zone has exactly one SOA record (Start of Authority), on the bare domain. Many panels don't even show it. Here's what it looks like:
example.com. 3600 IN SOA ns1.hosting.example. hostmaster.example.com. (
2026110701 ; serial number
14400 ; refresh
3600 ; retry
1209600 ; expire
300 ) ; minimum| Field | Meaning |
|---|---|
ns1.hosting.example. | The primary nameserver of the zone |
hostmaster.example.com. | The administrator's email address, with a dot instead of the @: hostmaster@example.com |
| Serial number | A version number. It goes up with every change. Often in the form year-month-day-sequence number. |
| Refresh, retry, expire | How often secondary nameservers check the primary server for a new version, how quickly they retry, and when they stop answering if the primary server has been unreachable for too long |
| Minimum | How long a resolver may remember that a name doesn't exist (the negative cache, RFC 2308). More on this in lesson 6.2. |
The serial number is useful when troubleshooting. If two nameservers for the same domain report a different serial number, they have different versions of the zone. One may already be giving out your new record, while the other is still giving the old one. With a lookup tool (lesson 8.2) you can check the serial number per nameserver.
TLSA: DANE for mail
A TLSA record (RFC 6698) contains a fingerprint of a server's certificate. This is called DANE. A sending mail server can then check whether it's really talking to your mail server and not to an intruder. DANE only works if your domain has DNSSEC (lesson 8.1). You'll see TLSA records under names like:
_25._tcp.mail.example.com. IN TLSA 3 1 1 <long hex code>This means: port 25, protocol tcp, server mail.example.com. A TLSA record that no longer matches the certificate (for example after renewal with a new key) causes mail from strict senders to be rejected. Only create one if your panel maintains it automatically.
HTTPS and SVCB: hints for the browser
The HTTPS record and its more general sibling SVCB (RFC 9460) are new. They give a browser information in advance, for example that the site supports HTTP/3 and which addresses it runs on. This makes the first connection slightly faster.
example.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=192.0.2.10Note: despite the name, the HTTPS record has nothing to do with your SSL certificate. Without an HTTPS record, https still works fine. Large DNS providers with their own network often set this record automatically. You rarely need to create it yourself.
DS and DNSKEY: DNSSEC
DNSKEY records contain the public keys used to sign your zone. The DS record is a fingerprint of that key and isn't in your own zone, but at the registry. Together they form the chain of trust of DNSSEC. You don't manage them by hand, but via your DNS provider's DNSSEC feature. Lesson 8.1 explains how it works and what goes wrong during a transfer.
Summary
- Leave the NS records on the bare domain alone; you change nameservers at the registrar. An NS record on a subdomain hands management of that subdomain to another party.
- The SOA record is the header of the zone, with a serial number that goes up with every change. The minimum field determines the negative cache.
- TLSA (DANE) links a certificate to a server and only works with DNSSEC.
- HTTPS and SVCB records are hints for the browser and have nothing to do with your certificate.
- DS and DNSKEY belong to DNSSEC and are managed via the DNSSEC feature.
Quiz
Exercise
Exercise Z5.3: SOA: administrator and negative cache. Look up the SOA record for wikipedia.org. Fill in the administrator's email address (the second field, with an @ instead of the first dot) and the value of the last field (minimum, the negative cache) in seconds.
There's no configuration exercise for this lesson: you'll rarely create these records yourself.
Further reading
These articles describe the WebOké panels; other panels work in a similar way.