DNSSEC
DNS, systemet, der oversætter navne som eksempel.com til IP-adresser, blev designet i 1983 uden godkendelse. Ethvert svar, der hævder at være fra et domænes autoritative server, blev accepteret. DNSSEC retter det ved at vedhæfte kryptografiske signaturer til hver DNS-post, hvilket lader klienter bekræfte, at svaret ikke er blevet manipuleret. Adoptionen har været langsom, men hvor den er implementeret, virker den.
Hele artiklens krop findes på engelsk nedenfor.
DNSSEC (Domain Name System Security Extensions) tilføjer kryptografiske signaturer til DNS-poster, så klienter kan verificere ægtheden og integriteten af DNS-svar. Uden DNSSEC kan en netværksangriber spoofe DNS-svar og omdirigere trafik til angriberkontrollerede servere - grundlaget for DNS-kapring. Med DNSSEC mislykkes falske svar signaturbekræftelse og afvises.
Hvad DNSSEC tilføjer
Fire nye registreringstyper:
- RRSIG — en signatur over et sæt poster. Hver signeret post har en tilsvarende RRSIG.
- DNSKEY — den offentlige nøgle, der bruges til at verificere RRSIG-signaturer for en zone.
- DS (Delegation Signer) — sidder i den overordnede zone og peger på den underordnede zone. Etablerer tillidskæden.
- NSEC/NSEC3 — beviser, at der IKKE findes et navn i zonen. Nødvendigt, fordi "dette navn ikke eksisterer" er også et svar, der skal godkendes.
Sådan fungerer verifikation
For at verificere IP-adressen for eksempel.com:
- Resolver-forespørgselsposten eksempel.com for A. Henter IP-adressen plus en RRSIG-signatur.
- Resolver queries example.com for sin DNSKEY (zone-signeringsnøglen, ZSK).
- Resolver verificerer RRSIG ved hjælp af ZSK.
- For at verificere den reparent zone for com-forespørgslerne for selve resolSKEY DS,. record of example.com.
- DS-posten indeholder en hash af example.com's DNSKEY, underskrevet af .com's nøgler.
- Dette går igen op til roden, hvis offentlige nøgle er hårdkodet i resolvere.
The end exemplet,com.com. slutter ved den originale A-post. Enhver manipulation på et hvilket som helst trin detekteres.
Nøgletyper og rotation
DNSSEC bruger to nøgletyper pr. zone:
- Zone-signeringsnøgle (ZSK). Signerer de faktiske poster, TXTA, osv.). Roteres ofte (måneder til et år), fordi den er brugt meget.
- Key-Signeringsnøgle (KSK). Signerer ZSK. Roteres sjældent, fordi det er ankerpunktet, som den overordnede zone refererer til. At rotere den kræver koordinering med registratoren for at opdatere DS-posten.
Roden KSK roteres cirka én gang hvert femte år. 2017-rotationen var den første nogensinde og krævede års forberedelse for at sikre, at resolvere over hele verden havde den nye offentlige nøgle.
Adoption
DNSSEC-vedtagelsen er ujævn:
- TLD-niveau: er de fleste større. .com, .org, .net, .gov, de fleste landekoder.
- Domæneniveau: Omtrent 5 % af .com-domæner har DNSSEC aktiveret fra 2026 — langsom vækst. XPLZ77ZXXsolver9PLZ78XPL store offentlige resolver9-niveau (1.1.1.1, 8.8.8.8, 9.9.9.9) valider DNSSEC. Det gør de fleste internetudbydere også. Dem, der ikke blot returnerer, hvad de får uden bekræftelse.
- Klientniveau: De fleste operativsystemer stoler på, at deres konfigurerede resolver validerer; de tjekker ikke signaturer selv. Nogle få applikationer og DNS-over-HTTPS-implementeringer udfører validering på klientsiden.
Hvorfor vedtagelse er langsom
Flere barrierer:
- Operationel kompleksitet. skal genereres på ny regelmæssigt. Fejlkonfiguration bryder domænet fuldstændigt (hver resolver returnerer SERVFAIL).
- Lstørre DNS-svar. Signerede svar er flere gange større end usignerede. Gammel DNS-infrastruktur antog, at svar ville passe i enkelte UDP-pakker; Underskrevne svar gør det ofte ikke, hvilket kræver TCP-faldback.
- Limiteret slutbrugerfordel. DNSSEC beskytter mod manipulation på DNS-laget, men ikke mod, at destinations-IP'en er ondsindet. De fleste brugere bemærker ikke, hvornår DNSSEC er eller ikke er der.
- Bedre alternativer til nogle brugstilfælde. Krypteret DNS (DoH, DoT, DNSCrypt) beskytter DNS-forespørgsler mod manipulation på stien, som adresserer meget af den samme trussel med mindre kompleksitet.
DNSSEC vs krypteret DNS
De to løser overlappende, men forskellige problemer:
- DNSSEC beviser, at svaret er autentisk og umanipuleret. Selve forespørgslen er stadig synlig for netværket.
- Encrypted DNS skjuler forespørgslen og svaret fra netværket, men beviser ikke, at svaret er autentisk - det stoler bare på den konfigurerede resolver.
Den stærkeste opsætning til at validere krypteret DNSSSEC. Skjul forespørgslen i transit, bekræft svaret kryptografisk. Cloudflare 1.1.1.1 og Google 8.8.8.8 over DoH giver begge i dag.
DANE: hvad DNSSEC muliggør
One downstream-teknologi DNSSEC låser op, er DANE (DNS-baseret autentificering af PLZ Entifikation)X PLZ Entification. DANE udgiver TLS-certifikatfingeraftryk i DNS, sikret af DNSSEC. En browser kan bekræfte et websteds certifikat ved at forespørge på DNS i stedet for udelukkende at stole på certifikatmyndigheder. Adoption er begrænset (anvendes mest til SMTP, ikke HTTPS, på grund af browserimplementeringspolitik).
Sådan kontrollerer man, om et domæne er DNSSEC-signeret
Kommandolinjetjek: dig +dnssec example.comXPLZ21ECs, hvis DNSS-signatur er enable. Onlineværktøjer som DNSSEC-Analyzer (Verisign Labs) viser den fulde kæde af tillid visuelt. Browserudvidelser kan markere DNSSEC-valideringsstatus pr. side.
Ofte stillede spørgsmål
- Har mit domæne brug for DNSSEC?
- Ikke strengt taget. Den beskyttelse, den giver, er meningsfuld, men delvis. For de fleste personlige websteder opvejer driftsomkostningerne ved at køre DNSSEC fordelene. For websteder, der håndterer finansielle transaktioner, offentlige tjenester eller mål af høj værdi, tilføjer DNSSEC plus DANE et værdifuldt defensivt lag.
- Vil DNSSEC forhindre alle DNS-angreb?
- Nej. DNSSEC forhindrer manipulation af DNS-svar på ledningen, men det forhindrer ikke: en ondsindet autoritativ server, der ligger med gyldige signaturer, overtagelse af registratorkonto (angriberen udgiver nye nøgler) eller angreb mod destinations-IP'en efter en legitim DNS-løsning. Det er et lag, ikke en komplet løsning.
- Hvorfor tjekker min browser ikke DNSSEC?
- Browsere delegerer DNSSEC-validering til den konfigurerede resolver. Hvis resolveren validerer og afviser dårlige svar, ser browseren dem aldrig. Der var forslag til validering på browsersiden, men de blev ikke vedtaget. Brug en validerende resolver (1.1.1.1, 9.9.9.9), og du får DNSSEC's fordele.
- Hvad sker der, hvis et DNSSEC-signeret domæne har et problem?
- Validering mislykkes, og de fleste resolvere returnerer SERVFAIL. Domænet ser ud til at være uopnåeligt. Dette er sket i produktionen (HBO Max's udfald i 2021 var en DNSSEC-fejlkonfiguration). Afvejningen: når DNSSEC fungerer, er det sikkert; når den går i stykker går den højlydt i stykker.
- Er DNSSEC det samme som DNS over HTTPS?
- Nej. DNSSEC tilføjer signaturer til DNS-svar for at bekræfte ægtheden. DNS over HTTPS (DoH) krypterer DNS-forespørgsler under overførsel. De er komplementære og bedst brugt sammen.