DNSSEC: Definition, hvordan det fungerer, og hvorfor det er vigtigt

Domænenavnesystemet DNS fungerer som internettets telefonbog og oversætter menneskeligt læsbare navne til IP-adresser milliarder af gange om dagen. DNS-databasen gemmer kritiske DNS-poster som IP-adresser og domænealias, hvilket gør den til et mål for cybertrusler. Men denne kritiske infrastruktur blev designet i 1980’erne uden indbygget sikkerhed. Traditionel DNS-validering baserede sig på at matche den samme IP-adresse for svar, hvilket er usikkert, fordi IP-adresser kan forfalskes. DNSSEC findes for at rette op på dette fundamentale hul ved at tilføje kryptografisk verifikation til et system, der oprindeligt fungerede udelukkende på basis af tillid.

DNSSEC i en nøddeskal

Domain Name System Security Extensions, almindeligvis kendt som DNSSEC, står for DNS Security Extensions og er et sæt IETF-protokolspecifikationer, der tilføjer kryptografiske signaturer til DNS-data. Disse signaturer gør det muligt for DNS-resolvere at verificere, at de oplysninger, de modtager, rent faktisk kommer fra den autoritative kilde og ikke er blevet ændret undervejs.

Det centrale problem, som DNSSEC løser, er ligetil: Uden DNSSEC kan angribere lægge falske DNS-svar ind i resolverens cache. Dette angreb, kendt som DNS-cache poisoning, omdirigerer brugere til ondsindede websteder uden deres viden. DNSSEC forhindrer dette ved at muliggøre autentificering af dataoprindelse og sikre integriteten af DNS-poster gennem digitale signaturer, brug af offentlig nøglekryptografi og krav om omhyggelig DNS-zone-nøglehåndtering for at forhindre efterligning og dataforfalskning.

Internet Engineering Task Force (IETF) standardiserede DNSSEC gennem en række RFC’er i begyndelsen af 2000’erne, herunder RFC 4033, 4034 og 4035. Den største milepæl i implementeringen kom i juli 2010, da ICANN underskrev DNS-rodzonen og etablerede et globalt tillidsanker, der gjorde praktisk DNSSEC-implementering mulig på verdensplan.

Det er vigtigt at forstå, hvad DNSSEC gør og ikke gør. DNSSEC autentificerer DNS-data og bekræfter, at A-, AAAA-, MX- og TXT-poster er ægte og uændrede. Men det krypterer ikke DNS-forespørgsler eller -svar. Din DNS-trafik forbliver synlig for alle, der kan observere den. Til kryptering har du brug for supplerende protokoller som DNS over TLS eller DNS over HTTPS.

DNSSEC forhindrer heller ikke alle angreb mod DNS-infrastrukturen. Volumetriske DDoS-angreb kan stadig overvælde DNS-servere uanset signering. Og DNSSEC kan ikke forhindre brugere i at besøge lovligt registrerede phishing-domæner, der tilfældigvis ser overbevisende ud.

Implementering af DNSSEC kan være kompleks på grund af behovet for nøglehåndtering og etablering af en tillidskæde. En vellykket DNSSEC-implementering kræver, at den overordnede zone og alle zoner i kæden også er signeret.

De fleste topdomæner understøtter DNSSEC i dag – over 1.400 TLD’er er underskrevet ifølge ICANN-data. Men udbredelsen af domæner på andet niveau fortæller en anden historie. Kun omkring 1-2 % af .com-zonerne har DNSSEC aktiveret, mens landekode-TLD’er som .nl (Holland) og .se (Sverige) har en signeringsgrad på over 90 % på grund af obligatoriske politikker.

Hvorfor skal du bekymre dig om det? Fordi uden DNSSEC er alle DNS-forespørgsler, som din organisation foretager, sårbare over for lydløs manipulation. En angriber, der forgifter din resolvers cache, kan omdirigere dine medarbejdere til websteder, der indsamler legitimationsoplysninger, eller opsnappe e-mailleverancer – alt sammen uden at udløse nogen åbenlyse advarsler.

Hvordan DNS og DNSSEC passer sammen

Før vi dykker dybere ned i DNSSEC, skal vi kort opsummere, hvordan domænenavnesystemet fungerer i dag. Når du skriver en URL i din browser, kontakter din computers stub resolver en rekursiv DNS-resolver – ofteleveret af din internetudbyder, dit virksomhedsnetværk eller en offentlig tjeneste som Googles 8.8.8.8 eller Cloudflares 1.1.1.1. DNS-resolveren behandler DNS-forespørgsler ved at følge kæden af servere for at hente den korrekte IP-adresse, hvilket sikrer en effektiv og præcis opløsning.

Overvej at løse www.example.com. Den rekursive DNS-resolver forespørger først en af de 13 logiske rod-DNS-navneservere og beder om oplysninger om .com. Rodserveren svarer med en henvisning til .com TLD-serverne, der drives af Verisign. Derefter spørger resolveren .com-serverne om example.com og modtager endnu en henvisning til example.com’s autoritative navneserver. Til sidst spørger resolveren den autoritative server og får den faktiske A-post, der indeholder IP-adressen for www.example.com.

Inden for dette hierarkiske system arbejderforskellige DNS-komponenter – såsom ressourceposter, autoritative navneservere og zonesigneringsnøgler– sammen om at administrere, kontrollere og sikre hver DNS-zone.

Dette elegante, hierarkiske system blev defineret i RFC 1034 og 1035 tilbage i 1987. Hvad er problemet? Den klassiske DNS-protokol blev designet uden stærk autentificering. Svarene blev primært valideret ved at matche kilde-IP-adresser og 16-bit transaktions-ID’er – etsystem, som angribere lærte at udnytte.

Kaminsky-sårbarheden fra 2008 viste, hvor sårbart dette design var. Sikkerhedsforskeren Dan Kaminsky viste, at angribere med stor sandsynlighed kunne indsprøjte falske svar i resolver-cacher ved at oversvømme dem med gæt i løbet af et enkelt forespørgselsvindue. Denne afsløring førte til nødrettelser i hele branchen og fremskyndede DNSSEC-udrulningen betydeligt på verdensplan.

DNSSEC integreres som et udvidelseslag, der omslutter eksisterende DNS uden at ændre kerneforespørgsels-/responsmodellen. Usignerede zoner fungerer fortsat normalt for ikke-validerende resolvere. Validerende resolvere udfører blot yderligere kryptografiske kontroller af signerede zoner. Denne bagudkompatibilitet var afgørende for en gradvis indførelse i hele DNS-navneområdet.

Centrale DNSSEC-koncepter og recordtyper

DNSSEC introducerer flere nye DNS-ressourceposttyper, som arbejder sammen om at skabe en verificerbar tillidskæde. At forstå disse optegnelser og deres forhold er vigtigt for alle, der arbejder med signerede zoner.

Den grundlæggende enhed i DNSSEC er ressourcepostsættet eller RRSet. Dette er en gruppering af DNS-poster, der deler samme navn, type og klasse. I stedet for at underskrive individuelle poster underskriver DNSSEC hele RRSets. Denne tilgang sikrer atomar integritet – du kan ikke manipulere med en post i et sæt uden at ugyldiggøre signaturen for dem alle.

RRSIG-posten indeholder en digital signatur, der dækker et RRSet. Hver ressourcepostsignatur oprettes ved hjælp af zonens private nøgle og indeholder metadata som underskriverens navn, gyldighedsperiode og den anvendte algoritme. Resolvere verificerer disse signaturer ved at genberegne en hash af RRSet-dataene og sammenligne den med den kryptografiske signatur.

DNSKEY-posten offentliggør den offentlige nøgle, der bruges til at verificere signaturer. Disse poster vises i zonens top (som example.com.) og indeholder flag, der angiver nøglens rolle. En flagværdi på 256 angiver en zonesigneringsnøgle, mens 257 angiver en nøglesigneringsnøgle.

DS-record, eller delegation signer record, skaber forbindelsen mellem forældre- og børnezoner. Den gemmes i den overordnede zone og indeholder et kryptografisk hash af den underordnede zones offentlige nøgle. For eksempel er DS-posten for example.com gemt i .com-zonen, hvilket gør det muligt for opløsere at kontrollere, at example.com’s DNSKEY-post er autentisk. Hver zones offentlige nøgle er signeret af den overordnede zones private nøgle, hvilket er afgørende for at etablere tillidskæden i DNSSEC. Denne proces sikrer, at tilliden overføres fra den overordnede til den underordnede zone, så der dannes et sikkert og verificerbart hierarki.

NSEC- og NSEC3-poster muliggør autentificeret afvisning af eksistens. Når en DNS-forespørgsel beder om et navn, der ikke findes, beviser disse poster, at navnet virkelig ikke findes – og forhindrer angribere i at hævde, at ikke-eksisterende navne er ægte. NSEC kæder eksisterende navne i sorteret rækkefølge, mens NSEC3 bruger kryptografisk hashede postnavne for at forhindre nem opremsning af zoneindhold.

CDS- og CDNSKEY-poster understøtter automatiseret nøglehåndtering. Disse gør det muligt for underordnede zoner at signalere opdaterede DS- eller DNSKEY-oplysninger til overordnede zoner, hvilket reducerer den manuelle koordinering, der traditionelt kræves med registratorer.

Adskillelsen mellem zonesigneringsnøgle (ZSK) og nøglesigneringsnøgle (KSK) fortjener særlig opmærksomhed. ZSK’en signerer almindelige zonedata (A, AAAA, MX records), mens KSK’en kun signerer selve DNSKEY RRSet. Denne adskillelse gør det muligt for operatørerne at rotere ZSK’en ofte, mens de holder den mere stabile KSK – og dens tilknyttede DS-post i moderzonen – uændret.

Navnesystemets sikkerhedsudvidelser

Name System Security Extensions (NSSE) repræsenterer et omfattende sæt af protokoller og standarder, der er designet til at styrke sikkerheden i domænenavnesystemet (DNS). Kernen i NSSE er DNSSEC, som bruger digitale signaturer og public key-kryptografi til at autentificere DNS-data og garantere deres integritet. Hovedformålet med disse systemsikkerhedsudvidelser er at forsvare sig mod trusler som DNS-spoofing og DNS-cache poisoning – angreb,der kan manipulere DNS-data og omdirigere brugere til falske websteder.

Ved at udnytte navnesystemets sikkerhedsudvidelser kan domæneejere sikre, at de DNS-data, der er knyttet til deres domæner, er både autentiske og uændrede, når de rejser på tværs af internettet. Dette opnås ved brug af public key-infrastruktur, hvor hver signeret zone udgiver en offentlig nøgle, som resolvere bruger til at verificere digitale signaturer på DNS-poster. Resultatet er, at brugere og applikationer kan stole på, at de oplysninger, de modtager fra domænenavnesystemet, er legitime, hvilket er med til at opretholde brugernes tillid og beskytte mod en lang række cybertrusler.

Sådan fungerer DNSSEC-validering fra ende til anden

DNSSEC-validering følger DNS-opløsningsstien og bygger verifikation fra et kendt udgangspunkt, der kaldes et tillidsanker. For de fleste resolvere er dette anker rodzonens KSK, der distribueres via IANA og opdateringer af resolversoftware. Når en validerende rekursiv resolver håndterer en forespørgsel på et signeret domæne, udfører den kryptografisk verifikation på hvert trin i DNS-hierarkiet. Resolveren har allerede tillid til root DNSKEY. Ved hjælp af denne nøgle verificerer den rodzonens RRSIG, der dækker DS-posten for TLD’et (som .com). Derefter henter den .com’s DNSKEY og kontrollerer, at den matcher DS-hash’en. Denne proces fortsætter ned til måldomænet.

Overvej at spørge www.example.com i et fuldt signeret miljø. Resolveren verificerer:

• Roots DNSKEY (betroet anker) underskriver .com’s DS-post
• .com’s DNSKEY matcher DS-hash’en og signerer eksempel.com’s DS-post
• example.com’s DNSKEY matcher dens DS og signerer A-recorden for www.

Det skaber en ubrudt tillidskæde fra roden til den ønskede DNS-post. Enhver uoverensstemmelse – en ugyldig signatur, udløbet RRSIG eller DS/DNSKEY-hashfejl – bryder kæden.

Du kan observere valideringsfejl ved hjælp af testdomæner som dnssec-failed.org, der med vilje er fejlkonfigureret af ICANN. Validerende resolvere returnerer SERVFAIL for dette domæne og blokerer helt for adgang. For brugere bag ikke-validerende resolvere (stadig ca. 70 % på verdensplan) løses domænet normalt – hvilket viser hullet i den nuværende implementering.

DNSSEC ændrer ikke applikationsprotokoller som HTTP eller SMTP. Det sikrer blot, at IP-adressen og andre DNS-data, som programmerne modtager, er autentiske og uændrede. Browseren opretter stadig en HTTPS-forbindelse på normal vis; DNSSEC garanterer bare, at svarene på DNS-forespørgslerne peger på den legitime server.

Ved autentificeret afvisning af eksistens beviser NSEC- eller NSEC3-poster, at et forespurgt navn eller en type ikke findes. Resolveren modtager et kryptografisk signeret bevis, der viser, hvilke navne der findes i zonen, hvilket gør det muligt at bekræfte det hul, hvor det forespurgte navn ville optræde.

DNSSEC Resource Records i praksis

Lad os se nærmere på de vigtigste DNSSEC-relaterede DNS-posttyper.

RRSIG-poster genereres ved hjælp af zonens private nøgle – typisk ZSK’en for almindelige poster. Hver signatur specificerer signeringsalgoritmen (f.eks. ECDSAP256SHA256), antallet af labels i det signerede navn, den oprindelige TTL og tidsstempler for start og udløb. Disse tidsstempler er kritiske: Resolvere afviser signaturer uden for deres gyldighedsvindue, som typisk er sat til 30 dage. Zoneoperatører skal opsige poster inden udløb for at undgå valideringsfejl.

DNSKEY-poster vises i zonens top og kan indeholde flere nøgler i overgangsperioder. Flagfeltet skelner mellem nøgleroller: 257 angiver en KSK med SEP-bitten (Secure Entry Point) indstillet, mens 256 angiver en ZSK. Nøgletagget – en 16-bit identifikator beregnet ud fra nøgledataene – hjælper resolvere med hurtigt at matche DNSKEY-poster med tilsvarende DS-poster.

DS-poster i den overordnede zone indeholder et hash af den underordnede zones KSK. En typisk DS-record indeholder nøgletag, algoritmenummer, fordøjelsestype (almindeligvis SHA-256) og selve fordøjelsen. Under DNSSEC-validering henter opløsere barnets DNSKEY, beregner hashen og sammenligner. En uoverensstemmelse giver en BOGUS-status, hvilket medfører, at valideringen mislykkes.

NSEC-poster kæder sig gennem zonens navne i kanonisk sorteret rækkefølge. Hver NSEC peger på det næste eksisterende navn og viser de recordtyper, der findes ved det navn. Dette beviser ikke-eksistens, men udsætter zoneindholdet for “zonevandring” – angribere kan opregne hvert navn ved at følge kæden.

NSEC3 løser problemet med zonevandring ved at hashe navne med et salt og et antal iterationer, før de kædes sammen. Selvom dette forhindrer triviel opremsning, kan målrettede angribere stadig knække forudsigelige navne offline. Opt-out-flaget tillader usignerede delegeringer inden for ellers signerede zoner, hvilket er nyttigt for store zoner med mange usignerede subdomæner.

CDS- og CDNSKEY-poster afspejler DS- og DNSKEY-formater, men offentliggøres i selve den underordnede zone. Operatører af overordnede zoner kan forespørge på disse poster for automatisk at opdatere delegationssigneringsposter, hvilket strømliner nøgleoverførsler og den første DNSSEC-implementering.

Gruppering af DNS-poster

Et grundlæggende aspekt af DNSSEC-implementeringen er grupperingen af DNS-poster i Resource Record Sets (RRSets). Et RRSet er en samling af DNS-poster, der har samme navn og type i en zone. I stedet for at signere hver enkelt record signerer DNSSEC hele RRSet med en enkelt RRSIG-record. Denne tilgang strømliner processen med at underskrive og validere DNS-data, hvilket gør den mere effektiv for både domæneejere og validerende opløsere.

Gruppering af DNS-poster i RRSets forenkler ikke kun implementeringen af DNSSEC, men gør det også nemmere at administrere DNS-infrastrukturen. Når der foretages en ændring af en post i et RRSet, signeres hele sættet igen, hvilket sikrer, at integriteten og autenticiteten af alle relaterede DNS-data bevares. For domæneejere betyder det mindre kompleksitet i håndteringen af signaturer og et mere robust forsvar mod manipulation eller uautoriserede ændringer af deres DNS-poster. I sidste ende er gruppering af DNS-poster en bedste praksis, der understøtter skalerbarheden og sikkerheden i moderne DNS-infrastruktur.

Zonesigneringsnøgle, signeringstilstande og nøglehåndtering

DDNSSEC-nøglehåndtering er centreret om to forskellige roller. Zonesigneringsnøglen (ZSK) håndterer den daglige signering af zonedata – A, AAAA, MX, TXT og andre almindelige poster. Nøglesigneringsnøglen (KSK) har en mere begrænset, men kritisk funktion: Den signerer kun DNSKEY RRSet og skaber det betroede link til moderzonens DS-post.

Operatørerne adskiller disse roller af gode grunde. Den private ZSK-nøgle bruges ofte og er udsat for større risiko, så ved at rotere den hver 30.-90. dag begrænser man den potentielle skade ved kompromittering. KSK’en ændres sjældent – årligt eller sjældnere– fordihver rotation kræver opdatering af DS-posten i den overordnede zone, hvilket typisk involverer koordinering med registratoren.

Der findes tre primære signeringsmetoder til DNSSEC-implementering:

• Offline-signering: Zonen signeres på en luftovervåget maskine eller HSM, hvorefter den signerede zonefil overføres til autoritative servere. Bedst til statiske zoner, hvor sikkerhed vejer tungere end driftskomfort.
• Centraliseret online-signering: En dedikeret signeringstjeneste modtager usignerede opdateringer og signerer dem, før de distribueres til autoritative DNS-servere. Afbalancerer sikkerhed med understøttelse af dynamiske opdateringer.
• On-the-fly-signering: Autoritative servere genererer DNSSEC-signaturer i realtid, når der kommer DNS-anmodninger. Passer til meget dynamiske zoner, men øger risikoen for nøgleeksponering, hvis serverne kompromitteres.

Key rollover kræver omhyggelig timing for at undgå at bryde tillidskæden. Standardmetoden udgiver nye nøgler på forhånd: Tilføj den nye nøgle til DNSKEY RRSet, vent på, at cachen udløber (typisk to TTL-perioder), og træk derefter den gamle nøgle tilbage. Ved KSK-overførsler skal den nye DS også spredes gennem den overordnede zone, før den gamle KSK fjernes.

KSK-overgangen i 2018 illustrerede, hvad der stod på spil. På trods af omfattende forberedelser lykkedes det ikke for ca. 0,3 % af resolverne at opdatere deres tillidsankre, hvilket resulterede i midlertidige SERVFAIL-svar. For en enkelt zone kan sådanne fejl virke mindre – mende tager effektivt et domæne offline for de berørte brugere.

Underskriver af delegation

Delegation Signer (DS)-posten er en hjørnesten i DNSSEC’s tillidskæde, der forbinder sikkerheden i en underordnet zone med dens overordnede zone i DNS-hierarkiet. DS-posten indeholder en kryptografisk hash-version af den underordnede zones Key Signing Key (KSK), og den offentliggøres i den overordnede zone. Det gør det muligt for rekursive opløsere at kontrollere, at DNSKEY-posten, der præsenteres af den underordnede zone, er autentisk og ikke er blevet manipuleret med.

Ved at etablere denne forbindelse gør DS-posten det muligt for domæneejere at udvide tilliden fra den overordnede zone ned til deres egne DNS-data og sikre, at hvert trin i opløsningsprocessen er valideret. Denne mekanisme er afgørende for at opretholde integriteten i hele DNS-infrastrukturen, da den forhindrer angribere i at indsætte falske DNS-data på et hvilket som helst tidspunkt i kæden. For domæneejere er korrekt konfiguration af delegationssigneringsposter et kritisk skridt i implementeringen af DNSSEC og beskyttelsen af deres domæner mod DNS-baserede angreb.

Fordele og begrænsninger ved DNSSEC

DNSSEC’s primære værdi er at forsvare sig mod DNS-cacheforgiftning og DNS-spoofing-angreb. Ved kryptografisk at bevise svarets ægthed forhindrer det angribere i lydløst at omdirigere brugere til phishing-sider eller opsnappe e-mails via falske MX-poster. Kaminsky-sårbarheden i 2008 viste, hvor ødelæggende sådanne angreb kunne være; DNSSEC gør dem grundlæggende ineffektive mod signerede zoner.

Ud over den grundlæggende beskyttelse giver DNSSEC mulighed for avancerede sikkerhedsapplikationer. DANE (DNS-Based Authentication of Named Entities) giver domæneejere mulighed for at offentliggøre TLS-certifikatoplysninger direkte i DNS ved hjælp af TLSA-poster. Dette kan verificere certifikater for SMTP-servere eller webtjenester uden udelukkende at stole på traditionelle certifikatmyndigheder. Sådanne applikationer kræver autentificerede DNS-data – præcis hvad DNSSEC giver.

Begrænsningerne er lige så vigtige at forstå:

• Ingen fortrolighed: DNSSEC autentificerer, men krypterer ikke. DNS-forespørgsler og svar på DNS-forespørgsler forbliver synlige for observatører. Kryptering kræver DNS over TLS eller DNS over HTTPS.
• Ingen DDoS-beskyttelse: DNSSEC kan ikke stoppe volumetriske angreb mod DNS-infrastruktur. Faktisk kan større signerede svar potentielt forværre forstærkningsangreb.
• Ingen beskyttelse mod trusler, der ser legitime ud: DNSSEC kan ikke forhindre typosquatting eller brugere, der stoler på vildledende domænenavne, som er lovligt registreret og korrekt signeret.

Overvejelser om ydeevne omfatter betydeligt større DNS-svar – signaturertilføjer ca. 500 byte per RRSet. Dette udløser nogle gange TCP fallback (hvilket øger ventetiden) og øger båndbreddeforbruget. Åbne resolvere med DNSSEC kan forstærke refleksionsangreb med faktorer på 50x eller mere sammenlignet med almindelig DNS.

På trods af disse afvejninger anbefaler sikkerhedsorganisationer, herunder ICANN og NIST, DNSSEC til domæner af høj værdi. Overheadet er reelt, men for offentligt tilgængelige tjenester, hvor DNS-spoofing kan muliggøre alvorlige angreb, retfærdiggør beskyttelsen kompleksiteten.

Risici, udfordringer og hvorfor udbredelsen stadig er ujævn

DNSSEC introducerer operationelle risici, som forklarer en stor del af tøven med at tage det i brug. Fejlkonfigurationer – udløbne signaturer, DS/DNSKEY-misforhold eller ugyldige signaturkæder – forårsager valideringsfejl. For de ca. 30 % af brugerne, der står bag validerende resolvere, holder en fejlkonfigureret zone simpelthen op med at virke. Der er ingen graciøs nedbrydning; forespørgsler returnerer SERVFAIL.

Flere barrierer bremser udbredelsen af DNSSEC:

• Koordinering mellem flere parter: Signering kræver afstemning mellem domæneejere, registratorer og DNS-hostingudbydere. DS-poster skal flyde gennem registrator-systemer for at nå den overordnede zone.
• Huller i ekspertisen: Mange organisationer mangler DNSSEC-erfaring. Frygten for at forårsage udfald på grund af fejlkonfiguration afholder dem fra at starte.
• Ældre infrastruktur: Nogle virksomhedsmiljøer omfatter resolvere eller apparater, der ikke fuldt ud understøtter DNSSEC-validering, hvilket skaber kompatibilitetsproblemer.

Statistikkerne over udbredelsen viser ujævne fremskridt. DNS-rodzonen har været signeret siden 2010, og over 1.400 TLD’er understøtter nu DNSSEC. Men udbredelsen på andet niveau varierer dramatisk. I .nl-zonen er over 95 % signeret, hvilket skyldes incitamenter fra registreringsdatabasen og obligatoriske politikker. I modsætning hertil ligger .com på omkring 1,5 % – millioneraf domæner er stadig ikke signeret.

På resolversiden viser APNIC-målinger, at ca. 30 % af DNS-resolverne udfører DNSSEC-validering globalt, hvilket er en stigning fra ca. 10 % i 2018. Der sker fortsat fremskridt, men de fleste slutbrugere modtager stadig uvaliderede DNS-svar.

DNSSEC indeholder også sikkerhedsovervejelser ud over valideringsfejl. Store signerede svar gør autoritative servere attraktive for DNS-forstærkningsangreb. Operatører skal implementere begrænsning af svarhastigheden og følge bedste praksis for resolver-konfiguration for at undgå at blive uvidende angrebsinfrastruktur.

Store organisationer fortsætter med at opfordre til bredere anvendelse. ICANN udgiver implementeringsvejledninger, og nationale cybersikkerhedsagenturer anbefaler i stigende grad DNSSEC til statslige domæner og domæner med kritisk infrastruktur. Prognoser tyder på, at udbredelsen af andet niveau kan nå 50 % i 2030, da automatisering gennem CDS/CDNSKEY reducerer den operationelle friktion.

Operationer i den virkelige verden: DNS Root Zone Signing Ceremony og Trust Anchors

DNS-rodzonen indtager en unik position i DNSSEC-arkitekturen. Da der ikke er nogen overordnet zone, der kan levere en DS-post , skal rodens KSK betros out-of-band som det ultimative tillidsanker. Det er enormt vigtigt at gøre det rigtigt – enhverDNSSEC-tillidskæde har sin oprindelse her.

ICANN gennemfører rodsigneringsceremonier fire til seks gange om året i sikre faciliteter i USA og Europa. Disse ceremonier involverer ekstraordinære proceduremæssige kontroller: Hardwaresikkerhedsmoduler (HSM’er) opbevarer den private rodnøgle, som der kun er adgang til, når flere kryptoofficerer bruger smartcards og PIN-koder samtidig. Fysiske sikkerhedsforanstaltninger omfatter poser, der kan manipuleres, overvågede pengeskabe og komplet videodokumentation.

Den første signering af rodzonen i juli 2010 markerede DNSSEC’s overgang fra teori til praktisk global implementering. KSK-omlægningen i 2018 – hvor den oprindelige KSK fra 2010 blev erstattet af KSK-2016 – testede systemets evne til at opdatere det grundlæggende tillidsanker. På trods af omfattende opsøgende arbejde oplevede ca. 0,2 % af resolverne problemer på grund af forældet software eller konfiguration. Fremtidige rollovers er planlagt til midten af 2020’erne.

Rekursive resolvere får root trust-ankeret gennem softwaredistributioner eller automatiserede opdateringsprotokoller, der vedligeholdes af IANA. Moderne resolversoftware indeholder typisk aktuelle ankre og mekanismer til at hente opdateringer, hvilket sikrer, at tillidskæden forbliver intakt, når nøglerne ændres.

Disse ceremonier kan virke omstændelige, men de giver berettiget sikkerhed. Rodzonens integritet understøtter DNSSEC globalt, og den dokumenterede, reviderbare proces skaber tillid til, at denne kritiske infrastruktur fungerer med passende stringens.

Implementering af DNSSEC på dine domæner

Er du klar til at aktivere DNSSEC for dine domæner? Processen omfatter flere faser, fra verifikation til løbende vedligeholdelse.

Forudsætninger for at bekræfte:

• Dit TLD understøtter DNSSEC (tjek ICANN’s implementeringsressourcer)
• Din registrator accepterer indsendelser af DS-poster
• Din DNS-hostingudbyder understøtter zonesignering og DNSKEY-administration

Mange administrerede DNS-udbydere som Cloudflare og AWS Route 53 håndterer signering automatisk. For selvadministrerede zoner skal du bruge signeringsværktøjer, der er kompatible med din autoritative serversoftware.

Typiske udrulningstrin:

1. Generer ZSK- og KSK-par (eller aktiver udbyderadministreret signering)
2. Signer DNS-zonen og bekræft DNSSEC-signaturer lokalt
3. Udgiv DNSKEY-poster (og eventuelt CDS/CDNSKEY til automatiseret DS-administration)
4. Indsend DS-poster via din registrators interface
5. Tillad udbredelsestid, og bekræft derefter hele kæden

Validering er lige så vigtig. Hvis din organisation bruger rekursive resolvere, skal du aktivere DNSSEC-validering (f.eks. dnssec-validation yes i BIND). Test mod kendte domæner: korrekt signerede websteder bør returnere AD-flaget (Authenticated Data), mens dnssec-failed.org bør give SERVFAIL.

Bedste praksis for drift:

• Overvåg signaturens udløb: RRSIG’er varer typisk 30 dage. Automatiser fratrædelse i god tid før udløb.
• Test vigtige rollovers: Øv dig i rollover-proceduren i et staging-miljø før produktion.
• Implementer advarsler: Konfigurer overvågning af DNSSEC-valideringsfejl hos dine opløsere.
• Dokumenter procedurer: Klare kørebøger forhindrer panik under hændelser eller planlagte rollovers.

De nøjagtige grænseflader varierer efter registrator og udbyder, så fokuser på at forstå de underliggende opgaver i stedet for at huske specifikke knapklik. Målet er at implementere DNSSEC uden at forårsage afbrydelser – omhyggeligforberedelse og testning gør det muligt.

Bedste praksis for DNSSEC

Vellykket implementering af DNSSEC kræver mere end blot aktivering af signaturer – det kræver løbende opmærksomhed på detaljer og overholdelse af branchens bedste praksis. Domæneejere bør prioritere regelmæssig nøglerotation for at minimere risikoen for nøglekompromittering og sikre, at alle private nøgler opbevares sikkert, ideelt set ved hjælp af hardwaresikkerhedsmoduler eller andre beskyttede miljøer.

Kontinuerlig overvågning af DNSSEC-validering er afgørende; dette omfatter sporing af signaturudløbsdatoer og hurtig tilbagetrækning af poster, før de udløber. Det er også vigtigt at kontrollere, at alle komponenter i din DNS-infrastruktur – autoritative servere, rekursive resolvere og registratorgrænseflader – fuldt ud understøtter DNSSEC-implementering og -validering.

Testning er et andet afgørende skridt. Domæneejere bør rutinemæssigt kontrollere, at deres DNS-data signeres og valideres korrekt, ved at bruge værktøjer og testdomæner til at simulere både vellykkede og mislykkede valideringsscenarier. Ved at følge disse best practices kan domæneejere opretholde en robust DNS-infrastruktur, beskytte deres brugere mod DNS-baserede angreb og sikre den løbende integritet og troværdighed af deres domænenavnesystem.

Konklusion og næste skridt

DNSSEC omdanner domænenavnesystemet fra en arkitektur med tillid til alt til en med kryptografisk verificering gennem digitale signaturer og en hierarkisk tillidskæde, der adresserer sårbarheder, som har eksisteret, siden DNS blev designet i 1980’erne. Beskyttelsesmekanismerne – RRSIG-signaturer, DNSKEY/DS-koblinger og autentificeret afvisning gennem NSEC/NSEC3 – forhindrer DNS-cacheforgiftning og DNS-spoofing-angreb, der ellers kunne omdirigere brugere lydløst. For eksisterende DNS-poster, der indeholder falske DNS-data, afviser validerende resolvere simpelthen de manipulerede DNS-data helt.

På trods af den operationelle kompleksitet er DNSSEC modnet betydeligt siden rodsigneringen i 2010. Bred TLD-understøttelse, forbedret automatisering gennem CDS/CDNSKEY og voksende valideringsrater for resolvere indikerer alle momentum. Store sikkerhedsorganisationer anbefaler det til domæner, hvor spoofing kan forårsage alvorlig skade.

For dem, der er ansvarlige for DNS-infrastrukturen, er de næste skridt praktiske:

• Opgør hvilke domæner og zoner, der i øjeblikket er signeret
• Planlæg en trinvis implementering af DNSSEC, der starter med kritiske tjenester, der henvender sig til offentligheden
• Aktivér DNSSEC-validering på interne resolvere, hvor det er muligt
• Etablér procedurer for overvågning og reaktion på hændelser i forbindelse med DNSSEC-fejl

Yderligere læringsressourcer omfatter de centrale DNSSEC RFC’er (4033, 4034, 4035), implementeringsvejledninger fra ICANN og regionale netværksinformationscentre samt testværktøjer som Verisigns DNSSEC Analyzer. Vejen fra forståelse til handling er klarere end nogensinde – og sikkerhedsfordelene retfærdiggør investeringen.