NS, SOA og andre records
Modul 5: Øvrige records · Læsetid: 7 minutter
Læringsmål: Efter denne lektion genkender du de øvrige records, du støder på i en zone, og du ved, at du oftest ikke behøver at røre dem.
Nøglebegreber: NS i zonen, SOA (serienummer, refresh, retry, expire, minimum), TLSA (DANE), HTTPS og SVCB, DS og DNSKEY
Records der bare står der
Åbner du DNS-skærmen for et domæne, ser du ud over A, CNAME, MX og TXT ofte nogle records, som du ikke selv har oprettet. De fleste er der af en god grund, og dem lader du stå. I denne lektion lærer du at genkende dem, så du ikke bliver forskrækket og ikke ved et uheld fjerner dem.
| Record | Hvad det gør | Selv ændre? |
|---|---|---|
| NS | Hvilke navneservere der styrer zonen | Sjældent |
| SOA | Zonens tekniske hoved | Nej, det klarer panelet |
| TLSA | Fingeraftryk af et certifikat (DANE) | Kun hvis du bruger DANE |
| HTTPS / SVCB | Hints til en hurtigere, sikker forbindelse | Oftest klarer din DNS-udbyder det |
| DS / DNSKEY | Dele af DNSSEC | Nej, via DNSSEC-knappen |
| PTR | Fra IP-adresse tilbage til navn | Ikke i din egen zone (lektion 4.6) |
NS: navneserverne i din egen zone
I lektion 2.1 så du, at registryen registrerer, hvilke navneservere dit domæne har. De samme navneservere står også i din egen zone som NS-records:
example.com. 3600 IN NS ns1.hosting.example.
example.com. 3600 IN NS ns2.hosting.example.De to lister skal stemme overens. Ændrer du NS-records i din zone, sker der ingenting hos registryen: navneservere ændrer du hos din registrar (lektion 2.3). Lad derfor NS-records på det rene domæne (apex) stå.
Et NS-record på et subdomæne er derimod noget, du selv kan oprette. Dermed overlader du administrationen af det subdomæne til en anden part:
lab.example.com. 3600 IN NS ns1.otherprovider.example.Alt under lab.example.com bliver så slået op hos den anden navneserver. Det kaldes en delegering, præcis det samme, som en registry gør for hele dit domæne.
SOA: det tekniske hoved
Hver zone har præcis ét SOA-record (Start of Authority), på det rene domæne. Mange paneler viser det ikke engang. Sådan ser det ud:
example.com. 3600 IN SOA ns1.hosting.example. hostmaster.example.com. (
2026110701 ; serienummer
14400 ; refresh
3600 ; retry
1209600 ; expire
300 ) ; minimum| Felt | Betyder |
|---|---|
ns1.hosting.example. | Zonens hovednavneserver |
hostmaster.example.com. | Administratorens e-mailadresse, med et punktum i stedet for @: hostmaster@example.com |
| Serienummer | Et versionsnummer. Det stiger ved hver ændring. Ofte i formatet år-måned-dag-løbenummer. |
| Refresh, retry, expire | Hvor ofte ekstra navneservere tjekker hos hovedserveren, om der er en ny version, hvor hurtigt de prøver igen, og hvornår de holder op med at svare, hvis hovedserveren er utilgængelig for længe |
| Minimum | Hvor længe en resolver må huske, at et navn ikke findes (den negative cache, RFC 2308). Mere om det i lektion 6.2. |
Serienummeret er nyttigt, når du fejlsøger. Giver to navneservere for samme domæne forskellige serienumre, har de forskellige versioner af zonen. Den ene giver måske allerede dit nye record, den anden stadig det gamle. Med et opslagsværktøj (lektion 8.2) kan du slå serienummeret op per navneserver.
TLSA: DANE til mail
Et TLSA-record (RFC 6698) indeholder et fingeraftryk af en servers certifikat. Det kaldes DANE. En afsendende mailserver kan dermed kontrollere, om den virkelig taler med din mailserver og ikke med en indtrænger. DANE virker kun, hvis dit domæne har DNSSEC (lektion 8.1). Du ser TLSA-records under navne som:
_25._tcp.mail.example.com. IN TLSA 3 1 1 <lang hexkode>Det betyder: port 25, protokol tcp, server mail.example.com. Et TLSA-record, der ikke længere passer til certifikatet (for eksempel efter en fornyelse med en ny nøgle), får mail fra strenge afsendere til at blive afvist. Opret det kun, hvis dit panel holder det automatisk ajour.
HTTPS og SVCB: hints til browseren
HTTPS-recordet og dets mere generelle lillebror SVCB (RFC 9460) er nye. De giver en browser information på forhånd, for eksempel at sitet understøtter HTTP/3, og hvilke adresser det kører på. Det gør den første forbindelse en smule hurtigere.
example.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=192.0.2.10Bemærk: trods navnet har HTTPS-recordet intet at gøre med dit SSL-certifikat. Uden HTTPS-record virker https helt almindeligt. Store DNS-udbydere med eget netværk sætter ofte dette record automatisk. Selv at oprette det er sjældent nødvendigt.
DS og DNSKEY: DNSSEC
DNSKEY-records indeholder de offentlige nøgler, som din zone er signeret med. DS-recordet er et fingeraftryk af den nøgle og står ikke i din egen zone, men hos registryen. Sammen udgør de tillidskæden i DNSSEC. Du administrerer dem ikke manuelt, men via DNSSEC-funktionen hos din DNS-udbyder. Lektion 8.1 forklarer, hvordan det virker, og hvad der kan gå galt ved en flytning.
Opsummering
- NS-records på det rene domæne lader du stå; navneservere ændrer du hos registraren. Et NS-record på et subdomæne overlader administrationen af det til en anden.
- SOA-recordet er zonens hoved, med et serienummer, der stiger ved hver ændring. Minimumfeltet bestemmer den negative cache.
- TLSA (DANE) kobler et certifikat til en server og virker kun med DNSSEC.
- HTTPS- og SVCB-records er hints til browseren og har intet med dit certifikat at gøre.
- DS og DNSKEY hører til DNSSEC og administreres via DNSSEC-funktionen.
Quiz
Opgave
Opgave Z5.3: SOA: administrator og negativ cache. Slå SOA-recordet op for wikipedia.org. Indtast administratorens e-mailadresse (det andet felt, med en @ i stedet for det første punktum) og værdien af det sidste felt (minimum, den negative cache) i sekunder.
Der er ingen opsætningsopgave til denne lektion: disse records opretter du sjældent selv.
Læs videre
Disse artikler beskriver panelerne hos WebOké; i andre paneler fungerer det på lignende vis.