DNS er internettets adressebog. Det oversætter navne som example.com til IP-adresser og bærer de records, der stille styrer mailrouting, ejerskabsbeviser og hvilke certifikatudstedere der må udstede for dit domæne.

Næsten enhver webforespørgsel starter med et DNS-opslag, så en forkert konfigureret record bliver direkte til nedetid, langsom første byte, ødelagt e-mail eller en fejlet certifikatfornyelse. Denne side dækker alle relevante recordtyper og præcis hvad der går galt, når hver enkelt er forkert.

Sådan fungerer DNS-opslag

En resolver starter i rodzonen og følger en delegeringskæde ned til dit domænes autoritative nameservere og spørger så dem om den record, den skal bruge. Hvert trin kan caches, og hvor længe det bliver i cachen, styres af TTL.

Den praktiske konsekvens: du ændrer aldrig DNS globalt, du ændrer det ved kilden og venter på at caches udløber. Næsten ethvert "DNS virker ikke"-problem er i virkeligheden et cache-problem eller et delegeringsproblem.

A- og AAAA-records

En A-record peger et hostname på en IPv4-adresse. En AAAA-record gør det samme for IPv6 — samme rolle, andet adresserum, og navnet afspejler, at en IPv6-adresse er fire gange længere.

Når et hostname har begge, foretrækker dual-stack-klienter normalt IPv6 og falder kun tilbage til IPv4, hvis forbindelsen fejler.

Peger en A-record på en forældet IP, ender trafikken på en død server, den forkerte tenant eller en parkeringsside. En voksende del af mobilnetværk router over IPv6 som standard, og uden en AAAA-record presses de klienter gennem carrier-grade NAT med ekstra latency og forbindelsesfejl til følge.

Kør dig +short example.com A og bekræft, at hver returneret IP er en, du driver.
Udgiv en AAAA ved siden af — men først når host, load balancer og firewall alle accepterer IPv6. En udgivet AAAA, der peger på en server, som stille dropper IPv6, er værre end slet ingen record.
Hold A og AAAA rettet mod samme logiske tjeneste med samme TTL, så failover opfører sig forudsigeligt.
Flere A-records giver grov redundans, men er ikke en load balancer: klienter bliver ved med at bruge den IP, de har cachet.

CNAME-records

En CNAME peger ét hostname på et andet hostname, aldrig på en IP. Resolveren følger aliaset og bruger de A/AAAA-records, den finder på målet.

Sådan fungerer de fleste platformsintegrationer: du peger app.example.com på et leverandør-hostname, og de styrer IP'er, CDN-edges og certifikater bagved.

To begrænsninger vælter folk konstant:

Et hostname med en CNAME kan ikke bære nogen anden recordtype. Derfor kan du ikke lægge en CNAME på et domæne, der også skal have MX.
Et apex-domæne (example.com, uden subdomæne) kan normalt slet ikke bruge CNAME, medmindre din udbyder tilbyder ALIAS eller ANAME.

Undgå kæder — hver ekstra CNAME tilføjer et opslag og en fejlkilde mere.

MX-records

En MX-record (mail exchange) angiver de servere, der modtager e-mail for et domæne. Hver har en prioritet — lavere tal foretrækkes — og et hostname, der skal kunne slås op via A eller AAAA.

Manglende, forkerte eller forældede MX-records får indgående mail til at fejle stille eller bounce med kryptiske SMTP-fejl. Modtagere bruger også MX-data i spamvurdering: et domæne, hvis mail burde gå gennem en kendt udbyder, men pludselig peger et andet sted hen, er et svindelsignal.

Kør dig MX example.com og bekræft, at hvert hostname er en mailserver, du faktisk bruger.
Brug flere MX-records, eller en udbyder med indbygget failover, så ét nedbrud ikke bouncer mail.
Et MX-mål skal være et almindeligt hostname med sin egen A-record. At pege MX på en CNAME er ugyldigt jf. RFC 2181, og nogle modtagere afviser det direkte.

NS-records

NS-records angiver, hvilke nameservere der er autoritative for et domæne. De er særlige: de definerer, hvor resten af zonen bor.

Er NS-records forkerte, er domænet ganske enkelt uopnåeligt — web, mail, API'er og certifikatfornyelse stopper alt sammen, fordi ingen resolver kan finde den rigtige server at spørge. Fejlkonfiguration giver også det irriterende tilfælde, hvor nogle regioner ser et fungerende site, mens andre får SERVFAIL. Fordi NS styrer hele zonen, er det også et oplagt mål for hijacking.

List delegeringen fra forældrezonen med dig +trace example.com NS og bekræft, at den matcher recordsene inde i zonen. Uoverensstemmelse mellem forælder og barn er den klassiske årsag til sporadisk opslag.
Hav mindst to nameservere på forskellige netværk.
Hver NS-værdi skal være et hostname med en fungerende A-record — ikke en IP.
Regn med op til 48 timer, før caches udløber efter en ændring.

TXT-records

En TXT-record gemmer vilkårlig tekst under et hostname. Oprindeligt frie noter, men i dag bæreren af det meste metadata på domæneniveau: ejerskabsverifikation, e-mail-authentication-politik og servicespecifikke tokens. Ét hostname kan have mange.

TXT-records er måden, resten af internettet afgør, om dit domæne kan stoles på. SPF angiver hvilke servere der må sende mail for dig, DKIM-nøgler lader modtagere verificere signaturer, og DMARC fortæller indbakker hvad de skal gøre, når de fejler — alt sammen dækket under e-mail-authentication.

Kortlæg alle TXT på apex og på _dmarc, _domainkey og udbyderspecifikke subdomæner med dig TXT.
Brug præcis én SPF-record per domæne. Flere SPF-strenge er en automatisk permerror, og det er den mest udbredte e-mail-authentication-fejl der findes.
Hold SPF under grænsen på 10 DNS-opslag i RFC 7208. Overskrides den, fejler SPF — og fordi hvert include: kan indlejre flere, sprænger større organisationer grænsen uden at opdage det.
Udgiv en separat DKIM-selector per udbyder og rotér nøgler, når leverandører skifter.

CAA-records

En CAA-record (Certification Authority Authorization) angiver, hvilke certifikatudstedere der må udstede TLS-certifikater for dit domæne (RFC 8659). Offentlige CA'er er forpligtet til at tjekke den ved udstedelse. Findes der ingen CAA-record, må enhver CA udstede for dit navn.

CAA begrænser skadesomfanget ved en kompromitteret eller useriøs CA. Uden den kan en angriber, der narrer en hvilken som helst betroet udsteder, fremstille et gyldigt certifikat for dit domæne og aflytte trafik — selv med HSTS slået til.

Tilføj en record per tilladt udsteder: 0 issue "letsencrypt.org".
Styr wildcards separat med issuewild — 0 issuewild ";" forbyder dem helt.
Sæt 0 iodef "mailto:security@example.com" for at få besked om blokerede udstedelsesforsøg. Det er et reelt brugbart tidligt varsel om, at nogen forsøger at udgive sig for dig.
Læg den på apex; subdomæner arver, medmindre de har deres egen.

TTL og propagering

TTL (Time To Live) er en værdi i sekunder per record, der fortæller cachende resolvere, hvor længe de må beholde en record, før de spørger igen.

TTL styrer, hvor hurtigt internettet ser din ændring. Var TTL'en 86400, vil nogle klienter stadig slå den gamle IP op et helt døgn efter, du har skiftet. Det er det, folk mener med "at vente på at DNS propagerer" — der propagerer ikke noget, caches udløber bare.

Sænk TTL til 300 sekunder mindst 24-48 timer før en planlagt migrering. At sænke den samtidig med ændringen udretter intet, for resolvere sidder stadig på den gamle kopi med lang TTL.
Hæv den til 3600 eller 86400 igen, når tingene er stabile.
Undgå TTL'er under 30 sekunder, medmindre du reelt har brug for failover på det niveau — de fleste resolvere ignorerer dem alligevel.
Resolvere overholder ikke altid TTL strengt. ISP- og virksomhedscaches kan forlænge den.

DNSSEC

DNSSEC tilføjer kryptografiske signaturer til DNS-records (RRSIG), udgiver signeringsnøgler (DNSKEY) og forankrer tillid i forældrezonen (DS). En validerende resolver kan derefter bevise, at et svar kom uændret fra den autoritative nameserver.

DNSSEC krypterer ikke DNS-trafik. Det giver autenticitet og integritet, ikke fortrolighed.

Almindelig DNS er let at forfalske på fjendtlige netværk og er blevet misbrugt til cache poisoning, kaprede bank-sessioner og stille omdirigering. Uden DNSSEC kan en ondsindet resolver returnere en hvilken som helst IP for dit domæne, uden at brugeren kan se det.

Aktivér DNSSEC hos din DNS-udbyder, og udgiv derefter den resulterende DS-record hos din registrar. At springe det andet trin over er den sædvanlige grund til, at DNSSEC ser aktiveret ud, men intet validerer — tilliden når aldrig roden.
Verificér med dig +dnssec example.com og kig efter ad-flaget.
Test mod en validerende resolver; mange ISP-resolvere fjerner DNSSEC-data.
Planlæg KSK/ZSK-rollovers i god tid og bekræft, at din registrar accepterer opdaterede DS-records — en forkert udført rollover tager hele domænet ned, ikke bare én record.

DNS-records forklaret: A, AAAA, CNAME, MX, NS, TXT, CAA