DNS Records forklaret: Komplet guide til A, AAAA, CNAME, MX, TXT og mere

Introduktion til DNS Records

DNS (Domain Name System) oversætter menneskelæselige domænenavne til de IP-adresser computere bruger. Denne oversættelse sker via DNS records - forskellige typer af poster der hver tjener et specifikt formål.

At forstå DNS records er fundamentalt for alle der administrerer websites, email eller anden online infrastruktur. I denne guide gennemgår vi alle vigtige record-typer med praktiske eksempler.

A Records: IPv4-adresser

A-records (Address records) er den mest grundlæggende record-type. De mapper et domænenavn til en IPv4-adresse.

Syntaks

domæne.dk.    IN    A    192.0.2.1

Praktiske eksempler

; Website på rod-domæne
example.dk.        A    93.184.216.34

; Subdomæne til specifik server
api.example.dk.    A    93.184.216.35
www.example.dk.    A    93.184.216.34

; Flere A-records for load balancing
example.dk.        A    93.184.216.34
example.dk.        A    93.184.216.35

Best practices for A records

• Brug altid den faktiske IP-adresse, ikke hostnames
• Overvej flere A-records for redundans
• Sæt passende TTL (typisk 300-3600 sekunder)
• Dokumentér hvilken server hver IP tilhører

AAAA Records: IPv6-adresser

AAAA-records (quad-A) er IPv6-ækvivalenten til A-records. Med IPv4-adresser ved at løbe tør er IPv6-support stadig vigtigere.

Syntaks

domæne.dk.    IN    AAAA    2001:0db8:85a3:0000:0000:8a2e:0370:7334

Eksempler

example.dk.        AAAA    2001:db8:85a3::8a2e:370:7334
www.example.dk.    AAAA    2001:db8:85a3::8a2e:370:7335

Hvorfor implementere IPv6?

• Fremtidssikring: IPv4-adresser er ved at slippe op
• Performance: Nogle netværk har bedre IPv6-routing
• Mobile: Mange mobilnetværk bruger IPv6 primært
• SEO: Google crawler via IPv6 hvor muligt

CNAME Records: Aliaser

CNAME (Canonical Name) records opretter et alias fra ét domæne til et andet. I stedet for at pege på en IP, peger de på et andet domænenavn.

Syntaks

alias.domæne.dk.    IN    CNAME    target.example.com.

Praktiske eksempler

; www som alias til rod-domæne
www.example.dk.           CNAME    example.dk.

; CDN-integration
static.example.dk.        CNAME    d111111abcdef8.cloudfront.net.

; SaaS-services
mail.example.dk.          CNAME    ghs.googlehosted.com.
support.example.dk.       CNAME    example.zendesk.com.

CNAME-begrænsninger

Kan ikke bruges på apex (rod-domæne):

; UGYLDIGT - virker ikke
example.dk.    CNAME    other.com.

; GYLDIGT - kun på subdomæner
www.example.dk.    CNAME    other.com.

Kan ikke sameksistere med andre records:

; UGYLDIGT - MX og CNAME på samme navn
mail.example.dk.    CNAME    ...
mail.example.dk.    MX       ...

CNAME vs A-record

ALIAS/ANAME Records

Nogle DNS-udbydere tilbyder ALIAS eller ANAME records der fungerer som CNAME på apex-niveau. Dette er ikke en officiel DNS-standard men løser apex-begrænsningen.

MX Records: Email-routing

MX (Mail Exchanger) records fortæller hvor email til dit domæne skal leveres. De er essentielle for korrekt email-funktion.

Syntaks

domæne.dk.    IN    MX    prioritet    mailserver.

Eksempler for populære email-udbydere

Google Workspace:

example.dk.    MX    1     aspmx.l.google.com.
example.dk.    MX    5     alt1.aspmx.l.google.com.
example.dk.    MX    5     alt2.aspmx.l.google.com.
example.dk.    MX    10    alt3.aspmx.l.google.com.
example.dk.    MX    10    alt4.aspmx.l.google.com.

Microsoft 365:

example.dk.    MX    0    example-dk.mail.protection.outlook.com.

Egen mailserver:

example.dk.    MX    10    mail.example.dk.
example.dk.    MX    20    mail-backup.example.dk.

MX prioritet forklaret

Lavere tal = højere prioritet. Email forsøges leveret til:

1. Serveren med lavest prioritet først
2. Hvis den fejler, prøves næste
3. Flere servere med samme prioritet = load balancing

Best practices for MX

• Hav altid mindst 2 MX-records for redundans
• Sørg for at backup-servere faktisk kan modtage mail
• Test email-levering efter ændringer
• Koordinér med SPF-record (email-sikkerhed)

TXT Records: Tekstdata og verifikation

TXT-records indeholder arbitrær tekst og bruges til mange formål, særligt email-sikkerhed og domæneverifikation.

Syntaks

domæne.dk.    IN    TXT    "indhold af record"

SPF Record (email-sikkerhed)

SPF (Sender Policy Framework) forhindrer email-spoofing:

example.dk.    TXT    "v=spf1 include:_spf.google.com ~all"

Se vores guide til SPF, DKIM og DMARC for detaljeret opsætning.

DMARC Record

DMARC-records publiceres på _dmarc subdomænet:

_dmarc.example.dk.    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc@example.dk"

DKIM Records

DKIM-nøgler publiceres på et selector-subdomæne:

selector1._domainkey.example.dk.    TXT    "v=DKIM1; k=rsa; p=MIGfMA0G..."

Domæneverifikation

Mange services kræver TXT-record til verifikation:

; Google Search Console
example.dk.    TXT    "google-site-verification=abc123..."

; Microsoft 365
example.dk.    TXT    "MS=ms12345678"

; Facebook
example.dk.    TXT    "facebook-domain-verification=abc123..."

TXT Record begrænsninger

• Maks 255 tegn per streng (kan have flere strenge)
• Lange records (som DKIM) splittes automatisk
• For mange TXT-records kan give performance-problemer

NS Records: Navneservere

NS (Name Server) records definerer hvilke DNS-servere der er autoritative for dit domæne.

Syntaks

domæne.dk.    IN    NS    ns1.dns-udbyder.com.

Eksempler

; Cloudflare navneservere
example.dk.    NS    ann.ns.cloudflare.com.
example.dk.    NS    bob.ns.cloudflare.com.

; DK Hostmaster navneservere
example.dk.    NS    p.nic.dk.
example.dk.    NS    s.nic.dk.

Best practices for NS

• Minimum 2 navneservere (helst 3-4)
• Servere på forskellige netværk/lokationer
• Konsistent med det registreret hos registrar

SOA Record: Zone autoritet

SOA (Start of Authority) indeholder administrative information om DNS-zonen. Der er præcis én SOA per zone.

Syntaks

domæne.dk.    IN    SOA    primary-ns. admin-email. (
                            serial      ; Serienummer
                            refresh     ; Slave refresh interval
                            retry       ; Retry ved fejl
                            expire      ; Slave expiry
                            minimum     ; Negative cache TTL
                          )

Eksempel

example.dk.    SOA    ns1.example.dk. hostmaster.example.dk. (
                      2024010101    ; Serial (YYYYMMDDNN)
                      7200          ; Refresh (2 timer)
                      3600          ; Retry (1 time)
                      1209600       ; Expire (2 uger)
                      86400         ; Minimum TTL (1 dag)
                     )

SOA serienummer

Serienummeret skal øges ved hver ændring. Konvention: YYYYMMDDNN

• 2024010101 = Første ændring 1. januar 2024
• 2024010102 = Anden ændring samme dag

CAA Records: Certifikat-autorisation

CAA (Certificate Authority Authorization) specificerer hvilke CAs der må udstede SSL-certifikater for dit domæne.

Syntaks

domæne.dk.    IN    CAA    flags tag "value"

Eksempler

; Kun Let's Encrypt må udstede
example.dk.    CAA    0 issue "letsencrypt.org"
example.dk.    CAA    0 issuewild "letsencrypt.org"

; Rapportér overtrædelser
example.dk.    CAA    0 iodef "mailto:security@example.dk"

; Tillad flere CAs
example.dk.    CAA    0 issue "letsencrypt.org"
example.dk.    CAA    0 issue "digicert.com"

CAA tags

• issue: Tillad udstedelse af standard-certifikater
• issuewild: Tillad udstedelse af wildcard-certifikater
• iodef: Kontakt ved policy-overtrædelse

PTR Records: Reverse DNS

PTR (Pointer) records mapper IP-adresser til domænenavne - det modsatte af A-records. De administreres af IP-ejeren (typisk din hostingudbyder).

Hvorfor PTR er vigtigt

• Email-servere tjekker PTR for spam-filtering
• Diagnostik og logging
• Sikkerhedsverifikation

Anmod om PTR

Kontakt din hostingudbyder for at få opsat PTR der matcher dit domæne:

; Eksempel (administreres af IP-ejer)
34.216.184.93.in-addr.arpa.    PTR    mail.example.dk.

SRV Records: Service location

SRV (Service) records specificerer lokationen af specifikke services på dit domæne.

Syntaks

_service._protocol.domæne.dk.    IN    SRV    priority weight port target.

Eksempler

; Microsoft 365 services
_sip._tls.example.dk.           SRV    100 1 443 sipdir.online.lync.com.
_sipfederationtls._tcp.example.dk.    SRV    100 1 5061 sipfed.online.lync.com.

; Jabber/XMPP
_xmpp-client._tcp.example.dk.   SRV    5 0 5222 xmpp.example.dk.
_xmpp-server._tcp.example.dk.   SRV    5 0 5269 xmpp.example.dk.

TTL: Time To Live

TTL bestemmer hvor længe records må caches.

Anbefalede TTL-værdier

TTL strategi

1. Normal: Sæt høj TTL for stabile records
2. Før ændringer: Sænk TTL 48+ timer før planlagte ændringer
3. Efter ændringer: Vent med at hæve TTL til du er sikker på alt virker

DNS Record opsummeringstabel

Test dine DNS Records

Brug DomainiFys gratis scanner til at analysere dine DNS-records og få anbefalinger til forbedringer.

Scan dit domæne nu