När jag arbetar med DNSSEC försöker jag börja i den faktiska tillgången, datan och förändringen som ska skyddas. DNSSEC skyddar autenticiteten i DNS-data genom signerade zoner, men det krypterar inte frågorna och stoppar inte alla typer av DNS-missbruk.
DNSSEC i praktiken
Första byggstenen: DS-posten kopplar parent-zonen till barnzonens DNSKEY. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: RRSIG används för att verifiera signerade records. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: Validerande resolvers kan skilja mellan säkert svar och trasig kedja. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: Nyckelrotation kräver ordning så att gammal och ny tillit överlappar korrekt. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Från nuläge till verifierad kontroll
- Kartlägg registrar, DNS-operatör och vem som äger nyckelrotationen.
- Aktivera signering och verifiera zonen före DS-publicering.
- Publicera DS först när rätt DNSKEY syns externt.
- Övervaka valideringsfel och utgångna signaturer.
- Dokumentera rollback för DS vid fel.
För DNSSEC håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Exempel från ett driftperspektiv
Det mest riskfyllda steget är ofta kopplingen hos parent-zonen. Jag vill därför verifiera den signerade barnzonen först och behandla DS-ändringen som en separat change med tydlig efterkontroll.
Fallgropar jag försöker undvika
- Att publicera fel DS och göra en signerad zon otillgänglig för validerande klienter.
- Att blanda ihop DNSSEC med krypterad DNS.
- Att rotera nycklar utan att ta hänsyn till TTL och cache.
Kontrollpunkter
För DNSSEC vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- Kedjan validerar från root till zonen.
- Både positiva och negativa svar valideras.
- Extern övervakning larmar innan signaturer eller nycklar blir ogiltiga.
Ett negativt test hör också till DNSSEC: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
DNSSEC – vad det skyddar, vad det inte skyddar och hur man felsöker handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.