DNSSEC

DNSSEC införs

När DNS en gång i tiden infördes så gjordes det utan något egentligt fokus på säkerhet och ganska snart efter lanseringen upptäcktes flera sårbarheter. Som ett resultat av detta har ett säkerhetssystem utvecklats i form av tillägg till det befintliga DNS-protokollet. Detta system har senare granskats och godkänts som en standard av Internet Engineering Task Force ( IETF ) .

Efter flera testinstallationer, med början 2007 har DNSSEC rullades DNSSEC officiellt ut på rotnivå under 2010. Därefter har det skett en kontinuerlig lansering av toppdomäner som inför DNSSEC. För nya toppdomäner som lanseras är det ett krav att de skall stödja DNSSEC redan från början.

Hur fungerar DNSSEC?

DNSSEC skapar ett säkert domännamnssystem genom att lägga till kryptografiska signaturer till befintliga DNS-poster. Dessa digitala signaturer lagras i DNS-namnservrar tillsammans med de vanliga posttyperna som A, AAAA, MX, CNAME, etc. Genom att kontrollera dess associerade signatur kan du verifiera att en begärd DNS-post kommer från dess auktoritativa namnserver och inte har ändrats på vägen, i motsats till ett falskt rekord injicerat i en man-i-mitten-attack.

För att skapa signaturvalidering lägger DNSSEC till några nya DNS-posttyper:

RRSIG – Innehåller en kryptografisk signatur av ett RRset
DNSKEY – Innehåller en offentlig zonsigneringsnyckel och en offentlig nyckelsigneringsnyckel.
DS – Innehåller hash för en DNSKEY-post
NSEC och NSEC3 – För explicit nekande av existens av en DNS-post
CDNSKEY och CDS – För en underordnad zon som begär uppdateringar av DS-post(er) i den överordnade zonen.

RRset och RRSIG

Det första steget mot att säkra en zon med DNSSEC är att gruppera alla poster med samma typ i en resurspostuppsättning (RRset). Till exempel, om du har tre AAAA-poster i din zon på samma värdnamn (dvs. www.webb.se), skulle de alla samlas i ett enda AAAA RRset.

Det är faktiskt detta fullständiga RRset som signeras digitalt, i motsats till enskilda DNS-poster. Naturligtvis betyder detta också att du måste begära och validera alla AAAA-poster från en zon med samma värdnamn istället för att endast validera en av dem.

RRSIG  är den digitala signaturen och den lagrar signaturer som används för validering av det medföljande RRset. Signaturen som finns i RRSIG posten valideras mot den publika delen av zonsigneringsnyckeln (ZSK).

Zonsigneringsnycklar (ZSK)

Varje zon i DNSSEC har ett zonsignerande nyckelpar (ZSK): den privata delen av nyckeln signerar digitalt varje RRset i zonen, medan den offentliga delen verifierar signaturen. För att aktivera DNSSEC skapar en zonoperatör digitala signaturer för varje RRset med den privata delen av ZSK och lagrar dem i sin namnserver som RRSIG-poster. Det är som att säga: ”Detta är mina DNS-poster, de kommer från min server och de borde se ut så här.”

Dessa RRSIG-poster är dock oanvändbara om inte DNS-resolvers har ett sätt att verifiera signaturerna. Zonoperatören måste också göra sin offentliga ZSK tillgänglig genom att lägga till den på sin namnserver i en DNSKEY-post.

När en resolver begär en viss posttyp (t.ex. AAAA), returnerar namnservern också motsvarande RRSIG-poster. Resolvern kan sedan hämta DNSKEY-posten som innehåller den offentliga delen av ZSK från namnservern. Tillsammans kan RRset, RRSIG och ZSK validera svaret.

Om vi ​​litar på zonsigneringsnyckeln i DNSKEY-posten kan vi lita på alla poster i zonen. Men vad händer om zonsigneringsnyckeln äventyras? Vi behöver ett sätt att validera ZSK.

Nyckelsigneringsnycklar (KSK)

Förutom en zonsigneringsnyckel har DNSSEC-namnservrar även en nyckelsigneringsnyckel (KSK). KSK validerar DNSKEY-posten på exakt samma sätt som vår ZSK säkrade resten av vårt RRset i föregående avsnitt: Den signerar den offentliga ZSK (som lagras i en DNSKEY-post) och skapar en RRSIG för DNSKEY.

Precis som ZSK, publicerar namnservern den offentliga delen av KSK i en annan DNSKEY-post, vilket ger oss DNSKEY RRset. Både den offentliga delen KSK och den offentliga delen ZSK är signerad av det privata delen av KSK. Resolvers kan sedan använda den offentliga delen av KSK för att validera den offentliga delen av  ZSK.

Validering för resolvers ser nu ut så här:

1. Begär önskad RRset, som också returnerar motsvarande RRSIG-post.
2. Begär DNSKEY-posterna som innehåller den offentliga ZSK och offentliga KSK, som också returnerar RRSIG för DNSKEY RRset.
3. Verifiera RRSIG för den begärda RRset med den offentliga ZSK.
4. Verifiera RRSIG för DNSKEY RRset med den offentliga KSK.

Naturligtvis kan DNSKEY RRset och motsvarande RRSIG-poster cachelagras, så att DNS-namnservrarna inte ständigt bombarderas med onödiga förfrågningar.

Varför använder vi separata zonsigneringsnycklar och nyckelsigneringsnycklar? Som vi kommer att diskutera i nästa avsnitt är det svårt att byta ut en gammal eller komprometterad KSK. Att byta ZSK är å andra sidan mycket lättare. Detta gör att vi kan använda en mindre ZSK utan att kompromissa med säkerheten på servern, vilket minimerar mängden data som servern måste skicka med varje svar.

Vi har nu etablerat förtroende inom vår zon, men DNS är ett hierarkiskt system och zoner fungerar sällan oberoende. För att komplicera saker ytterligare, signeras nyckelsigneringsnyckeln av sig själv, vilket inte ger något ytterligare förtroende. Vi behöver ett sätt att koppla ihop förtroendet i vår zon med dess föräldrazon.

Delegation Signer Records

DNSSEC introducerar en DS-post (delegation signer) för att möjliggöra överföring av förtroende från en överordnad zon till en underordnad zon. En zonoperatör hashar DNSKEY-posten som innehåller den offentliga delen av nyckelsigneringsnyckeln (KSK) och ger den till den överordnade zonen för att publicera den som en DS-post.

Varje gång en resolver hänvisas till en underordnad zon tillhandahåller den överordnade zonen också en DS-post. Denna DS-post är hur resolvers vet att den underordnade zonen är DNSSEC-aktiverad. För att kontrollera giltigheten av den underordnade zonens offentliga KSK hashar resolvern den och jämför den med DS-posten från förälderzonen. Om de matchar kan resolvern anta att den offentliga KSK inte har manipulerats, vilket innebär att den kan lita på alla poster i den underordnade zonen. Så etableras en förtroendekedja i DNSSEC.

Observera att varje ändring i KSK också kräver en ändring av föräldrazonens DS-post. Att ändra DS-posten är en process i flera steg som kan sluta med att zonen  slutar fungera om den utförs felaktigt. Först måste föräldern lägga till den nya DS-posten, sedan måste de vänta tills TTL för att den ursprungliga DS-posten ska löpa ut innan de tar bort den. Det är därför det är mycket lättare att byta ut zonsigneringsnycklar än nyckelsigneringsnycklar.

Förtroendekedjan

Vi har ett sätt att etablera förtroende inom en zon och koppla den till dess överordnade zon, men hur litar vi på DS-posten? DS-posten är signerad precis som alla andra RRset, vilket betyder att den har en motsvarande RRSIG i förälderzonen. Hela valideringsprocessen upprepas tills vi kommer till förälderns offentliga KSK. För att verifiera det måste vi gå till den förälderns DS-post, och vidare och vidare går vi upp i förtroendekedjan.

Men när vi äntligen kommer till rootzonen har vi ett problem: det finns ingen överordnad DS-post att validera mot. Det är här vi får se en mänsklig sida av det globala Internet.

I Root Signing Ceremony samlas flera utvalda individer från hela världen och signerar rootzonens DNSKEY RRset på ett mycket offentligt och granskat sätt. Ceremonin producerar en RRSIG-post som kan användas för att verifiera rotnamnserverns offentliga KSK och ZSK. Istället för att lita på den offentliga KSK på grund av förälderns DS-post, antar vi att den är giltig eftersom vi litar på säkerhetsprocedurerna kring åtkomst till den privata KSK.

Möjligheten att skapa förtroende mellan föräldra- och barnzoner är en integrerad del av DNSSEC. Om någon del av kedjan är bruten kan vi inte lita på posterna vi begär eftersom en man i mitten kan ändra posterna och dirigera oss till vilken IP-adress de vill ha.