DNS-recordtyper forklaret: A, AAAA, CNAME, MX, TXT, NS og mere

En DNS-zone fungerer som internettets telefonregister. Domænenavnet er det navn du slår op, og records er de forskellige typer svar du kan få tilbage - ikke bare én telefonnummer-type, men mange slags oplysninger afhængigt af hvad du spørger efter. Åbner du en DNS-zone for første gang, møder du en liste af forkortelser der kan virke uigennemskuelig. Den liste er ikke tilfældig. Hver recordtype løser et specifikt problem, og når du forstår dem, falder DNS-fejlfinding på plads af sig selv.

A-record - grundstenen

En A-record kobler et domænenavn til en IPv4-adresse. Det er den mest fundamentale record i hele DNS-systemet, og uden den ved ingen browser hvor den skal sende sine pakker. Når du skriver example.dk i adresselinjen, er det typisk en A-record der afgør hvilken server forespørgslen ender hos.

Syntaksen er enkel: domænenavnet til venstre, IP-adressen til højre, og en TTL-værdi der fortæller DNS-resolvere hvor længe de må cache svaret. En lav TTL på 300 sekunder giver fleksibilitet ved servermigrationer. En høj TTL på 86400 sekunder reducerer DNS-forespørgsler men gør ændringer langsommere at udbrede.

AAAA-record - IPv6-varianten

En AAAA-record gør præcis det samme som en A-record - men til IPv6-adresser. IPv6-adresser er 128 bit lange mod IPv4's 32 bit, hvilket er grunden til de fire A'er: adressen er fire gange så lang. En typisk AAAA-record peger på noget i retning af 2a01:4f8:c2c:5b21::1.

De fleste moderne servere og domæner bør have begge recordtyper konfigureret. Klienter der understøtter IPv6 foretrækker det via den mekanisme der hedder Happy Eyeballs, mens IPv4 fungerer som fallback. Har du kun en A-record, mister du ikke noget kritisk - men du udnytter heller ikke den infrastruktur der er bygget til fremtiden.

CNAME-record - alias til et andet navn

CNAME står for Canonical Name og fungerer som et alias: i stedet for at pege på en IP-adresse peger den på et andet domænenavn. Det bruges klassisk til at lade www.example.dk pege på example.dk, eller til at koble et subdomæne til en ekstern tjeneste som en CDN-udbyder eller et SaaS-produkt.

Her er den vigtige begrænsning, som mange løber ind i: du må ikke placere en CNAME på et root-domæne (apex-domæne). Årsagen er teknisk - et domæne på rodniveau skal have en SOA- og NS-record, og en CNAME må ifølge DNS-standarden ikke eksistere side om side med andre records for samme navn. Forsøger du at sætte en CNAME på example.dk direkte, vil mange DNS-udbydere enten afvise det eller producere uforudsigelig adfærd. Løsningen er enten en A-record på apex eller en proprietær ALIAS/ANAME-record som nogle DNS-udbydere tilbyder.

En CNAME-kæde - altså en CNAME der peger på en CNAME der peger på endnu en CNAME - er teknisk lovlig men bør undgås. Det tilføjer latenstid og skaber vedligeholdelsesproblemer.

MX-record - e-mailens trafikdirigent

MX-records (Mail Exchanger) styrer hvortil e-mail til dit domæne skal leveres. Uden en MX-record ved afsendende mailservere ikke hvor de skal aflevere beskeder, og e-mail til dit domæne vil enten bounce eller ende i limbo.

Hver MX-record har to komponenter ud over selve domænenavnet: en prioritetsværdi og et mailserver-hostnavn. Prioritetsværdien er et positivt heltal - jo lavere tal, jo højere prioritet. En opsætning med to MX-records kunne se sådan ud:

example.dk.  MX  10  mail1.example.dk.
example.dk.  MX  20  mail2.example.dk.

Afsendende servere forsøger altid den laveste prioritet først og falder tilbage på den næste, hvis den primære server ikke svarer. Det giver redundans uden ekstra konfiguration på klientsiden. Bemærk at MX-records skal pege på et hostnavn - aldrig direkte på en IP-adresse og aldrig på et CNAME.

TXT-record - den alsidige allrounder

TXT-records indeholder fritekst og er i dag den foretrukne mekanisme til en lang række verifikations- og sikkerhedsformål. Oprindeligt tænkt som menneskelig dokumentation er TXT-records nu rygraden i e-mailsikkerhed og domænebekræftelse.

De vigtigste anvendelser:

• SPF (Sender Policy Framework): Definerer hvilke mailservere der har lov at sende e-mail på vegne af dit domæne. En SPF-record ser ud som v=spf1 include:_spf.google.com ~all og placeres på root-domænet. Mangler SPF, øges risikoen markant for at dine e-mails havner i spam. Læs mere i artiklen om hvordan SPF-records fungerer.

• DKIM (DomainKeys Identified Mail): Indeholder den offentlige nøgle der bruges til at verificere e-mailsignaturer. DKIM-records placeres på et specifikt subdomæne som selector._domainkey.example.dk.

• DMARC: Fortæller modtagende mailservere hvad de skal gøre med e-mails der fejler SPF eller DKIM. Placeres på _dmarc.example.dk.

• Domænebekræftelse: Google Search Console, Microsoft 365 og mange andre tjenester beder dig tilføje en unik TXT-record for at bevise ejerskab over domænet.

Et domæne kan have flere TXT-records - og det er helt legitimt. Har du SPF, DKIM og en Google-verifikation, sidder de fredeligt ved siden af hinanden.

NS-record - hvem er autoritativ?

NS-records (Name Server) angiver hvilke navneservere der er autoritative for en DNS-zone. Det er dem der kender de rigtige svar for dit domæne - alle andre DNS-resolvere spørger dem, når de ikke har svaret i deres cache.

NS-records sættes typisk af din domæneregistrar og peger på din DNS-udbyders navneservere. Skifter du DNS-udbyder, er det NS-records der skal opdateres - og det er her mange fejl opstår, fordi ændringen skal propagere gennem hele DNS-hierarkiet, hvilket kan tage op til 48 timer afhængigt af TTL-værdier. Vil du tjekke status på dine navneservere, kan navneserver status-værktøjet hjælpe dig.

SOA-record - zonens administrative hoved

SOA-recorden (Start of Authority) er den første record i enhver DNS-zone og indeholder administrativ metadata om zonen selv. Den specificerer den primære navneserver, en administrativ e-mailadresse (kodet som et domænenavn), et serienummer der inkrementeres ved ændringer, og en række tidsintervaller der styrer zone-replikering mellem navneservere.

De fleste webmastere behøver aldrig redigere SOA-recorden manuelt - DNS-udbydere håndterer den automatisk. Men den er værd at kende, fordi serienummeret er nøglen til at forstå om sekundære navneservere har synkroniseret de seneste ændringer.

PTR-record - reverse DNS

Mens A-records oversætter navne til IP-adresser, gør PTR-records det modsatte: de oversætter en IP-adresse tilbage til et domænenavn. Det kaldes reverse DNS, og det administreres ikke i din normale DNS-zone men i en særlig zone kontrolleret af IP-adressens ejer - typisk din internetudbyder eller hostingudbyder.

PTR-records er primært relevante for mailservere. Mange spamfiltre udfører et reverse DNS-opslag på den afsendende servers IP-adresse og afviser e-mails hvis der ikke er et match. Sender din mailserver fra IP-adressen 203.0.113.42, bør der eksistere en PTR-record der peger tilbage på dit mailserver-hostnavn.

SRV-record - til specifikke tjenester

SRV-records (Service) giver klienter mulighed for at finde servere der tilbyder en bestemt tjeneste på et domæne. Formatet inkluderer tjenestens navn, protokol, prioritet, vægt, port og målhost. Microsoft Teams, Skype for Business, SIP-telefoni og andre VoIP-løsninger bruger SRV-records til at dirigere trafikken korrekt.

En SRV-record for SIP over TCP kunne se sådan ud:

_sip._tcp.example.dk.  SRV  10  20  5060  sipserver.example.dk.

Prioritet og vægt fungerer analogt med MX-records: lavere prioritet foretrækkes, og vægt bruges til load balancing mellem servere med samme prioritet.

CAA-record - certifikatkontrol

CAA-records (Certification Authority Authorization) giver domæneejere mulighed for at specificere hvilke certifikatudstedere der har tilladelse til at udstede SSL/TLS-certifikater til domænet. Det er et sikkerhedslag der reducerer risikoen for fejludstedte certifikater - en angriber der forsøger at få udstedt et certifikat for dit domæne hos en alternativ CA, vil blive afvist hvis din CAA-record ikke tillader det.

En simpel CAA-record ser sådan ud:

example.dk.  CAA  0  issue  "letsencrypt.org"

Har du ingen CAA-record, må alle certifikatudstedere som udgangspunkt udstede certifikater for dit domæne. Vil du analysere dit domænes SSL-konfiguration, kan du bruge SSL/TLS analyse-værktøjet.

Hurtig referencetabel

Slå records op for dit eget domæne

Den hurtigste måde at omsætte denne viden til praksis er at kigge på et rigtigt domæne. DNS opslag-værktøjet giver dig et komplet overblik over alle records for et valgfrit domæne - A, MX, TXT, NS og resten - direkte i browseren uden at skulle åbne en terminal. Det er et naturligt udgangspunkt, når du skal debugge en mailopsætning, verificere at en DNS-ændring er slået igennem, eller blot forstå hvad et domæne faktisk er konfigureret til.

Vil du grave dybere i e-mailsikkerhed, kan du bruge SPF analyse-værktøjet til at validere din SPF-record og identificere eventuelle fejl i konfigurationen.

Fra forkortelser til fejlfinding

DNS-problemer er næsten altid et spørgsmål om en forkert eller manglende record. E-mails der bouncer? Tjek MX og SPF. Hjemmesiden der ikke loader? Tjek A eller CNAME. Certifikatet der ikke udstedes? Tjek CAA. Når du kender de ti recordtyper og deres formål, har du et mentalt kort over DNS-zonen der gør det muligt at isolere fejlen hurtigt - uden at gætte i blinde eller vente på support. Den viden er ikke forbeholdt netværksspecialister. Den tilhører enhver der ejer eller vedligeholder et domæne.