Vägledning för införande av DNSSEC

Vägledning Version 1.0 2010-10-22 Vägledning för införande av DNSSEC Framtagen i samarbete mellan E-delegationen, Sveriges Kommuner och Landsting samt Kommunförbundet Stockholms Län. Vad vill uppnås med vägledningen? Mål: Ett införande av DNS Security Extensions (DNSSEC) ska vara genomfört senast sommaren 2011. Syfte: Att ge den enskilda myndigheten, kommunen eller landstinget en vägledning för att snabbt och smidigt kunna införa DNSSEC.

Innehållsförteckning Förord... 3 1 Inledning... 4 1.1 Syfte och mål... 4 1.2 Dokumentbeskrivning... 4 1.3 Målgrupp... 4 2 Sammanfattning... 5 3 Bakgrund... 6 3.1 Historik... 6 3.2 Teknisk översikt... 6 3.3 DNSSEC mellan klient och resolver... 11 4 Konsekvensanalys DNSSEC... 12 4.1 Konsekvenser av ett icke-införande... 12 4.2 Operativa frågeställningar... 12 4.3 Risker vid införande... 13 4.4 Vid utlokaliserad drift (outsourcing)... 13 5 Införande av DNSSEC... 14 5.1 Definiera införandeplan... 14 5.2 Införande vid utlokaliserad drift (outsourcing)... 14 6 Praktisk införandeplan DNSSEC... 15 6.1 Genomför konsekvensanalys... 15 6.2 Resurser... 15 6.3 Inventering... 15 6.4 Testbädd... 15 6.5 Utbildning... 16 6.6 Dokumentation och rutiner... 16 6.7 Nyckelhantering... 16 6.8 Signera en första zon... 16 6.9 Full signering... 17 6.10 Intern resolver och DNSSEC... 17 6.11 Drift och förvaltning... 17 7 Referenser... 18 2

Förord Denna vägledning är framtagen i samarbete mellan E-delegationen, Sveriges Kommuner och Landsting (SKL) samt Kommunförbundet Stockholms län (KSL). Vägledningen är en första version vilken vi har för avsikt att uppdatera vid årsskiftet 2010/2011. Tips på förbättringar, tillägg och ändringar skickas till info@edelegationen.se. 3

1 Inledning 1.1 Syfte och mål Syftet är att ge den enskilda myndigheten, kommunen eller landstinget en vägledning för att snabbt och smidigt kunna införa DNS Security Extensions (DNSSEC). Målet är att ett införande ska vara genomfört senast sommaren 2011. 1.2 Dokumentbeskrivning I dokumentet används ett system för texthänvisningar där varje hänvisning följs av ett nummer inom hakparenteser. Hänvisningarna beskrivs i referenslistan i avsnitt 7. För en mer teknisk djuplodande beskrivning av DNSSEC hänvisas läsaren bl.a. till källorna som finns i referenslistan i avsnitt 7. 1.3 Målgrupp Dokumentet är skrivet med IT-strateger, IT-chefer och IT-projektledare som målgrupp. Texten tar upp den tekniska bakgrunden till DNSSEC samt hur denna teknologi kan införas i den egna organisationen. 4

2 Sammanfattning Huvudsyftet med DNSSEC är att säkerställa att svaret på en DNS-fråga inte är förvrängt och att det kommer från korrekt källa. DNS används för att översätta domännamn till IP-adresser, t.ex. att www.foretaget.se har IP-adressen 212.75.68.226. Det konkreta resultatet av att använda DNSSEC är att förfalskade och manipulerade svar upptäcks. Internetanvändare kan därmed förlita sig på att IPadressen i DNS-svaret verkligen motsvarar det domännamn som frågan avsåg. Risker med att inte använda DNSSEC är till exempel att: 1. externa parter som ska nå resurser på ett företag (webbservern, e-post etc.) istället blir styrda till ett annan server, t.ex. till en webbserver som satts upp av någon illvillig i syfte att locka av kreditkortsnummer etc. 2. interna tjänster styrs om till externa källor, vilket kan avslöja känslig information. Införande av DNSSEC har två dimensioner: 1 1. att man inför DNSSEC på sin egen externa DNS-server, 2. att man inför stöd för DNSSEC för den interna infrastrukturen, något som beröra brandväggar, routrar och servrar/datorer. I dagsläget är de flesta befintliga produkter (DNS-servrar, resolvrar och klienter) redan förberedda att hantera DNSSEC, så anskaffningskostnaden av ny utrustning kan hållas låg. Stor vikt bör läggas på att använda ett bra verktyg för att hantera DNS-uppdateringar på ett automatiserat sätt. Detta minskar administration och förvaltning av DNS. Rekommendation: Lägg resurser på utbildning, tester och labbmiljöer i början av införandeprojektet för att minimera driftstörningar. 1 Med andra ord menas att externa frågor mot organisationens externa DNS-servrar kan besvaras enligt DNSSEC och att den interna organisationens utrustning får DNSSEC-validerade svar på sina DNS-frågor. 5

3 Bakgrund DNSSEC (DNS Security Extensions) är ett viktigt tillägg för att råda bot på den tillförlitlighetsproblematik som finns med DNS utan signerade poster. 3.1 Historik DNS (Domain Name System) är världens största distribuerade databas och används av miljontals Internetanvändare varje minut. DNS används främst för att översätta domännamn till IP-adresser. Om exempelvis http://www.exempel.se anges i användarens webbläsare så ställs automatiskt en fråga till angiven DNS-server som i sin tur kontrollerar om svaret för det efterfrågade domännamnet finns lagrat i minnet, vilket är fallet om frågan nyligen ställts. I annat fall rådfrågar DNS-servern andra servrar baserat på en given hierarki, och återkommer därefter med ett svar till klienten i form av en IP-adress. Processen är helt transparent och den normala användaren funderar inte över tekniken bakom detta. Det är därför inte förvånande att vanliga användare sällan är medvetna om hur lätt det är att attackera en DNS-fråga och lämna ett felaktigt svar. Det felaktiga svaret resulterar i att användaren når en falsk värdmaskin. Kanske en webbserver som ser identisk ut med den förväntade, men som i själva verket används för att fånga upp inloggningsinformation. Regeln är enkel, den som snabbast besvarar en DNS-fråga vinner, oavsett vem som svarar. År 2008 upptäckte säkerhetsforskaren Dan Kaminsky ett säkerhetshål i DNS[1] gällande det relativt låga antalet transaktionsidentiteter som används och att dessa går att gissa sig till för att sedan förfalska svaret som går tillbaka. Detta säkerhetshål var relativt lätt att täppa till men gjorde att DNSSEC fick fler anhängare som ansåg att något måste göras åt DNS protokollets dåliga säkerhet. Svenska.SE blev 2007 den första toppdomänen i världen att erbjuda en fullvärdig DNSSEC-tjänst[2]. Den 15 Juli 2010 signerades rot (.) zonen[3] vilket är ett viktigt steg i utbredningen av DNSSEC. 3.2 Teknisk översikt Behovet av att garantera äktheten i DNS och skydda mot modifiering av DNS är en av de viktigaste hörnstenarna för att säkra användningen av Internet. IETF släppte RFC 2535-2541 i mars 1999 vilka innefattade tillägg till DNS för att skydda mot modifiering av DNS-data och garantera dess integritet[4]. Tilläggen går under benämningen DNS Security Extensions och kräver anpassade DNS-servrar och applikationer för att nyttjas fullt ut. Specifikationerna har uppdaterats och kompletterats ett flertal gånger sedan dess. RFC 4033-4035 är de versioner som gäller idag[5]. DNSSEC baseras på kryptografiska funktioner för att hantera äkthet och förhindra modifiering. Detta bygger på två delar, en hash (checksumma) och 6

asymmetrisk kryptering. Tekniken har länge använts i andra protokoll och teknologier som SSL/TLS, PKI och IPSec. 2 En DNS-server som ställer en fråga till en signerad domän kan med domänens publika nyckel verifiera att exempelvis en adresspost är korrekt. Den digitala signaturen används för att verifiera att adressposten är äkta och inte förändrad. Vid användning av asymmetrisk kryptering 3 gäller det att kunna garantera att den publika nyckeln verkligen är den publika nyckel som den utges för att vara. En falsk domän, med falska signaturer och en falsk publik nyckel, kan potentiellt producera ett korrekt DNS-svar. För att garantera äktheten hos den publika nyckeln för en domän, så signeras den av den överliggande domänens nyckel som i sin zon publicerar en unik signatur för varje signerad underdomän. Exempelvis så signeras den publika nyckeln för zonen www.exempel.se av zonen example.se. Den publika nyckeln för exempel.se signeras av.se som i sin tur signerats av rot-servrarna (.) (Se bild 1). Rotservrarnas publika nycklar är givna på förhand, på samma sätt som deras IP-adresser. Detta verifieringsscenario kallas för walking the chain of trust. Bild 1. Chain of trust Rotservrarnas publika nyckel är den enda som behövs för att kunna verifiera kedjan vilket löser problemet med distribution av nycklar. Det är viktigt att påpeka att DNSSEC inte krypterar DNS-information utan enbart signerar information så att mottagaren kan verifiera äktheten. DNSSEC använder sig normalt av två nyckelpar. Zone Signing Key (ZSK) - Signerar zondata Key Signing Key (KSK) - Signerar ZSK - Signeras av överliggande domän 2 Erkända teknologier för säkra förbindelser över Internet(SSL/TLS, IPSec) samt infrastruktur för certifikat (PKI). 3 Nyckelpar med matematiskt samband. Information krypterad med publik nyckel dekrypteras med privat nyckel. Information krypterad med privat nyckel dekrypteras med publik nyckel. Det senare brukar benämnas signering då publik nyckel delas med mottagaren som kan verifiera äkthet genom att dekryptera data med publik nyckel och jämföra det med datat i klartext. 7

Två nycklar används för att KSK, som är länken mellan föräldrazon och egen domän, inte ska behöva publiceras på nytt i föräldrazonen varje gång man förnyar nyckel för signering av den egna zonen. ZSK är normalt av kortare längd och byts oftare än den typiskt bitmässigt längre KSK. DNSSEC utökar den befintliga DNS-standarden med följande nya poster: DNSKEY Publika delen av det nyckelpar som signerar data RRSIG Signatur för en annan post i zonen (SOA, NS, A etc). NSEC Nästa signerade post. Funktion för att få signerade svar på poster som ej existerar (NX DOMAIN). NSEC3 Utökning av NSEC för att förhindra så kallad zone walking. 4 DS Delegering av signering. Föräldrazonen delegerar signering av underzon till den som äger den privata nyckeln som har den checksumma på publik nyckel som publiceras i denna post. Signering av zon För att DNS uppslag ska kunna verifieras med DNSSEC måste zonen signeras. Det går till på följande sätt. Signering av zon. (Se bild 2.) 1. Två nyckelpar genereras, KSK och ZSK. 2. Den publika delen av nycklarna publiceras i zonen som DNSKEY poster. 3. KSK signerar DNSKEY posterna. Signeringsdata publiceras i form av en eller flera RRSIG DNSKEY poster. 4. NSEC/NSEC3 poster skapas så att zonen kan ge signerade svar på poster som ej existerar (NX DOMAIN). 5. Om signerad delegering för underzon används så skapas DS poster för dessa med en checksumma av under zonens publika KSK nyckel. 6. ZSK signerar alla poster i zonen och skapar RRSIG för varje post. 4 Om enbart NSEC används är det möjligt att räkna ut vilka värdnamn som finns i zonen. En hackare kan på så vis skaffa sig information som inte är uppenbart publik om organisationens nätverk och tjänster. NSEC3 använder kryptografiska checksummor i DNS-posterna för att inte avslöja informationen. 8

Bild 2. Självsignerad. (rot) som i sin tur delegerar signering till zonen/toppdomänen.se som i sin tur delegerar signering till underzoner. Verifiering av uppslag För att DNSSEC ska ge någon effekt måste en resolver (funktion som utför DNS uppslag) verifiera signaturerna. Exempel där resolver ska slå upp www.exempel.se (Se bild 3.): 1. Publika nyckeln för rotzonen distribueras via annat protokoll. Exempelvis signerad med PGP och publicerad via HTTP/S, FTP eller direkt via operativsystemet. 2. Resolver frågar. (rot) om namnserver för se. 3. DNS. (rot) svarar med namnserver post och DS för KSK i zonen se. samt RRSIG för DS-posten. 9

4. Resolver kontrollerar signaturerna med hjälp av nyckeln för rotzonen. 5. Resolver frågar namnservern hos se. om namnserver för exempel.se. 6. se. svarar med namnserver post samt DS för KSK i zonen exempel.se. och RRSIG för DS-posten. 7. Resolver frågar DNS se. om DNSKEY för se. 8. DNS se. svarar med de DNSKEY poster som finns i zonen. 9. Resolver kontrollerar att signaturerna stämmer och att nyckeln är den samma som. (rot) pekade ut som DS för se. 10. Resolver frågar DNS exempel.se. om A-post för www.exempel.se. 11. DNS exempel.se. svarar med A post samt RRSIG för A-posten. 12. Resolver frågar DNS exempel.se. om DNSKEY för exempel.se. 13. DNS exempel.se. svarar med de DNSKEY poster som finns i zonen. 14. Resolver kontrollerar att signaturer stämmer och att nyckeln är den samma som DNS se. pekade ut som DS för exempel.se. Bild 3. Exempel där resolver ska slå upp www.exempel.se 10

När en resolver sätter flaggan 5 do till 1 innebär det att den, om möjligt, vill ha signerade poster från DNS-servern. 3.3 DNSSEC mellan klient och resolver Utifrån ovanstående tekniska förklaring till DNSSEC så är det således primärt externa zoner som signeras. Interna zoner kan också signeras, men det ger inte något större skydd då det i dagsläget inte görs någon verifikation på klientens sida av DNSSEC-svaret. En klient (arbetsstation, t.ex. med operativsystemet Windows 7) förlitar sig på att resolvern (oftast den interna DNS-servern) gör verifikationsarbetet och skickar tillbaka ett svar med AD-biten 6 satt/inte satt beroende på verifikationsresultatet. För ett säkert informationsflöde mellan klient och resolver (Last hop communication) utnyttjas krypteringsprotokollet IPsec mellan klienten och resolvern. Alla DNS-frågor går sålunda krypterat genom en IPsec-tunnel mellan klienten och resolvern. IPsec-tunneln är konfigurerad för att enbart sättas upp mellan klienten och betrodd motpart (DNS-servern); DNS-frågor kan alltså inte av misstag ställas mot annan än utsedd resolver. 5 Flaggor används i paketen mellan resolver och server för att signalera information enligt protokollstandarden. 6 AD-biten (Authenticated Data) används av resolvern för att i sitt svar till klienten markera att ett DNSSEC-svar har kontrollerats och anses vara autentiserat i enlighet med RFC 4035. Om den inte är satt, betyder det att verifikationen av svaret har misslyckats någonstans. 11

4 Konsekvensanalys DNSSEC E-delegationen publicerar på sin webbsajt 7 en lista över signerade myndighetsdomäner. Listan visar att det endast är ett mycket litet antal av myndighetsdomänerna i Sverige som är signerade. Ett stort DNSSEC-arbete väntar därför inom de närmaste åren, såväl administrativt som tekniskt. Denna konsekvensanalys är avsedd som en mall för de frågor som generellt är viktiga att besvara innan ett beslut om införande av DNSSEC fattas och genomförs. Generellt kan sägas att ett icke-införande på längre sikt torde vara en omöjlighet för samtliga svenska myndigheter. Det stora förtroendekapital som finns för material publicerat av det offentliga Sverige kan vid exempelvis en domänkapning såväl utnyttjas som skadas. Det är också mycket viktigt att myndighetsanställda kan validera DNS-svar med DNSSEC så snart som möjligt. 4.1 Konsekvenser av ett icke-införande De två huvudkonsekvenserna av att inte använda DNSSEC är att: de egna domänerna potentiellt kan kapas och utnyttjas för phishing, spridning av skadlig kod eller utsättas för defacement. 8 Om organisationen har en egen resolver kommer denna inte kunna validera DNS-svar från signerade domäner. I dagsläget är få domäner signerade men ur ett längre perspektiv är detta en mycket viktig konsekvens. Utöver detta kommer förmodligen webbläsarna att inom en snart framtid indikera om en domän är signerad eller inte på samma sätt som sker för SSL-certifikat. DNSSEC-stöd kommer då att vara en kvalitetstecken gentemot användaren. 4.2 Operativa frågeställningar Befintlig IT-infrastruktur, nätverk och applikationsportfölj Stöder organisationens registrar DNSSEC? Detta är en förutsättning för att en DSpost (Delegated Signer) vilket är ett kondensat av den egna publika nyckeln, ska kunna publiceras i föräldradomänen, exempelvis.se. Finns stöd för DNSSEC-signering och validering redan i befintlig DNSutrustning eller behöver ny hård- eller mjukvara inköpas? Finns en fungerande tidssynkronisering hos relevanta nätverkskomponenter? Detta är viktigt för att en korrekt validering av DNSSEC-signaturer ska kunna genomföras. 7 www.edelegationen.se 8 Defacement av en webbsajt innebär att innehållet byts ut av angriparen. Motiven är ofta politiska eller på annat sätt åsiktsrelaterade. 12

Det finns olika varianter av DNSSEC-signerare, se Review of Administrative Tools for DNSSEC [6]. Lösningsalternativen ställer olika krav på den interna DNSinfrastrukturen och denna kan behöva läggas om för att passa vissa alternativ. Eftersom DNSSEC-signaturer inkluderas i zonfilerna kommer dessas storlek att växa kraftigt, liksom storleken på DNS-svaren. Det bör utredas lokalt av organisationen huruvida detta har några effekter på nätprestanda eller val av DNSprotokoll (TCP istället för UDP). En policy och rutin för nyckelhantering bör etableras för att underlätta byte av signeringsnycklar. Utbildning av medarbetare Kunskapsnivån hos medarbetarnas som ska planera/införa/administrera/förvalta DNSSEC bör inventeras. Vilken utbildningsinsats krävs och hur och var kan den genomföras? 4.3 Risker vid införande Den största risken med att införa DNSSEC är att misstag görs vid byte av nycklar vilket kan medföra att organisationens domän inte går att validera, och alltså inte kan nås utifrån. Detta kan ske om DS-posten inte uppdateras korrekt vid byte av KSK. De flesta verktyg för DNSSEC-signering hanterar nyckelbyte automatiskt och kan konfigureras att notifiera administratören när posten behöver uppdateras. Om DNSSEC används för validering även på det interna nätet vid automatisk kommunikation mellan servrar, exempelvis för tidssynkronisering kan oväntade problem uppstå om valideringen misslyckas. För att minimera denna typ av problem stöder flera produkter notifiering via SNMP-fällor (Simple Network Management Protocol). Om organisationens resolver använder DNSSEC för validering är det viktigt att resolvern har tillgång till de senaste rotnycklarna. Planer finns på att inkludera rotnyckeluppdatering i de flesta operativsystem men dessa kan även behöva importeras manuellt för att säkerställa att validering fungerar som avsett. 4.4 Vid utlokaliserad drift (outsourcing) Det som ovan skrivet om att utföra en konsekvensanalys för den egna organisationen vid införande av DNSSEC är lika tillämpligt när organisationen har sin drift utlagd på annan part (outsourcing). Den största risken vid införande av DNSSEC i en utlokaliserad miljö, är att driftparten inte har (eller tänker skaffa sig) stöd för DNSSEC. Detta bör kunna undvikas genom att man som beställare har krav på stöd för DNSSEC vid upphandling (eller omförhandling) av sin driftmiljö. Observera att det kan vara relevant att veta vilken DNSSEC-lösning operatören erbjuder, då det kan ha inverkan vad gäller nyckelhantering osv. Det kan även vara aktuellt att ta in referenser på vilken erfarenhet de har av tekniken, andra DNSSECkunder etc. 13

5 Införande av DNSSEC Vid införande av DNSSEC är det är viktigt att förstå funktionen och dess komponenter. Här följer en handlingsplan för införande av DNSSEC. Införande av DNSSEC omfattar tre övergripande steg: Utredning av policy för DNSSEC. (Nyckellängder, nyckelrullningsmetod, förvaring av nycklar, etc.). Signering av organisationens publika zoner. Kontroll av signaturer för uppslag mot externa zoner. Policy kan utredas av säkerhetsansvarig tillsammans med ansvarig för DNS. Tekniska förändringar utförs av administratören i DNS infrastrukturen. Införandet av DNSSEC kan drivas i projektform om så önskas. 5.1 Definiera införandeplan Nedan är ett förslag till hur ett införande av DNSSEC kan gå till. Punkterna utvecklas närmare i avsnitt 6. 1. Genomför konsekvensanalys av ett DNSSEC-införande. Se avsnitt 4. 2. Avdela resurser för ett införande av DNSSEC. 3. Genomför en inventering av utrustning och applikationer. 4. Om möjligheten finns, sätt upp ett testnät/testbädd där funktionaliteten kan provas om osäkerhet finns för nivå av DNSSEC-stöd i system eller applikationer. 5. Vid behov, utbilda den personal som ska utföra konfigurationen av DNSSEC. 6. Se över dokumentation och rutiner kring hantering av DNSSEC, speciellt rutiner vid nyckelrullning. 7. Generera signeringsnycklar (KSK och ZSK). 8. Publicera DS-post för den publika delen av KSK i föräldrazon. 9. Signera (om möjligt) en mindre zon, eller testzon, för att se hur det fungerar i praktiken. 10. Signera övriga zoner i DNS:en och kontrollera förloppet och funktionaliteten. 11. Aktivera validering av DNSSEC i den interna resolvern. 12. Verifiera att förvaltningsrutiner etc. är framtagna och kan följas i praktiken. 5.2 Införande vid utlokaliserad drift (outsourcing) När driften av DNS är utlokaliserad, bör konsekvensanalysen genomföras av den beställande organisationen. Efter detta kan en beställning av funktionen DNSSEC göras. Hur det kan realiseras omfattas troligen av driftavtalet mellan parterna. Vid/under införandet bör beställaren bevaka att förvaltningsrutiner är framtagna och kan följas i praktiken (se punkt 12 ovan). 14

6 Praktisk införandeplan DNSSEC 6.1 Genomför konsekvensanalys En konsekvensanalys tas fram för att skapa ett underlag till om ett projekt att införa DNSSEC ska genomföras och förutse risker mm med införandet, se avsnitt 4. 6.2 Resurser Följande resurser krävs vid införande av DNSSEC: Administratör av infrastruktur för DNS (Gäller även om DNS administreras externt av tredje part.) Administratörer av server och klient för verifiering av DNSSEC funktion. Testpersoner som kan utföra tester utanför den interna infrastrukturen, exempelvis från Internetuppkoppling i hemmet. 6.3 Inventering Innan arbetet med att signera zoner och konfigurera kontroll av uppslag påbörjas behöver infrastrukturen inventeras så att denna kan hantera DNSSEC. Åtminstone följande punkter kan vara lämpliga att se över: Intern resolver: - Hanteras DNSSEC? (Signaturkontroll av DNS-uppslag)? - Hantering av loggar för felsökning av DNSSEC? DNS server för organisationens publika zoner: - Hanteras signering och publicering av signerade DNS-poster? - Finns administrativa verktyg för att hantera nyckelpar och förnyelse av dessa? - Hur skyddas privata nycklar, behöver en hårdvarumodul för nyckellagring köpas in? - Om extern leverantör av DNS tjänst används, kan denna hantera DNSSEC? Rapporten A Review of Administrative Tools for DNSSEC, framtagen av CERTEZZA för.se (Stiftelsen för Internetinfrastruktur), kan vara bra referens vid inventeringsarbetet.[6] 6.4 Testbädd För att undvika störningar i DNS-tjänsten kan det vara bra att sätta upp en testbädd där man implementerar DNSSEC utanför produktionsmiljön för att upptäcka eventuella problem. Detta kan enkelt göras genom att sätta upp en kopia av 15

nuvarande DNS tjänst och sedan kopiera zondata från produktionsmiljön till testbädd. Sedan kan man i testmiljön skapa testnycklar, signera zondata och utföra övriga relevanta tester. Samma process fungerar för interna resolvers. Dock behöver man enbart sätta upp en kopia av nuvarande resolver och slå på verifiering av signerade DNS-svar och göra tester enligt testprotokoll. Denna testuppsättning behöver dock åtkomst till Internet för att nå rotservrarna. 6.5 Utbildning Administratörer av DNS-servrar bör läsa in sig på hur DNSSEC fungerar generellt samt inventera och planera hur organisationens nuvarande DNS infrastruktur hanterar eller bör hantera DNSSEC. Detta kan ske via utbildning eller genom att läsa produktdokumentation och de publika dokument som finns kring DNSSEC. 6.6 Dokumentation och rutiner Rutinerna kring hantering av DNS blir mer komplicerade med DNSSEC. Detta är några rutiner och regler som bör upprättas specifikt för DNSSEC: Hur privata nycklar skyddas Uppdatering av zondata (kräver signering) Förnyelse av KSK och ZSK Propagering av KSK/DS-post till toppdomän Uppdatering av rotzonens publika nyckel för caching/forwarding resolvers 9.SE:s deklaration av säkerhetsåtgärder och rutiner för DNSSEC är en bra referens vid detta arbete.[7] Dokumentation kring hur organisationens DNS-servrar är uppsatta för DNSSEC bör tas fram. 6.7 Nyckelhantering Hantera nyckelgenerering och hantering i enlighet med det som bestämts i punkt 6.6. 6.8 Signera en första zon Det första steget (om det inte finns någon testbädd enligt 6.4 tillgänglig för ändamålet) är att signera en mindre zon, kanske en gammal zon som inte används längre. Detta visar att använda verktyg fungerar som avsett och att DNSdelegeringen är korrekt. 9 Caching avser att resolver lagrar uppslag för att snabbare kunna ge svaret nästa gång samma information efterfrågas. Forwarding avser att resolver skickar vidare DNS frågor till server som kan ge svar på den information som efterfrågas. 16

6.9 Full signering När den initiala signeringen har gjorts, övergå till att signera alla de zoner som finns i DNS:en. 6.10 Intern resolver och DNSSEC Se till att den interna DNS-servern använder sig av DNSSEC och utför validering av DNS-uppslag. 6.11 Drift och förvaltning Driftsättning sker efter säkerställande att drift i produktionsmiljön kan hållas på en acceptabel nivå. Innan driftsättning bör backup och återställningsrutiner för utrustning som påverkas av förändringen verifieras. Detta för att säkerställa smidig återställning av system om driftsättning behöver återkallas. Underhåll bör ske enligt de rutiner som är rekommenderade under punkt 6.6. 17

7 Referenser [1] Dougherty, Chad R, US-CERT, http://www.kb.cert.org/vuls/id/800113 [2].SE (Stiftelsen för Internetinfrastruktur), http://www.iis.se/domaner/dnssec [3] IANA, VeriSign Inc., http://www.root-dnssec.org/2010/07/16/status-update- 2010-07-16/ [4] IETF, http://www.ietf.org/rfc/rfc2535.txt, http://www.ietf.org/rfc/rfc2536.txt, http://www.ietf.org/rfc/rfc2537.txt, http://www.ietf.org/rfc/rfc2538.txt, http://www.ietf.org/rfc/rfc2539.txt, http://www.ietf.org/rfc/rfc2540.txt, http://www.ietf.org/rfc/rfc2541.txt [5] IETF, http://www.ietf.org/rfc/rfc4033.txt, http://www.ietf.org/rfc/rfc4034.txt, http://www.ietf.org/rfc/rfc4035.txt [6] Nilsson, Andreas, CERTEZZA, A Review of Administrative Tools for DNSSEC http://www.iis.se/docs/dnssec-admin-tools-review-final.pdf [7].SE (Stiftelsen för Internetinfrastruktur), DNSSEC Säkerhetsdeklaration (DPS) http://www.iis.se/docs/dnssec-dps-sv.pdf 18