Vad är DNSSEC?
DNSSEC (Domain Name System Security Extensions) lägger till digitala signaturer i DNS-postmängder. En validerande resolver kan använda giltiga signaturer och en förtroendekedja för att autentisera signerade data och upptäcka obehöriga ändringar. DNSSEC krypterar inte DNS-frågor eller svar.Så fungerar DNSSEC
DNSSEC bygger en kedja av förtroende från rotzonen via en toppdomän till den signerade domänen. Zonens publika nycklar, DS-posten i föräldrazonen och RRSIG-signaturerna måste passa ihop. En resolver validerar varje länk och markerar ett giltigt svar som autentiserat. Vid ogiltig signatur bör den avvisa svaret i stället för att leverera potentiellt manipulerad information.
Förtroendekedja (exempel med separata KSK- och ZSK-nycklar):
Rotzon (.)
├── Rotens KSK (trust anchor) signerar rotens DNSKEY RRset
└── Rotens ZSK signerar rotzonens auktoritativa RRset, inklusive DS RRset på föräldrasidan för .com
└── DS-digesten matchar .com KSK
├── .com KSK signerar .com DNSKEY RRset
└── .com ZSK signerar auktoritativa RRset i .com-zonen, inklusive DS RRset på föräldrasidan för example.com
└── DS-digesten matchar example.com KSK
├── example.com KSK signerar example.com DNSKEY RRset
└── example.com ZSK signerar auktoritativa RRset i example.com
Resolvern validerar signaturer och DS-digester med utgångspunkt i rotens trust anchor
DNSSEC-posttyper
| Post | Syfte | Beskrivning |
|---|---|---|
| RRSIG | Signatur | Kryptografisk signatur för varje postmängd |
| DNSKEY | Publik nyckel | Zonens publika signeringsnycklar (KSK och ZSK) |
| DS | Delegation Signer | Hash av barndomänens KSK i föräldrazonen |
| NSEC/NSEC3 | Autentiserad nekad existens | Bevisar att en post inte finns |
Nyckeltyper
| Nyckel | Syfte | Rotationsfrekvens |
|---|---|---|
| KSK (Key Signing Key) | Signerar DNSKEY-poster | Policyberoende; se anteckningen nedan |
| ZSK (Zone Signing Key) | Signerar andra auktoritativa RRset i zonen; delegeringens NS- och glue-RRset i föräldrazonen är osignerade ([RFC 4035 §2.2](https://www.rfc-editor.org/rfc/rfc4035.html#section-2.2)) | Policyberoende; se anteckningen nedan |
Rotationstidpunkten beror på KSK-nyckelns roll och operatörens policy. För en KSK med en DS-post i föräldrazonen beskriver [RFC 6781 §3.3](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3) ett år som en rimlig period när regelbunden rotation väljs. En KSK som används som trust anchor kräver samordning med validerande resolvrar och kan ha en betydligt längre effektivitetsperiod ([RFC 6781 §3.2.2](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.2.2)).
ZSK-nyckelns livslängd beror också på operatörens policy och villkoren för rotationen. För en ZSK som lagras online i en miljö med förhöjd risk anger [RFC 6781 §3.3](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3) att en planerad livslängd på en månad kan vara rimlig. Det är villkorad vägledning, inte ett universellt intervall: TTL-värden för DNSKEY-poster och signaturer, spridningen av zonändringar och hur länge signaturer från den nyckel som tas ur bruk kan finnas kvar i resolvercacheminnen påverkar tidpunkten för rotationen ([RFC 7583 §3.2.1](https://www.rfc-editor.org/rfc/rfc7583.html#section-3.2.1)).
KSK skyddar övergången mellan zonen och dess publika nycklar, medan ZSK normalt signerar den övriga zoninformationen. Rutinerna för generering, lagring, åtkomst och rotation måste vara dokumenterade.
KSK-rotationen i DNS-roten den 11 oktober 2026
ICANN anger att rotationen av DNS-rotens KSK sker den 11 oktober 2026. Kontrollera att din DNSSEC-validerande resolver har KSK-2024 (nyckeltagg 38696) inlagd i sin trust anchor-konfiguration; utgå inte från att automatiska uppdateringar av trust anchor har fungerat. Om nyckeln saknas, kontrollera att automatiska uppdateringar är aktiverade och följ instruktionerna från resolverleverantören. Se [ICANN:s aktuella vägledning om rotation av DNS-rotens KSK](https://www.icann.org/resources/pages/ksk-rollover-en) för mer information.
DNSSEC-validering
1. Klienten frågar en resolver efter A-posten för example.com.
2. Resolvern hämtar A-posten och dess RRSIG-signatur.
3. Resolvern hämtar DNSKEY för att kontrollera RRSIG.
4. Resolvern validerar DS-posten mot DNSKEY.
5. Kedjan fortsätter till roten och varje nivå kontrolleras.
6. Om alla signaturer är giltiga är svaret autentiserat.
Validering måste testas från flera resolvrar. Internetstiftelsen beskriver DNSSEC som ett sätt att avgöra om informationen kommer från rätt källa och om den ändrats under överföringen.
Vad DNSSEC-validering kan hjälpa till att upptäcka
Dessa kontroller förutsätter signerade RRset och en validerande resolver med en intakt förtroendekedja. Osignerade eller osäkra data kan inte autentiseras.
| Hot | Exempel | DNSSEC-skydd |
|---|---|---|
| Cacheförgiftning | Förfalskade DNS-data läggs in i resolverns cache | En validerande resolver kan avvisa data som inte klarar signatur- eller kedjevalidering. |
| Manipulering av DNS-svar | En signerad DNS-postmängd ändras under överföringen | Ändrade data klarar inte signaturverifieringen. |
| DNS-förfalskning | Ett förfalskat svar lämnas för en signerad zon | En validerande resolver kan avvisa ett svar som inte klarar valideringen. |
Hänsyn vid införande
- Prestanda: Signaturer gör svaren större, ofta omkring 1 000–4 000 byte jämfört med omkring 100 byte.
- Nyckelhantering: Nycklar måste genereras, lagras och roteras säkert.
- Zonsignering: Zonen måste signeras om när poster ändras.
- Resolverstöd: Klienterna behöver resolvrar som validerar DNSSEC.
Planera för nyckelrotation, återställning, övervakning av RRSIG:s giltighet och hantering av förlorade eller felaktiga DS-poster innan DNSSEC aktiveras.
Bästa praxis
1. Välj en DNSSEC-signeringsalgoritm: [IANA:s DNSSEC-algoritmregister](https://www.iana.org/assignments/dns-sec-alg-numbers) rekommenderar ECDSAP256SHA256 (algoritm 13) för signering och validering. ECDSAP384SHA384 (14) kan passa för tillämpningar som kräver 192-bitars kryptografisk styrka; kontrollera att resolverprogramvaran stöder algoritmen innan du byter ([RFC 9904](https://www.rfc-editor.org/rfc/rfc9904.html), [RFC 8624 §3.1](https://www.rfc-editor.org/rfc/rfc8624.html#section-3.1)).
2. Automatisera nyckelrotation: Använd verktyg som OpenDNSSEC för nycklarnas livscykel.
3. Övervaka utgång: RRSIG-signaturer har giltighetsperioder och får inte löpa ut.
4. Testa före driftsättning: Validera zonen med verktyg som dnsviz.net.
5. Planera för nödlägen: Dokumentera procedurer för nyckelbyte och återställning.
När en validerande resolver verifierar kedjan autentiserar DNSSEC ursprunget till och integriteten hos signerade DNS-data. DNSSEC fastställer inte att en webbplats eller server på den returnerade adressen är tillförlitlig.