dnssec en säkerhetsförbättring av dns -en studie om svenska kommuners syn på...

Examensarbete

Henric Telling och Anders Gunnarsson

2010-11-29

Ämne: Datalogi

Nivå: Kandidatexamen inom datalogi

Kurskod: 2DV00E

DNSSEC en säkerhetsförbättring av DNS

-en studie om Svenska kommuners syn på

DNSSEC

Författare: Henric Telling och Anders Gunnarsson

Handledare: Ola Flygt

Examinator: Mathias Hedenborg

i

Sammanfattning

Syftet med uppsatsen är att undersöka varför få svenska kommunerna valt att installera

DNSSEC på sina domäner. DNS är en av de viktigaste protokollen på Internet och

behövs för att sammanlänka IP-adresser med mer lättförståeliga adresser för oss

människor. DNS skapades utan att tänka på säkerheten, för att kunna göra DNS säkrare

utvecklades ett säkerhetstillägg till DNS detta fick namnet DNSSEC.

Vi har använt oss av litteraturstudie, experiment och intervjuer för att skapa en

djupare kunskap och förståelse om hur DNS och DNSSEC fungerar samt besvara varför

få kommuner har valt att installera DNSSEC.

Under vår litteraturstudie läste vi om flera sårbarheter i DNS och hur dessa kan

utnyttjas för att utsätta en organisation för attacker såsom cacheförgiftning och MITM.

Vi testade dessa sårbarheter och bekräftade det. Efter installationen av DNSSEC kunde

inte angreppen längre genomföras i vår testmiljö.

Under intervjuerna kom vi fram till att den vanligaste orsaken att kommuner inte

väljer att installera DNSSEC är okunskap om tillvägagångsättet för en installation och

att de tycker deras nuvarande DNS fungerar bra, det blir då ingen prioriterad fråga.

Kommunerna som installerat DNSSEC är nöjda med sin installation och bara en

kommun har upplevt problem vid införandet.

För att vi ska kunna fortsätta utveckla Internet är en kontroll av säkerheten en

nödvändighet och då är DNSSEC en vägvisare. Kommunerna borde föregå med gott

exempel och vara bland de första som inför DNSSEC så besökarna till deras hemsidor

kan känna sig säkra att informationen på deras sidor är korrekt.

Nyckelord: DNS, DNSSEC, IP, Säkerhet, Cache, MITM, Internet, .SE, ARP, Intrång,

Windows, Server, DoS.

ii

Abstract

The purpose of this paper is to investigate why few Swedish municipalities have chosen

to install DNSSEC on their domains. DNS is one of the most important protocols on the

Internet and used to link IP-addresses to understandable addresses for users. DNS was

created without thinking about security, to make DNS more secure a security extension

was developed to DNS, named DNSSEC.

We have used literature review, experiments and interviews to create a deeper

knowledge and understanding about DNS and DNSSEC, how it works and why few

municipalities have chosen to install DNSSEC.

In the literature we read about several vulnerabilities in DNS and it can easily be

exposed to attacks such as cache poisoning and MITM. We tested these vulnerabilities

and confirmed them. After installation of DNSSEC we could not expose our

implemented DNS anymore in our test environment.

During the interviews, we concluded that the most common reason why

municipalities do not choose to install DNSSEC is ignorance of an installation and they

think that their current DNS works well and it does not become a priority. The

municipalities that have installed DNSSEC are satisfied with its installation and only

one municipality has experienced difficulties during the implementation.

In order for us to continue developing the Internet a control of security is a necessity

and DNSSEC is a good example. Local authorities should lead by good example and be

among the first to implement DNSSEC, so users of their websites can be assured that

the information on their pages is accurate.

Keywords: DNS, DNSSEC, IP, Security, Cache, MITM, Internet, .SE, ARP, Intrusion,

Windows, Server, DoS.

iii

Förord

Uppsatsen är en kandidatuppsats inom datalogi på institutionen för datavetenskap, fysik

och matematik på Linnéuniversitetet i Växjö. Uppsatsen omfattar 15 högskolepoäng och

utfördes under höstterminen 2010.

Arbetet inriktas mot kommuner och vi vill tacka de kommuner som valt att ställa upp

för intervju vilket gjort vårt arbete möjligt. Vi vill tacka Växjö-, Gävle-, Gislaved-,

Älmhult-, Lund- och Leksands kommun. Vi vill även tacka enskilda personer som på

sitt sätt bidragit till uppsatsen.

Ola Flygt, Linnéuniversitetet – Kontinuerlig handledning som bidragit med goda

råd samt diskussioner och under arbetets gång.

Fredrik Ringberg, Växjö kommun – Första kontaktperson inom en kommun som

bidragit med många tips för vidare kontakter för intervjuer.

Håkan Larsson, Wexnet – Bidrog med att bjuda in oss på föreläsning om

DNSSEC från ett företag som tillhandahålla tjänsten.

Växjö, 2010-11-29

Henric Telling

Anders Gunnarsson

iv

Innehåll

1. Inledning ....................................................................................................................... 1

1.1 Bakgrund ................................................................................................................. 1

1.2 Syfte ........................................................................................................................ 2

1.3 Tidigare forskning ................................................................................................... 2

1.4 Avgränsningar ......................................................................................................... 2

1.5 Målgrupp ................................................................................................................. 2

1.6 Rapportstruktur ....................................................................................................... 2

2. Metod ............................................................................................................................ 3

2.1 Litteraturstudie ........................................................................................................ 3

2.2 Experiment .............................................................................................................. 3

2.3 Fallstudie ................................................................................................................. 3

2.3.1 Intervju ............................................................................................................. 4

3. DNS .............................................................................................................................. 5

3.1 Introduktion ............................................................................................................ 5

3.2 Trädstrukturen i DNS .............................................................................................. 5

Figur 3.1 : Visualisering av DNS-trädstruktur. ......................................................... 5

3.3 Auktoritativa namnservrar, zoner och zonfiler ....................................................... 5

3.4 DNS-uppslagning .................................................................................................... 6

3.5 Mellanlagring .......................................................................................................... 7

3.6 Säkerhetsbrister ....................................................................................................... 8

3.6.1 Man-in-the-middle ........................................................................................... 8

3.6.2 Cacheförgiftning............................................................................................... 9

3.6.3 DoS-attacker ................................................................................................... 10

3.6.4 Visualisering av sårbarheterna inom DNS ..................................................... 11

4. DNSSEC ..................................................................................................................... 12

4.1 Varför DNSSEC ................................................................................................... 12

4.2 Hur fungerar DNSSEC ......................................................................................... 12

4.3 Lösningar till DNS- säkerhetsbrister .................................................................... 14

4.4 Säkerhetsbrister i DNSSEC .................................................................................. 14

4.5 DNSSEC validering för användare ....................................................................... 14

5. DNSSEC i Sverige och världen .................................................................................. 15

5.1 Historik ................................................................................................................. 15

5.2 Checklista för implementation av DNSSEC ......................................................... 16

v

5.3 Olika produkter för att installera DNSSEC .......................................................... 17

5.3.1 Microsoft Server 2008 R2 DNS ..................................................................... 17

5.3.2 BIND .............................................................................................................. 17

5.2.3 OpenDNSSEC ................................................................................................ 17

6. Installation av DNS och DNSSEC i testmiljö ............................................................ 18

6.1 Syfte ...................................................................................................................... 18

6.2 Planering ............................................................................................................... 18

6.2.1 Faktorer .......................................................................................................... 18

6.3 Installation av DNS ............................................................................................... 19

6.3.1 ARP och DNS-förgiftnings attack.................................................................. 21

6.3.2 DNS-cache förgiftningsattack ........................................................................ 23

6.3.3 DoS-attack ...................................................................................................... 26

6.3.4 Intrång i Windows Server 2003 ..................................................................... 26

6.5 Installation av DNSSEC ....................................................................................... 27

6.5.1 ARP och DNS-förgiftningsattack................................................................... 29

6.5.2 DNS-cache förgiftningsattack ........................................................................ 30

6.5.3 DoS-attack ...................................................................................................... 30

6.5.4 Intrång i Windows Server 2008 ..................................................................... 31

7. Resultat ....................................................................................................................... 32

7.1 Intervjuer ............................................................................................................... 32

7.1.1 Intervjuresultat ............................................................................................... 32

7.2 Statistik ................................................................................................................. 33

8. Analys och Diskussion ............................................................................................... 35

8.2 Framtida forskning ................................................................................................ 36

Referenser ....................................................................................................................... 37

Appendix A – Ordlista .................................................................................................... 41

Appendix B – DNS-post definition ................................................................................ 44

vi

Figur- och tabellförteckning

Figur 3.1 : Visualisering av DNS-trädstruktur. ................................................................ 5

Figur 3.2 : Visualisering av en DNS-uppslagning från en användare. ............................. 7

Figur 3.3 : Visualisering av sårbarheterna inom DNS under DNS-uppslagning. .......... 11

Figur 4.1 : Visualisering av NSEC-uppslagning mellan olika namnservrar. ................. 13

Figur 5.1 : Karta med kommuner med DNSSEC [44]. .................................................. 16

Figur 6.1 : Testmiljöns infrastruktur för implementering av DNS. ................................ 19

Tabell 6.1 : Visar egenskaper och inställningar för varje nod i infrastrukturen för

implementering av DNS. ................................................................................................ 20

Figur 6.2 : Resultat av angripen DNS-server med dig-kommando. ............................... 22

Figur 6.3 : Resultat av icke-angripen DNS-server med dig-kommando. ....................... 22

Figur 6.4 : Resultat av porttest för DNS-server 1. .......................................................... 23

Figur 6.5 : Ansatta parametrar i Metasploit inför attack. ............................................... 24

Figur 6.7 : Korrupt svar från DNS-server 1 med nslookup. ........................................... 25

Figur 6.8 : Korrupt svar från DNS-server 2 med dig...................................................... 25


implementering av DNSSEC. ......................................................................................... 28

Figur 6.9 : Domänen www.lab är säkrad med DNSSEC och visar en godkänd

validering. ....................................................................................................................... 29

Figur 6.10 : Säkert DNS-svar innehållande RRIG för domänen www.lab. ................... 29

Figur 6.11 : Domänen www.lab är säkrad med DNSSEC och visar därför att sidan är

korrupt. ........................................................................................................................... 30

Figur 6.12 : Resultat av porttest för DNS-server 1. ........................................................ 30

Figur 7.1 : Visar antalet registrerade DNSSEC-domäner under de senaste 90 dagarna. 33

Figur 7.2 : Visar antalet registrerade DNSSEC-domäner vid de 15 senaste månaderna.34

Figur B.1 : Visar DNS-postformatet och dess fält.......................................................... 44

Tabell B.1 : Förklaring av definierade fält för DNS-poster. .......................................... 44

Tabell B.2 : Förklaring av definierade TYPE värden. .................................................... 45

Tabell B.3 : Förklaring av definierade QTYPE värden. ................................................. 45

Tabell B.4 : Förklaring av definierade CLASS värden. ................................................. 45

Tabell B.5 : Förklaring av definierade QCLASS värden. .............................................. 45

Figur B.2 : Visar SOA-format. ....................................................................................... 46

Tabell B.6 : Förklaring av definierade SOA värden. ...................................................... 47

Figur B.4 : Visar de olika fälten i pakethuvudet............................................................. 47

Tabell B.7 : Förklaring av definierade fält pakethuvudet. .............................................. 48

Figur B.5 : Visar format för en DNS-fråga. ................................................................... 48

Tabell B.8 : Förklaring av definierade fälten i DNS-frågan. .......................................... 49

Figur B.6 : Visar DNS-postformatet och dess fält.......................................................... 49

Tabell B.9 : Förklaring av definierade fält i en DNS-post. ............................................ 49

1

1. Inledning

Detta kapitel presenterar arbetets bakgrund, syfte, tidigare forskning, avgränsningar,

målgrupp och förklarar rapportens struktur.

En av de viktigaste tjänsterna som får Internet att fungera är DNS (Domain Name

System). DNS är ett protokoll som mappar datorernas IP-adresser till förståeliga

adresser för oss användare. DNS är skapat i dess enklaste form och innehåller många

säkerhetsbrister. Paketen som skickas med DNS kan enkelt stoppas eller förvrängas och

på så sätt visar användaren fel information. DNSSEC (DNS Security Extention) är

lösningen för de flesta säkerhetsbrister i DNS då DNSSEC skapar integritet samt

bevisar äkthet för paketen med hjälp av digitala signaturer [1]. Trots att denna

säkerhetsförbättring funnits tillgänglig sedan ett par år tillbaka visar undersökningar och

statistik att bara ett fåtal valt att implementera DNSSEC. Anne-Marie Eklund Löwinder

som är kvalitets- och säkerhetsansvarig på den svenska toppdomänen .SE håller med om

att säkerheten är dålig bland kommunerna och att kunderna som använder deras e-

tjänster riskerar att bli lurade [2].

1.1 Bakgrund

Varje dator som är uppkopplad mot Internet har en egen IP (Internet Protocol) -adress,

dessa behövs för att vi ska kunna skicka datatrafik mellan datorerna. För att göra det

lättare att komma ihåg IP-adresserna har de tilldelats domännamn. DNS är kopplingen

mellan IP-adresser och domännamnen [8].

DNS kan ses som en telefonbok för Internet. För att besöka en hemsida skrivs

adressen in i webbläsaren och då sker en DNS-uppslagning, programvaran som utför

DNS-uppslagningen åt användaren kallas resolver. När detta är gjort skickas

informationen tillbaka till datorn som efterfrågade informationen och datorn kan sedan

tillgå den efterfrågade hemsidan.

DNS skapades utan säkerhetsaspekter och det finns en rad kända hot mot DNS och

alla dessa ses som allvarliga attacker, de kan skada användarna på Internet och göra att

organisationen tappar kontroll över sin hemsida [45]. DNS innehåller säkerhetsbrister

och IETF (Internet Engineering Task Force) ger exempel på angrep som kan

förekomma emot DNS i RFC (Request For Comments) 3833 [3].

I november 1993 arrangerade IETF en sammankomst där de diskuterade DNSSEC

som skulle lösa säkerhetsproblemen inom DNS. Målen var att skapa något som var

bakåtkompatibelt med DNS, skapa dataintegritet, dataautentisering samt innehålla

digitala signaturer [3]. Mars 1999 publicerade IETF RFC 2535 och DNSSEC hade

skapats [4].

Trots att DNSSEC skapades för 11 år sedan finns det fortfarande ett stort antal

företag och myndigheter som har bristfällig DNS-säkerhet. Den svenska toppdomänen

.SE förespråkar implementeringen av DNSSEC på de svenska domänerna. De utför

varje år undersökningar för att utreda ”hälsoläget” för Internet och undersöker hur

implementeringen av DNSSEC fortskrider [5].

2

1.2 Syfte

Syftet är att undersöka varför ett fåtal har valt att implementera DNSSEC när den finns

tillgänglig och kan förebygga attacker.

Hur fungerar DNS och DNSSEC?

Fördelar och nackdelar med DNSSEC?

Hur genomförs en installation av DNS och DNSSEC?

Vad finns det för säkerhetshot i DNS och DNSSEC?

Varför väljer inte fler kommuner att övergå till DNSSEC?

1.3 Tidigare forskning

Under de tre senaste åren har IIS (Stiftelsen för Internetinfrastruktur) som är ansvariga

för Sveriges toppdomän .SE utfört undersökningar om svenska domäner. Målet med

deras rapporter är att undersöka kvalitén och nåbarheten i domänsystemet inom .SE-

zonen. Under 2009 testades 663 domäner och 867 unika servrar. Resultaten visar att 23

procent lider av allvarliga fel och 34 procent genererar felmeddelanden och markeras

med en varning. Exempel på felmeddelanden i rapporten kan vara om namnservern är

rekursiv eller att enbart en namnserver används [5]. Domänerna som testades är inte

enbart kommuner.

1.4 Avgränsningar

Vi kommer att inrikta oss mot svenska kommuner som ingår i toppdomänen .SE.

1.5 Målgrupp

Vi riktar oss mot personer som har kandidatexamen eller liknade inom ämnet datalogi.

Vi riktar oss även till personer som är sakkunniga inom området.

1.6 Rapportstruktur

Första kapitlet beskriver uppsatsens bakgrund och syfta samt tidigare forskning inom

ämnet. Andra kapitlet beskriver uppsatsens val av ansats. Motivering samt förklaringar

av valda metoder finns under detta kapitel. Tredje kapitlet förklarar DNS teoretisk, hur

DNS fungerar samt dess säkerhetsbrister. Fjärde kapitlet förklarar DNSSEC teoretiskt,

hur DNSSEC fungerar samt kvarstående säkerhetsproblem. Femte kapitlet beskriver det

aktuella läget av införande av DNSSEC i Sverige och världen. Sjätte kapitlet förklarar

och beskriver vår testmiljö där vi installerat DNS och DNSSEC samt utfört olika typer

av angrepp mot DNS. Resultat och tillvägagångssätt förklaras. Sjunde kapitlet

representeras vårt resultat utifrån intervjuer samt aktuell statistik över införande av

DNSSEC i Sverige. Åttonde kapitlet redovisar våra slutsatser utifrån vår undersökning.

Vi presenterar även förslag på tillvägagångssätt för ett ökat införande av DNSSEC samt

förslag på fortsatt forskning inom området.

3

2. Metod

Detta kapitel förklarar och motiverar arbetets metodik. I kapitlet beskrivs varje

delmoment i arbetet och motiveras varför de används.

Tidigare forskning från IIS påvisar en kvantitativ undersökning där resultatet visas i

form av statistik. De har utfört tester och experiment vilket visar en kvantitativ

undersökning [6]. Vi kommer att ta del tidigare kvantitativ forskning för att utföra en

kvalitativ och empirisk undersökning där vi skall skaffa oss en djupare förståelse för

verkligheten i form av vetenskapliga artiklar, egna experiment samt intervjuer.

2.1 Litteraturstudie

En litteraturstudie ingår i den kvalitativa forskningsprocessen. Litteraturstudien ger en

överblick av tidigare samlade kunskaper inom området vilket skapar en större förståelse

för problemen. Studien ger stöd vid problemformuleringen eftersom en bredare

överblick av problemen skapas [6].

Vi kommer utföra en litteraturstudie av vetenskapliga artiklar som publicerats samt

böcker inom ämnet för att skapa en bättre förståelse för problem och begrepp inom valt

ämne.

2.2 Experiment

Experiment används för att lokalisera orsakssamband samt förklara vad olika fenomen

beror på. Ett experiment är en fix design vilket innebär att inget kan ändras under

experimentets gång. Frågeställning som vad ska analyseras? Vilket syfte? ska

definieras. Utifrån frågeställningen formuleras en hypotes, ett antagande om det som

ska undersökas. I planeringen måste faktorer som kan påverka undersökningen anges i

form av oberoende variabler [15].

Vi kommer genomföra experiment genom att installera en DNS-server samt angripa

den med kända attacker. En DNSSEC-server kommer även installeras för att skapa oss

en egen uppfattning om implementering av DNSSEC. Eftersom vi även kommer utföra

en fallstudie anser vi att ett experiment inom området krävs för att förstå den realistiska

miljön.

2.3 Fallstudie

En fallstudie används för att undersöka ett fenomen i dess realistiska miljö. Dess

omständigheter tilltalar och passar det kvalitativa perspektivet. Fallstudier anses särskilt

bra att tillämpa då studien är komplex. Målet är att förklara samt förstå organisationer

och dess system. En fallstudie behöver inte inrikta sig mot enbart ett fall, utan flera fall

kan undersökas i samma studie [6]. Fallstudien ger kunskaper på djupet och designen är

flexibel där ändringar av frågor och inriktning under studiens gång kan förändras.

Fallstudien använder sig av intervjuer vilket vi kommer utnyttja [15].

En fallstudie är en passande studie då vår frågeställning inriktar sig mot olika

kommuner. Eftersom vi redan vet att de kommuner vi ska undersöka skiljer sig mot

varandra passar denna studie. Den ger oss flexibilitet under studiens gång och vi

behöver undersöka flera olika fall där utsagorna skiljer sig från varandra.

4

2.3.1 Intervju

En intervju kan utformas på olika sätt, de finns strukturerade, halvstrukturerade och

öppenriktade intervjuer. En strukturerad intervju kan ses som en muntlig enkät där en

fördefinierad frågelista finns och den följs till punkt och pricka. Halvstrukturerad har en

uppsättning av frågor som används som ett stöd genom intervjun där ordningen och

formuleringarna kan variera. I en öppenriktad intervju låts den intervjuande till stor del

styra vad som ska tas upp [15].

Vi kommer använda oss av halvstrukturerade intervjuer eftersom vi behöver anpassa

intervjufrågorna utifrån den intervjuande därför valde vi att inte använda oss av enkäter.

Halv-strukturen ger oss den bästa möjligheten att genom intervjuer utreda vår

frågeställning. En strukturerad intervju är inte möjlig eftersom varje fall skiljer sig från

mängden och genom en öppenriktad intervju kan vi inte strukturera vår frågeställning på

ett effektivt sätt. Datainsamlingen sker genom ljudinspelning på ett ljudmedium för att

sedan transkriberas till skriven text för senare analys.

5

3. DNS

Detta kapitel förklarar hur DNS-protokollet är uppbyggt och hur det fungerar. Även

DNS säkerhetsbrister förklaras i form av olika angrepp som kan utföras emot DNS.

3.1 Introduktion

DNS-protokollet används för att översätta datorernas IP-adresser till mer förståeliga

adresser för oss människor. DNS är en distribuerad databas med hierarkisk struktur som

är uppdelat i zoner [7]. En distribuerad databas betyder att all information fördelas

mellan flera olika serverar. Hierarkistrukturen innebär att all information lagras i en

trädstruktur. Designen av DNS ger ett snabbt uppslag om vilken IP-adress som tillhör

ett domännamn, detta görs med hjälp av en namnserver [8].

3.2 Trädstrukturen i DNS

Figur 3.1 visar en visualisering av DNS-trädstruktur. I toppen av trädet finns enbart en

nod, den kallas root. En nivå ner i trädstrukturen finns noderna vilka benämns som

toppdomäner där bland annat .SE ingår. Varje nod i trädet tilldelas ett domännamn

förutom root-noden och en punkt används för att avgränsa noderna. På så sätt kan en

sökväg skapas vilket leder rakt genom trädet. Exempel på en sökväg som även figur 3.1

illustrerar är www.exempel.se.

Trädstrukturen där samtliga noder ingår benämns som domännamnrymd där alla

domäner för hela Internet ingår. För varje domän som ingår i domännamnrymden finns

en auktoritativ namnserver [8].

Alla färgade noder i figur 3.1 visar att de ingår i .SE-domänen. De tre mörkare

noderna ingår i exempel.se-domänen och den allra mörkaste ensamma noden tillhör

www.exempel.se-domänen.

Figur 3.1 : Visualisering av DNS-trädstruktur.

3.3 Auktoritativa namnservrar, zoner och zonfiler

En namnserver som ansvarar för en domän benämns som en auktoritativ namnserver.

Namnservers uppgift är att översätta domännamnet till en IP-adress. Eftersom DNS

6

består av en hierarkis struktur behöver inte toppdomänen .SE lagra all information om

underliggande noder eftersom ansvaret kan delegeras till flera olika auktoritativa

namnservrar. Dessa namnservrar innehåller bara information om en del av sin domän

och benämns som en zon [8].

Varje namnserver som ansvar för en zon lagrar en zonfil vilket innehåller

information om alla domännamn som ingår i domänen, så mappningen från domännamn

till IP-adresser kan ske. Zonfilen är uppdelad i DNS-poster där varje post innehåller

information om varje enskilt domännamn. Namnservern använder DNS-posterna för att

svara på olika frågor om varje domän som resolver ställer. En DNS-överföring kan ses

som en serie av frågor och svar mellan två aktörer, resolver och namnservern. Aktörerna

som integrerar är programvaror hos klienten och servern [9].

3.4 DNS-uppslagning

En DNS-uppslagning går till på så sätt att resolvern ställer frågan om vilken IP-adress

ett specifikt domännamn har, namnservern svarar med information som finns lagrat.

Teoretiskt tolkas det att enbart en fråga ställs med ett svar. Det som sker är att resolvern,

vilket kan vara en användares webbläsare till exempel kontaktar en stubb-resolver som

innehåller en lista av rekursiva-resolvers som antingen vet vilken namnservern som har

informationen eller vidarebefordrar frågan till en annan zon [9]. Skillnaden mellan

stubb-resolver och en rekursiv-resolver är att rekursiva-resolvers genomför en DNS-

uppslagning genom att ställa frågan om domännamnet om och om igen tills den får svar.

Stubb-resolvern ställer frågan om domännamnet en gång till en rekursiv-resolver [8].

Om den aktuella zonen inte har informationen eller IP-adressen som efterfrågas

kommer den rekursiva namnservern söka efter informationen högs upp i hierarkin, till

root där vidare sökningar sker ner i DNS-trädet tills antingen ett svar kan ges eller

returneras ett felmeddelande [9].

Figur 3.2 illustrerar en DNS-uppslagning och nedan följer en förklaring om vad som

sker vid de olika stegen [8].

1. En användare anger adressen www.exempel.se i sin webbläsare.

2. Stubb-resolvern i användarens dator frågar den rekursiva-resolvern vilken IP-

adress som motsvarar domänen www.exempel.se.

3. Den rekursiva-resolvern vidarebefordrar frågan högre upp i hierarkin, till root.

4. Uppslag i root-serverns zonfil indikerar att .SE-domäner är delegerade till .SE-

zonen. Root-servern svarar med en hänvisning till auktoritativservrarna för .SE-

zonen.

5. Resolvern upprepar frågan till auktoritativservrarna för .SE-zonen.

6. Uppslag i auktoritativservrarnas zonfil för .SE-zonen visar att example.se har

delegerats och .SE-namnserver svarar med en hänvisning till de

auktoritativservrarna som pekas ut för domännamnet.

7. Resolvern upprepar frågan igen till de utpekade auktoritativa servrarna för

exampel.se.

8. Auktoritativa servern för example.se svarar med IP-adressen som motsvarar

www.example.se.

7

9. Den rekursiva servern vidarebefordrar IP-adressen till stubb-resolvern i

användarens dator.

10. Stubb-resolvern vidarebefordrar IP-adressen till webbläsaren.

11. Webbläsaren ansluter till webbservern med den mottagna IP-adressen och

hemsidan laddas ner till användarens dator.

Alla steg är nödvändiga om det inte finns lagrad information om vilka zoner eller

namnservrar som ansvarar för en angiven domän sedan tidigare.

Figur 3.2 : Visualisering av en DNS-uppslagning från en användare.

3.5 Mellanlagring

Mellanlagring används för att förhindra att DNS-uppslagningarna blir tidkrävande samt

undvika onödig datatrafik över nätverket [8]. DNS-uppslag som lyckas når sällan rooten

i DNS-trädet. Svaren på resolverns fråga lagras oftast i cacheminnet på namnservern

längre ner i trädet. Exempelvis hos användarens Internetleverantör [9].

Utifrån tidigare underrubrik DNS-uppslagning har användaren redan efterfrågat IP-

adressen för domänen www.exempel.se där IP-adressen returnerades. Utifrån det

exemplet har resolvern mellanlagrat informationen i cacheminnet som gavs från root-

servern. Därmed finns det lagrat vilka namnservrar som är auktoritativa servrar inom

.SE-zonen. Frågan ställs direkt till en av .SE-namnservrar och svaret returneras

snabbare.

Ett annat scenario kan uppstå då resolvern nyligen besvarat en fråga om ett annat

domännamn som slutar på exampel.se, till exempel ftp.exempel.se. Då finns svaret från

.SE-zonens namnserver lagrat i cacheminnet om vilken auktoritativ server som

8

besvarade frågan tidigare och frågan kan ställas direkt till den auktoritativa servern

ansvarig för exampel.se.

Scenario tre kan uppstå då resolvern tidigare besvarat en fråga om www.exempel.se.

Då finns svaret från den auktoritativa servern om domännamnet lagrat i cacheminnet

och resolvern kan svara direkt viken IP-adress som motsvarar www.exempel.se.

Hur länge denna information lagras beror på vilken värde zonen har ansatt för TTL

(Time To Live) [8].

3.6 Säkerhetsbrister

Det vanligaste tillvägagångsättet för att hantera säkerhetshål i DNS är att uppdatera

implementerad mjukvara vilket enbart skapar temporärt uppskov tills nästa säkerhetshot

uppstår. Alla säkerhetshot i DNS varierar men dess egenskap att utnyttja DNS svagheter

är lika [7]. Nedan följer beskrivning av de huvudsakliga säkerhetshoten.

3.6.1 Man-in-the-middle

MITM (Man In The Middle) -attack är möjlig eftersom resolvern erhåller svar från

DNS-servern och kan inte utföra någon äkthetsbevisning eller verifiering av integriteten

för paket den tar emot. Den enda äkthetsbevisningen resolven kan utföra är kontrollera

IP-adressen från DNS-servern, destination- samt källport och DNS-överförings-ID. En

angripare kan enkelt matcha dessa parametrar genom manipulation och klienten kan inte

göra mer än att tilltro paketen och ta emot. Således kan angriparen lösa berättigade

frågor och svara med falsk information [10].

3.6.1.1 Paketavlyssning

Överföringen som sker med frågor och svar i DNS är osignerade och skickas med

okrypterade UDP (User Datagram Protocol) -paket och en angripare kan enkelt avlyssna

DNS-överföringen [3]. Genom att avlyssna DNS-frågan från resolvern kan angriparen

generera ett svar tillbaka till resolvern innan den tilltänkta DNS-servern hinner svara.

Angriparen kan modifiera svaret och resolvern har ingen säkerhetsmekanism som utför

äkthetsbevisning av källan för att veta om svaret blivit manipulerat [10].

Säkerhetsmekanismer som TSIG (Transaction SIGnature) och IPSec är möjligt att

implementera men belastningarna för varje DNS-överföring skulle öka vilket skapar

instabilitet mellan de olika parterna, resolvern och DNS-servrarna. Implementeringen

skulle heller inte skapa något förtroende eftersom de bara genererar hop-by-hop

integritet och ingen end-to-end integritet mellan parterna [3].

En MITM-attack involverar en tredje part, angriparen genskjuter kommunikationen

mellan de andra två parterna, servern och klienten vilket vanligtvis uppnås genom ARP

(Address Resolution Protocol) -förgiftning inom en LAN (Local Area Network) miljö.

Dataöverföringar använder MAC (Media Access Control) -adresser som opererar på

datalänklagret av TCP (Transmission Control Protocol) /IP-stacken för att översätta IP-

adresser till MAC-adresser. Protokollet som används vid denna översättning är ARP.

MAC-adressen krävs för att nätverksenheter ska kunna kommunicera med varandra.

Dessa nätverksenheter måste kunna skicka och ta emot MAC-adresser [24].

ARP hanterar två olika typer av paket, ARP-förfrågningar och ARP-svar. Den nod

som vill veta MAC-adressen till mottagarnoden broadcastar en APR-förfrågan ut över

9

nätverket. Mottagarnoden med den angivna IP-adressen besvarar frågan med sin MAC-

adress genom ett ARP-svar i unicast. Noden som ställde ARP-förfrågan lagrar svaret i

sitt lokala cacheminne (ARP-tabell) genom att para ihop IP-adressen och MAC-

adressen i par om (IP, MAC) [25].

ARP-protokollet innehåller ingen autentiseringsmekanism vilket inte förhindrar en

angripare från att skicka förfalskade ARP-svar, de förhindrar inte heller att vem som

helst kan besvara ARP-förfrågningar. När en angripare omdirigerar trafiken till en

annan dator inom samma LAN tillåts den att genomföra detta utan att någon

autentisering sker. En ARP-spoofing attack sker när angriparen skickar ett förfalskat

ARP-svar genom att låtsas ha IP-adressen som efterfrågas. Detta leder till att den

förfrågande mellanlagrar fel adress i sin ARP-tabell och ständigt skickar data till

angriparen utan att vara medveten om att det sker. DNS-cacheförgiftning är en

konsekvens av MITM-attacker [24].

3.6.1.2 Gissa överförings-ID

DNS använder till största del UDP-protokollet vid överföring. Det är enkelt för en

angripare att generera paket som matchar UDP-protokollets parametrar. ID-fältet i

DNS-huvudet är ett 16-bitars fält och serverns UDP-port associeras med DNS som har

en välkänd port vilket kan vara en av 232

olika kombinationer. Spannet mellan olika

kombinationer är inte tillräckligt stort för att undvika brute-force attacker. I praktiken

kan klientens UDP-port och ID-numret förutses från tidigare överföringar och det är inte

ovanligt att klientens port är av ett fixt värde med tanke på brandväggar och andra

restriktioner. Därför kan spannet frekvent reduceras till 216

olika kombinationer.

Eftersom denna attack är beroende av att förutse resolverns beteende lyckas den oftast.

En korrekt gissning av överförings-ID: et är inte tillräckligt för att injicera korrupt data.

En kombination av kännedom eller gissning av frågetypen (QTYPE) och fråga

angående domännamnet (QNAME) gör att resolvern har svårt att skilja på korrekt eller

korrupt data. I de flesta avseenden likar denna attack en paketavlyssning. Denna attack

är mer komplex än paketavlyssning eftersom attacken fungerar enbart då antagandena är

korrekta, attacken är dock enklare eftersom angriparen inte behöver befinna sig på

samma nätverk [3].

3.6.2 Cacheförgiftning

DNS använder cacheminnet för att effektivisera DNS-förfrågningar. DNS-protokollet

stödjer inget effektivt sätt att uppdatera DNS-servrarnas cacheminne [10]. Därför kan en

angripare utnyttja svagheten genom att förse den rekursiva resolvern med falsk

information om domänens IP-adress. Uppgifterna lagras i resolverns cacheminne där

TTL-värdet kan ansättas av angriparen. När användaren ställer en förfrågan om

domänen kommer ett det felaktiga svaret skickas till användaren. Domänen med den

felaktiga IP-adressen kan leda till en förfalskad hemsida där användarens ges fel

information eller luras att ange känslig information [8].

De flesta namnbaserade attackerna kan delvis mildras genom långvariga kontroller

av DNS-poster i relevans till originalförfrågan, dock räcker inte skyddet till gentemot

Name-Chaining-attacker. Det finns flera olika varianter på denna attack men de som

10

involveras i alla är DNS-poster vars DNS-data (RDATA) innehåller ett DNS-namn,

eller i vissa fall inte alls innehåller något DNS-namn utan direkt mappar till ett korrupt

DNS-namn. Genom dessa DNS-poster kan angriparen injicera felaktiga adresser till

användarens cacheminne och därmed omdirigera efter angriparens tycke [3].

Värsta exemplen av detta är DNS-posterna CNAME, NS och DNAME för att de kan

omdirigera offrets DNS-frågor vilket angriparen väljer. DNS-poster som MX och SRV

är inte lika farliga, men kan i princip också utlösa ytterligare uppslagningar som

angriparen väljer. DNS-posterna A och AAAA använder inte DNS-namn i sina DNS-

data (RDATA) men eftersom in-addr.arpa och IP6.arpa indexeras för DNS-kodning av

IPv4 och IPv6 kan även dessa DNS-poster användas för Name-Chaining-attacker [3].

Generellt sett sker en attack på följande sätt [3]:

1. Offret ställer en DNS-förfrågan.

2. Angriparen injicerar ett svar exempelvis via paketavlyssning vilket ska leda till

att användaren någon gång i processen skall ges fel information.

3. Angriparen svar innehåller en eller flera DNS-poster med DNS-namn i deras

RDATA. Beroende på vilken typ av attack kan angriparen antingen injicera falsk

data till användarens cacheminne eller omdirigera till en server angriparen

väljer.

En angripare som injicerar DNS-poster i användarens cacheminne kan alltid

åstadkomma någon form av skada [3].

3.6.3 DoS-attacker

Liksom många andra nätverkstjänster är DNS såbar för DoS (Denial of Service) -

attacker. DNS-servrar riskerar även att bli använda som DoS-förstärkare eftersom

svarspaketen för DNS tenderar att vara större än paketen där DNS-förfrågan ställs [3].

En angripare kan förgifta en ARP-tabell för en användare på så sätt att varje paket

användaren skickar skickas till angriparen istället för den tilltänkta destinationen. Då

kan angriparen blockera kommunikationen för användaren [25]. DNS-servrar är inte

särskilt utsatta för DoS-attacker så länge DNS-servern tilldelas tillräckligt med minne.

En DNS-server kan snabbt svara på DNS-frågor om den är auktoritativ [26].

Den 21 oktober 2002 utsattes alla 13 root-servrar samtidigt för en DDoS (Distributed

Denial of Service) -attack. Volymen av attacken var uppskattningsvis 50 till 100

Mbits/sek per root-server. Attacken resulterade att flera root-servrar blev otillgängliga

från flera parter av det globala Internet, flera serverar var dock nåbara från samtliga

övervakningsstationer under attacken. Det finns inga rapporter att slutanvändarna

uppmärksammande några felmeddelanden. Eftersom DNS-protokollet är konstruerat för

att klara viss nåbarhet bland namnservrarna kan det uppstått förseningar om ett antal

sekunder vid namnuppslagningar. För ovanlighetens skull var denna attack riktat mot

samtliga root-servrar, denna typ av attack brukar annars riktas mot en enskild root-

server. Systemet fungerade efter dess design och demonstrerade robusthet mot

synkroniserade attacker mot alla root-servrar [27].

11

3.6.4 Visualisering av sårbarheterna inom DNS

Figur 3.3 visualiserar var i DNS-uppslagningen sårbarheterna finns [40]. Nedan

förklaras de olika sårbarheterna.

1. MITM-attack och cache-förgiftning för lokala IP-adresser genom till exempel

ARP- och DNS-spoofing i kapitel 6.2.1.

2. Samma som ovan.

3. Gissa överförings-ID samt injicera felaktiga paket.

4. Samma som 1 och 2.

5. Gissa överförings-ID samt injicera felaktiga paket.

6. Administratören kan tillhanda hålla en korrupt zonfil, antigen av misstag eller

medvetet.

7. En felaktig zonfil kan returneras till användaren. Gissa överförings-ID samt

injicera felaktiga paket.

8. MITM-attack och Cache-förgiftning för lokala IP-adresser genom till exempel

ARP- och DNS-spoofing i kapitel 6.2.1.

Figur 3.3 : Visualisering av sårbarheterna inom DNS under DNS-uppslagning.

12

4. DNSSEC

Under detta kapitel kommer vi att förklara hur DNSSEC är uppbyggt och hur tekniken

fungerar. Vi kommer även att gå in på hur DNSSEC är tänkt att lösa säkerhetsbristerna

i DNS och vilka återstående problem som finns i DNSSEC.

4.1 Varför DNSSEC

DNS är en av de viktigaste bitarna i Internet och utan fungerande DNS: er fungerar inte

Internet. Problemet med DNS är att det saknar implementering av säkerhet och kan på

så sätt utsätta användarna för sårbarheter. Därför var en utveckling av säkerhetspaket

nödvändigt för att säkerställa tillförlitligheten och utveckling av Internet. Detta

säkerhetstillägg kallas DNSSEC och lägger till en krypterad signatur till DNS-data som

skickas [11].

Ett av de största problemen med DNS var att de inte tänkte på säkerheten när de

utvecklade DNS-protokollet. IETF uppmärksammande problemet med den bristande

säkerheten i DNS och ordnade i november 1993 en sammankomst där huvudmålet var

att ta fram en lösning till säkerhetsbristerna i DNS. Det dröjde fram till 1999 innan de

publicerade RFC 2535, detta dokument beskriver DNSSEC [3]

En av de största bristerna i DNS är att det ger en möjlighet för en angripare att lägga

till en falsk DNS-server vilket gör att användarna som skriver in en adress i

webbläsaren tror att de kommer till den riktiga sidan men i själva verket lotsas de till en

helt annan sida som angriparen väljer, detta gör att användarna kan bli utsatta för

nätfiske [11].

4.2 Hur fungerar DNSSEC

Det är framför allt tre säkerhetsbrister i DNS som DNSSEC är skapat för att åtgärda,

dessa är ursprunglig autentisering, dataverifiering och verifiera denial-of-existence.

Detta är tänkt att lösas genom att lägga till en digital krypterad signatur från svaren som

skickas från DNS-servern [14].

Det är viktigt att kunna garantera att användaren kommer till den sidan som

webbadressen anger. DNS kontrollerar aldrig om data som skickas kommer från den

servern som den utger sig att vara ifrån. Så länge port och TXID fälten matchar med den

efterfrågade adressen från användaren. För att lösa detta problem implementerar

DNSSEC en PKI (Public Key Infrastrucure) som gör att en resolver kan få tillgång till

en publik nyckel från en DNSSEC signerad zon och med hjälp av denna kan den

kontrollera att signerad data kommer från rätt zon [13].

För att kunna garantera att data från DNS-svaren är äkta skapar varje zon två nycklar,

en publik nyckel och en privat nyckel [12]. Den publika nyckeln sparas i en ny RR

(Resource Record) som kallas DNSKEY och innehåller den binärkodade nyckeln som

tillsammans med relevant information om nyckeln som vad det är för

krypteringsalgoritm som har används [13]. Varje RRSet använder sig av den privata

nyckeln för att skapa signaturer, dessa sparas i en RR som kallas RRSIG [13]. När

sedan den svarar på en förfrågan skickar DNS tillbaka både RRSIG och RRSet som är

associerad med data som ställdes i frågan. Resolvern måste har lärt sig DNSKEY: n från

13

den efterfrågade zonen och kan då verifiera att svarsdata är äkta och inte har blivit

modifierad på vägen [12].

De två olika nycklarna som används för signering i zonerna kallas för ZSK (Zone

Signing Key) och KSK (Key Signing Key) och de skapas av zonadministratörerna.

Zonen signeras med ZSK och så blir ZSK signerad av KSK [12]. För att resolvern inte

ska behöva tillhandahålla en publik nyckel för varje signerad zon och att varje zon inte

ska behöva skicka sin publika nyckel till alla vid ändringar av sina nycklar då skapas

chain-of-trust och detta görs med en DS (Delegation Signer) RR som delar upp zonerna

i förälder- och barnzoner, så när en zon uppdaterar eller ändrar sin nyckel skickar barn-

zonen nyckeln till sin förälderzon. Detta gör att varje förälder kan signera sina barn och

på så sätt garantera säkerheten i kedjan, detta gör även att resolvern inte behöver

tillhandahålla de signerande nycklarna från varje zon utan bara från root-zonerna [16].

På detta sätt ska DNSSEC lösa problemet med ursprungautentisering för att garantera

att data som kommer i DNS-svaret är äkta och kommer fram utan att de ska ha blivit

störda på vägen. Men DNSSEC ska även kunna tillhandahålla funktioner som löser

denial-of-existence detta görs genom att implementerar ytligare en RR, som heter

NSEC, den listar alla namnservrar som ett företag har listat och vilket som är den nästa i

listan [13]. Figur 4.1 visas hur NSEC fungerar, ett företag har tre olika namnservrar.

a.namnserver.se pekar på b.namnserver.se och vidare så pekar b.namnserver.se på

d.namnserver.se.

Figur 4.1 : Visualisering av NSEC-uppslagning mellan olika namnservrar.

Om en resolver efterfrågar c.namnserver.se försöker namnservern göra uppslaget men

misslyckas eftersom det inte finns någon c.namnserver.se, istället hittar den

a.namnserver.se och då skickar den tillbaka svaret a.namnserver.se på detta sätt NSEC

d.namserver.se och sedan får resolver att förstå att det inte finns någon b.namnserver.se

[16].

NSEC var den första versionen som skapades för att förutse denial-of-existence. Ett

av problemen med NSEC är att den skickat svaren i klartext och gör att en angripare kan

14

få tillgång till information om företaget. För att förhindra detta utvecklades NSEC3 som

är en hashad och krypterad variant av NSEC [12].

4.3 Lösningar till DNS- säkerhetsbrister

Paketavlyssning är ett problem i DNS, om DNSSEC är korrekt konfigurerad och

används på rätt sätt kan det skapa en end-to-end integritetskontroll. Då kan verifiering

att data som skickas från servern bli kontrollerad att den inte har blivit modifierad på

vägen till klienten. DNSSEC har inget skydd mot ändring av pakethuvuden från DNS,

för att kontrollera detta måste resolvern vara konfigurerad för just detta ändamål. Det

gäller även för attacker där angriparen gissar överförings-ID, där emot när resolvern

kontrollerar signaturerna i DNS-svaren kan dessa attacker upptäckas [3].

Cacheförgiftning ska DNSSEC erbjuda ett bra skydd emot genom att med hjälp av

resolvern kontrollera signaturen och kan på så sätt bestämma om data som skickas i

DNS-svaren verkligen kommer från rätt avsändare [3].

4.4 Säkerhetsbrister i DNSSEC

Även om DNSSEC är ett säkerhetstillägg är det inte lösningen på alla problem. Ett av

DNSSEC största problem är att det är ett väldigt komplext system som kräver stor

skicklighet från zonadministratörerna för att utföra implementeringen av DNSSEC och

den bristfälliga rapporteringen av fel som kan uppstå gör att felsökning i DNSSEC

försvåras [3].

Med DNSSEC ökar arbetsbördan för resolvern eftersom varje paket med signaturer

ska valideras, detta medför att tiden som en uppslagning tar kommer att öka och det

kommer att ta längre tid att kunna ge svar tillbaka till klienten. Detta ökar risken för

time-out. Användare med bristande tålamod som kanske ställer en ny fråga för att det

tar för lång tid att få svar gör att bördan på resolvern kommer att öka. På grund av detta

hjälper DNSSEC inte heller mot DoS-attacker utan gör problemet värre [3].

DNSSEC kan inte heller kontrollera att zonfiler är korrekta. Dessa kan ändras av en

zonadministratör antingen medvetet eller omedvetet [20].

4.5 DNSSEC validering för användare

För användare som vill kontrollera om sidor de besöker använder sig av DNSSEC så är

möjligheter för att göra detta automatisk väldigt dåligt. Användare som vill kontrollera

sidor så kan man använda .SE alternativt DNSCHECK där man får reda på om den

sökta sidan använder sig av DNSSEC eller inte [42].

Om man vill ha ett alternativ som automatiskt kontrollerar om sidan som man

besöker använder sig av DNSSEC så har Firefox ett tillägg till sin webbläsare som

automatiskt validerar sidan som man besöker [43].

15

5. DNSSEC i Sverige och världen

Detta kapitel beskriver DNSSEC historia samt förklarar olika implementerings

alternativ.

5.1 Historik

Även om DNSSEC har funnits tillgänglig en länge tid har införandet av tekniken gått

väldigt långsamt i världen. Trots detta är Sverige och den svenska toppdomänen.SE en

av de länderna som ligger långt fram med införandet och är ett föregångsland för resten

av Internetvärlden. Sverige var det första land att signera sin root-zon och detta gjordes

2005. Januari 2007 lanserade .SE tjänsten DNSSEC vilket gör att alla som har en

domän under .SE-domänen kan tillgå den förbättrade säkerhet som DNSSEC erbjuder

[19].

Under 2007 när .SE hade lanserat sin DNSSEC-tjänst började de även arbeta hårdare

med att få domännamnsägarna att bli mer intresserade av DNSSEC och få dem att byta

från DNS till DNSSEC. De började även göra en undersökning varje år där de

undersöker hälsoläget i den Svenska .SE-zonen. I rapporten som släpptes 2007 gjordes

det ingen kontroll av hur många domäner som använde sig av DNSSEC men det gjordes

året därpå och detta visade att 2008 var det totalt 891 domäner i den svenska .SE-zonen

som hade infört DNSSEC men av dessa var det bara åtta kommuner och två statliga

myndigheter som hade infört DNSSEC [21].

2008 upptäckte forskaren Dan Kaminsky en bugg i DNS som gjorde att välden fick

upp ögonen för DNSSEC och eftersom att .SE då låg i framkant med införandet av

DNSSEC så riktade väldens blickar mot Sverige. Kaminskybuggen är en form av

cacheförgiftning. I Sverige fortsätter antalet domäner som använder sig av DNSSEC att

öka. När rapporten 2007 kom var det totalt 891 domäner som hade DNSSEC nu har den

siffran ökat till 2000, ökningen är kontinuerlig enligt .SE men det går inte i samma takt

som de hade hoppats på [22]. Denna ökning av antal domäner som ansluter sig till

DNSSEC förväntas öka väldigt mycket under 2010 detta för att den 15 juli 2010 så

signerades root-zonen och detta tror de ska leda till att fler länder får upp ögonen för

fördelarna med DNSSEC [23].

I Figur 5.1 ses en karta över de kommuner som i dagsläget implementerat DNSSEC

på sin domän.

16

Figur 5.1 : Karta med kommuner med DNSSEC [44].

5.2 Checklista för implementation av DNSSEC

För att installera DNSSEC på sin domän finns det en del steg som måste göras innan

DNSSEC är redo och kan användas.

Göra en DNS-uppsättning på önskad hårdvara och programvara som stödjer

DNSSEC. Detta kan vara Microsoft Server 2008 R2, BIND (Berkeley Internet

Name Domain) eller någon liknade.

Aktivera DNSSEC för sin zon.

Skapa nycklar som kommer att användas vid signering av zonen. Det kommer

att behövas två stycken nycklar en KSK och en ZSK.

Signera zonen.

Publicera nyckeln till domänmansregistrator.

Nu ska zonen vara signerad med DNSSEC och färdig för användning [18,31].

17

5.3 Olika produkter för att installera DNSSEC

Det finns idag olika alternativ som kan användas vid installation av DNSSEC och

tillvägagångssättet vid signering av zonen. Ofta vill kommuner, företag och

myndigheter behålla sin nuvarande DNS-infrastruktur utan att behöva installera en ny.

Därför är det viktigt att det finns lösningar för alla typer av system [32].

5.3.1 Microsoft Server 2008 R2 DNS

Eftersom Windows Server 2003 bara tillhandahöll grundläggande stöd för DNSSEC var

det många som hoppades att Windows Server 2008 R2 skulle innehålla bättre support

för DNSSEC. Microsoft har utvecklat Windows Server 2008 R2 med fullständigt stöd

för DNSSEC. Trots att Windows Server 2008 R2 har stöd för det mesta saknas det

fortfarande stöd för NSEC3 och kan inte signera dynamisk uppbyggda zoner som AD

(Active Directory) bygger kring [17,32].

5.3.2 BIND

BIND är den mest använda tekniken för DNS över Internet. BIND utvecklades under

1980-talet på University of California. Den klarar av det mesta som en DNS ska göra,

den svarar på frågor som skickas till den och den gör det med de DNS-protokoll

standarder som finns. BIND är kompatibelt med DNSSEC ifrån version 9. BIND är en

fri programvara som vem som helst får använda, den går under en ICS-licens vilken gör

att den är fri att använda, kopiera, modifiera och distribuera [34,35].

5.2.3 OpenDNSSEC

För att öka införandet av DNSSEC bestämde .SE att utveckla ett alternativ som

användare kunde använda för införande av DNSSEC. Denna lösning skulle göra det

enklare att installera DNSSEC för webbhotell, Internetleverantörer och toppdomäner att

införa DNSSEC. Syftet med OpenDNSSEC var att förenkla administrationen av

DNSSEC, med hjälp av OpenDNSSEC ska många steg automatiseras. OpenDNSSEC

kan bara användas för att införa DNSSEC, den har alltså ingen egen DNS utan det

måste redan finnas installerat [36,37].

18

6. Installation av DNS och DNSSEC i testmiljö

Detta kapitel förklarar och visar vår testimplementering av DNS och DNSSEC.

Tidigare nämnda säkerhetsbrister i DNS testas i form av praktiska angrepp och visar

vad en implementering av DNSSEC skyddar mot.

6.1 Syfte

Syftet är att skapa oss en bredare uppfattning om hur DNS och DNSSEC fungerar samt

testa det olika säkerhetsbristerna. Syftet är också att undersöka hur komplex en

testimplementering av DNSSEC är. En hypotes är att kommuner, myndigheter och

företag inte installera DNSSEC eftersom en implementation är för komplex.

6.2 Planering

Vi kommer installera DNS med operativsystemet Windows Server 2003 RS SP2 och

använda grundinställningarna. DNSSEC installeras med Windows Server 2008 R2

eftersom det innehåller stöd för en installation av DNSSEC, en annan anledning är att

Windows Server 2008 R2 är det senaste serveroperativsystemet från Microsoft [17]. Vi

kommer att installera en DNS-server, därefter utsätta servern för attacker som är kända

som säkerhetsbrister i DNS-protokollet. Därefter installerar vi DNSSEC på DNS-

servern och utsätter den för samma attacker och utvärderar resultaten. Installationen av

DNSSEC kommer ske i olika steg enligt Microsoft egna checklista för applicering av

DNSSEC [18].

6.2.1 Faktorer

Här specificeras de faktorer vi tar hänsyn till under experimentet och vilken effekt som

behandlas.

Behandling är den faktor vi kommer undersöka effekten av i experimentet [15]. Vi

kommer undersöka skillnaden på DNS och DNSSEC genom att utsätta servern för

attacker. Vi kommer även behandla hur komplex ett införande av DNSSEC är.

Oberoende variabler är de faktorer som kan påverka experimentet [15]. Faktorer som

kan påverka vårt experiment:

Kommuner, myndigheter och företag behöver ytterligare resurser för att

emigrera från DNS till DNSSEC vilket är tidskrävande och ökar komplexiteten.

Experimentservrarna kommer inte vara lika belastad som en DNS-server för ett

företag eller likande och datorresurserna kan variera.

Beroende variabler är de faktorer vi mäter resultatet för experimentet [15]. Faktorer

vi kommer mäta resultatet på:

Hur en installation av DNS sker i Windows Server 2003 R2 SP2.

Hur en installation av DNS och DNSSEC sker i Windows Server 2008 R2.

Praktisk tillämpa attacker mot säkerhetsbristerna i DNS-protokollet.

Hur komplext DNSSEC är att installera i Windows Server 2008 R2.

19

6.3 Installation av DNS

Under experimentet utförde vi olika typer av attacker och därför upprättades en

testmiljö för att inte skada någon DNS-server i drift. Figur 6.1 visualiserar vår

uppsättning av DNS-serverar och klienter för att möjliggöra DNS-uppslag.

Figur 6.1 : Testmiljöns infrastruktur för implementering av DNS.

20

Nod Datorspecifikation Programvaror DNS-server

DNS-server

1

Dell Latitude D620

Intel Core 2 1.66 GHz

2GB RAM

Windows Server 2003 R2 Standard

IIS 6.0

192.168.1.43

DNS-server

2

Dell OptiPlex 745


1 GB RAM


192.168.2.2

(Forwarder)

192.168.1.43

Klient 1 AMD Athlon X2 6000+ 3.01 GHz

6 GB RAM

Windows 7

192.168.1.43

Klient 2 Packar Bell Easynote

AMD Athlon X2 1.90 GHz

3 GB RAM

Windows 7

192.168.2.3

Klient 3 Compaq Mini 311 1.6 GHz

Intel Atom

2 GB RAM

Windows 7

192.168.2.6

Angripare 1 VirtualBox

1024 MB RAM

Bryggat nätverkskort

Backtrack 4 R1


512 MB RAM


Backtrack 4 R1

Router 1 NETGEAR Wireless-N 150 Router

WNR 1000

Router 2 Siemens Gigaset SE361 WLAN


implementering av DNS.

21

6.3.1 ARP och DNS-förgiftnings attack

Mål

Målet med attacken är att vilseleda Klient 2 till en förfalskad hemsida som angriparen

administrerar utifrån testmiljön i figur 6.2. Klient 2 använder DNS-server 2 för DNS-

uppslag och angreppet görs mot DNS-server 2.

Tillvägagångssätt

Vi skapade en textfil (hosts.txt) som innehåller raden:

192.168.2.9 www.orsa.se

Sedan körde vi följande kommandon:

arpspoof –i eth0 –t 192.168.2.2 192.168.2.1

arpspoof –i eth0 –t 192.168.2.1 192.168.2.2

dnsspoof –i eth0 –f hosts.txt host 192.168.2.2

Första och andra kommandot används för att DNS-server 2 (192.168.2.2) skall tro att

angriparen (192.168.2.9) är routern så all dess utgående trafik skickas till angriparen.

Tredje kommandot avlyssnar all DNS-trafik från DNS-server 2 och alla DNS-frågor

som involverar www.orsa.se kommer besvaras av angriparen enligt filen host.txt.

Resultat

Detta leder till när Klient 2 anger www.orsa.se i sin webbläsare kommer inte den

förväntade hemsidan visas utan Angriparens hemsida laddas istället. Angriparen kan på

så sätt visa fel information och införskaffa sig känslig information om användaren vid

Klient 2. Klient 2 använder kommandot:

dig @192.168.2.2 www.orsa.se

Resultatet i figur 6.2 visar att den angripna DNS-servern (192.168.2.2) pekar på

angriparens IP-adress när DNS-förfrågan om www.orsa.se ställs. Om Klient 2 istället

använder kommandot:

dig @192.168.1.43 www.orsa.se

Figur 6.3 visar att den icke-angripna DNS-servern (192.168.1.43) pekar på den korrekta

IP-adressen till www.orsa.se. Klient 3 och alla andra klienter som använder DNS-server

2 för DNS-uppslagningar är därmed också utsatta för attacken. Detta är en MITM-attack

och DNS-server 2 pekar egentligen på rätt IP-adress till domänen www.orsa.se. Men

eftersom angriparen avlyssnar DNS-server 2 DNS-förfrågningar kan den avläsa när en

fråga ställs om www.orsa.se och då svarar den med dess felaktiga IP-adress till

angriparen. I figur 3.3 placeras angriparen mellan ISP (Internet Service Provider)

Resolver Server (DNS-server 2) där den avlyssnar frågorna (2) och besvarar dessa med

sina egna paket (3) och användaren tolkar att svaren är korrekta utan att någon

validering sker.

22

; <<>> DiG 9.3.2 <<>> @192.168.2.2 www.orsa.se

; (1 server found)

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1317

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;www.orsa.se. IN A

;; ANSWER SECTION:

www.orsa.se. 60 IN A 192.168.2.9

;; Query time: 1 msec

;; SERVER: 192.168.2.2#53(192.168.2.2)

;; WHEN: Mon Oct 04 16:13:33 2010

;; MSG SIZE rcvd: 45

Figur 6.2 : Resultat av angripen DNS-server med dig-kommando.

; <<>> DiG 9.3.2 <<>> @192.168.1.43 www.orsa.se

; (1 server found)


;; Got answer:




;www.orsa.se. IN A

;; ANSWER SECTION:

www.orsa.se. 85376 IN CNAME plaza.daladatorer.se.

plaza.daladatorer.se. 549 IN A 62.101.37.56


;; SERVER: 192.168.1.43#53(192.168.1.43)

;; WHEN: Mon Oct 04 15:28:40 2010


Figur 6.3 : Resultat av icke-angripen DNS-server med dig-kommando.

23

6.3.2 DNS-cache förgiftningsattack

Mål

Målet med attacken är att förgifta DNS-server 1 DNS-cache så att den och dess

användare får korrupta DNS-uppslagningar.


Vi började med att använda ett webbaserat verktyg som används för att kontrollera

sårbarheten hos den DNS-server som används [29]. Figur 6.4 visar resultatet av detta

test för DNS-server 1 och ger oss informationen om att vi skall använda port 1046 under

vår attack. Figur 6.4 visar alltså det som diskuterats tidigare, att DNS enbart använder

ett fåtal portar och att överförings-ID: et enkelt kan beräknas.

Vi använde oss av programmet Metasploit på angriparens dator för att utföra

attacken. De parametrar vi satte var att domännamnet vi skulle kapa var www.mora.se

(HOSTNAME), nya adressen skulle vara 74.125.39.104 (NEWADDR) vilket är

www.google.se, servern att angripa var 192.168.1.43 (RHOST) och porten att använda

var 1043 (SRCPORT). Figur 6.5 visar de ansatta parametrarna i Metasploit.

När parametrarna var satta körde vi igång programmet med kommandot run vilket

sätter igång attacken genom att angriparen skickar förfalskade DNS-förfrågningar till

DNS-server 1. Figur 6.6 visar resultatet av attacken, det krävdes 29750 förfrågningar

och 651000 svar innan DNS-servers 1 DNS-cache var förgiftad.

Figur 6.4 : Resultat av porttest för DNS-server 1.

24

Figur 6.5 : Ansatta parametrar i Metasploit inför attack.

Figur 6.6 : Resultat av DNS-cache förgiftningsattack mot DNS-server 1.

25

Resultat

Attacken resulterar i att DNS-server 1 mellanlagrar en korrupt adress till www.mora.se.

Eftersom DNS-cache: en används för snabbare DNS-uppslag utnyttjas den korrupta

adressen tills dess TTL har passerat och DNS-server 1 samt alla dess användare svaras

med en korrupt adress. Både 192.168.1.1 och 192.168.2.1 nätverket påverkas av denna

förgiftning efter som DNS-server 1 används för DNS-uppslagning av samtliga

underliggande datorer.

Figur 6.7 visar med hjälp av kommandot nslookup att klient 1 besvaras med ett

korrupt svar från DNS-server 1. Figur 6.8 visar med hjälp av kommandot dig att klient 2

besvaras med ett korrupt svar från DNS-server 2.

C:\Users\Henric>nslookup www.mora.se

Server: UnKnown

Address: 192.168.1.43

Icke-auktoritärt svar:

Namn: www.mora.se

Address: 74.125.39.104

Figur 6.7 : Korrupt svar från DNS-server 1 med nslookup.

; <<>> DiG 9.3.2 <<>> www.mora.se


;; Got answer:




;www.mora.se. IN A

;; ANSWER SECTION:

www.mora.se. 21101 IN A

74.125.39.104


;; SERVER: 192.168.2.2#53(192.168.2.2)

;; WHEN: Fri Oct 08 23:04:59 2010


Figur 6.8 : Korrupt svar från DNS-server 2 med dig.

26

6.3.3 DoS-attack

Mål

Målet med attacken är att överbelasta DNS-server 1 så dess resurser inte kan användas

av varken sig själv eller dess användare.


Vi använde programmet Ettercap för att utföra vår DoS-attack. Först scannade vi efter

klienter på nätverket för finna möjliga mål, vi väljer att angripa router 1 och DNS-server

1. Därefter scannar Ettercap vilka portar som är sårbara för denna attack, resultatet

visade att portarna 53, 80, 135, 139 och 445 kunde utnyttjas för en attack. Angripare 1

startar en DoS-attack genom Ettercap och anger måldators IP-adress samt en förfalskad

IP-adress inom nätverket, exempelvis 192.168.1.88 vilket används för att DNS-server 1

skall uppfatta denna IP-adress som korrekt och därför tillsätta alla sina resurser att

besvara dess frågor till en adress som alltså inte finns.

Resultat

Denna attack resulterade i att varken DNS-server 1 eller dess underliggande användere

kunde nå Internet. På så sätt kan ingen av datorerna i nätverken 192.168.1.1 eller

192.168.2.2 ställa några DNS-förfrågningar.

6.3.4 Intrång i Windows Server 2003

Mål

Målet med attacken är att komma åt zonfilen som är lagrad i vår server för att sedan

göra så att den pekar på en helt annan IP-adress.


Även till denna attack använder vi programmet Metasploit med hjälp av detta utnyttjar

vi en sårbarhet som orsakar en buffer owerflow i NetApi32. Från angriparens dator

försöker vi att få tillgång till filerna i DNS-server 2 för att på så sätt kunna ändra i

dennes zonfiler och göra så att den skickar förfrågningar till andra IP-adresser istället

för den korrekta.

Det första som ska göras är att köra en scanner mot datorn som görs med kommandot

NMAP på följande sätt.

nmap 192.168.2.2

NMAP är en portskanner som används i detta fall för att ta reda på information om

datorn som ska attackeras. Därefter används Metaspolit i kommandoläge. Där väljs

exploiten ms08_067_netapi med kommandot.

Use windows/smb/ms08_067_netapi

Efter detta så sätter vi payloaden med följande kommando.

set payload generic/shell_bind_tcp

Vi ska nu ställa in vilken server vi vill utföra attacken emot med kommandot.

set RHOST 192.168.2.2

Sedan kör vi attacken med kommandot.

27

exploit

Nu får vi fram lite information om servern som vi ska utföra attacken emot. Metasploit

lyckas inte automatiskt finna operativsystemet som vi vill attackera så det får vi

specificera själva.

show targets

Vi får nu upp en fullständig lista över de olika operativsystemen med olika

språkpacksalternativ. Vårt system är ett Windows Server 2003 med engelskt språkpack

så vi väljer den i listan.

set target 10

Och sedan kör vi attacken igen med kommandot.

rexpolit

När denna sedan har kört färdig så får vi tillgång till servern.

Resultat

Attacken lyckas och vi får kontroll över DNS-server 2. På angriparens dator visas nu ett

kommandofönster och för att kontrollera att det fungerar som det är tänkt så skapar vi

en mapp på skrivbordet och granskar vi servern ses att mappen ligger där. Nu navigerar

vi oss in till zonfilerna som ligger i Windows/System32/dns på DNS-server 2. Dessa

filer ha vi nu full kontroll över och kan ändra dem som vi vill. Men eftersom att vi har

full kontroll över datorn så kan vi även utnyttja läget till att göra mer förstörelse på

servern. Det var förhållandevis lätt att utföra attacken eftersom att det fanns många

guider för hur de skulle utföras. Men detta är en standardinstallation av Windows Server

2003 så vi använde oss inte av några tilläggsprogram för att förhindra intrång i servern

Microsoft släppte även en säkerhetsuppdatering som förhindrade att denna attack skulle

gå att genomföra på ett uppdaterat system.

6.5 Installation av DNSSEC

Infrastrukturen är densamma som testimplementeringen av DNS i kapitel 6.3, se figur

6.1. Skillnaden är operativsystemen för DNS-server 1 och 2, se tabell 6.2 för egenskaper

och inställningar för var enskild nod.

28

Nod Datorspecifikation Programvaror DNS-server

DNS-server

1

Dell Latitude D620


2GB RAM


IIS 7

192.168.1.43

DNS-server

2

Dell OptiPlex 745


1 GB RAM


192.168.2.2

(Trusted A)

192.168.1.43

Klient 1 AMD Athlon X2 6000+ 3.01 GHz

6 GB RAM

Windows 7

192.168.1.43

Klient 2 Packar Bell Easynote

AMD Athlon X2 1.90 GHz

3 GB RAM

Windows 7

192.168.2.3

Klient 3 Compaq Mini 311 1.6 GHz

2 GB RAM

Windows 7

192.168.2.6


1024 MB RAM


Backtrack 4 R1


512 MB RAM


Backtrack 4 R1

Router 1 NETGEAR Wireless-N 150 Router

WNR 1000

Router 2 Siemens Gigaset SE361 WLAN


implementering av DNSSEC.

Vi äger ingen registrerad .SE-domän därför skapade vi en testmiljö med DNSSEC där

DNS-server 1 och 2 signerar dess zoner och DNS-server 2 erhåller DNS-server 1 som

en tillförlitlig enhet för att skapa chain-of-trust relation däremellan. Kapitel 5.1

beskriver en checklista hur införandet stegvis appliceras för en registrerad domän, vi

utförde det fyra första stegen och använde Microsofts handbok för införande av

DNSSEC [30]. För validering av de besökta domänerna användes ett tillägg i

webbläsaren Firefox [33].

Figur 6.9 visar validering av domänen www.lab Klient 2 besöker. Valideringen visar

att Klient 2 är säkrad med hjälp av DNSSEC för den angivna domänen och användaren

kan besöka den på ett säkert sätt. Figur 6.10 visar med hjälp av kommandot dig svaret

på DNS-förfrågan för domännamnet www.lab, svaret innehåller RRSIG.

29

Figur 6.9 : Domänen www.lab är säkrad med DNSSEC och visar en godkänd

validering.

; <<>> DiG 9.3.2 <<>> @192.168.2.2 www.lab +dnssec

; (1 server found)


;; Got answer:


;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags: do; udp: 4000


;www.lab. IN A

;; ANSWER SECTION:

www.lab. 3571 IN A 192.168.1.43

www.lab. 3571 IN RRSIG A 5 2 3600

20101119100133 20101020100133 60172 lab.

Sq0KfcWZ9txhe5EcEpOTP1SwP8qBLv9nN1pWudQ5yVLv/0eA9YomJwWX

nFADyXDP1uJwPDmMsu8BnBWztfNDtg==


;; SERVER: 192.168.2.2#53(192.168.2.2)

;; WHEN: Wed Oct 20 14:42:20 2010


Figur 6.10 : Säkert DNS-svar innehållande RRIG för domänen www.lab.

6.5.1 ARP och DNS-förgiftningsattack

DNSSEC förhindrar denna attack. Figur 6.9 visar när användaren besöker domänen

www.lab när DNS-server 2 inte är angripen. Figur 6.11 visar när användaren besöker

domänen www.lab och DNS-server 2 är angripen då angriparens hemsida visas istället

för originalet.

30

Figur 6.11 : Domänen www.lab är säkrad med DNSSEC och visar därför att sidan

är korrupt.

6.5.2 DNS-cache förgiftningsattack

Denna attack fungerade inte under vår testmiljö. Windows Server 2008 R2 innehåller

säkerhetsförbättringar gentemot Windows Server 2003, som till exempel Socket Pool

och Cache Locking vilket försvårar attacken, figur 6.4 och 6.12 visar skillnaden mellan

resultaten för Windows Server 2003 och 2008. Tidigare använda webbaserade verktyget

för kontrollering av sårbarheterna på namnservern användes och resultatet visas i figur

6.12. Resultaten visar en förbättring av säkerheten och fler resurser krävs för att angripa

DNS-servern utan DNSSEC. För att en angripare skall tillgå fler resurser kan ett botnet

användas, dock kommer DNSSEC motverka en förfalskad hemsida precis som attacken

ovan visar.

Figur 6.12 : Resultat av porttest för DNS-server 1.

6.5.3 DoS-attack

Denna attack ger samma resultat under denna implementation som tidigare test och

DNSSEC motverkar inte attacken mot servers resurser.

31

6.5.4 Intrång i Windows Server 2008

Vi försöker genomföra samma attack som vi lyckades med på Windows Server 2003

men då inte denna sårbarhet finns i Windows Server 2008 fungerar det inte och vi

lyckas inte att få tillgång till filerna på datorn. Det finns säkert andra öppningar i

systemet som en angripare skulle kunna använda.

Även DNSSEC skulle kunna hjälpa till vid dessa attacker, för att kunna åstadkomma

samma sak som vi gjorde i Windows Server 2003 där vi ändrade i zonfilen så att den

pekade på fel adress. Med DNSSEC måste en omsignering av zonen ske och dessa

nycklar som behövs till signeringen ska förvaras på ett säkert ställe som inte ska ha

någon koppling till den angripna datorn. Även om angriparen ändrar zonfilen kommer

den inte kunna signera zonerna och sidan blir otillgänglig. Det som kan hända är att

angriparen förstör så att serven slutar fungera på ett korrekt sätt, men det är mindre

allvarligt än att användare blir omdirigerade till felaktiga sidor.

32

7. Resultat

Under detta kapitel kommer vi att redovisa de resultat som vi har fått fram genom våra

intervjuer. Vi kommer också även att redovisa statistik om hur användningen av

DNSSEC har utvecklas i Sverige under de senaste två åren.

7.1 Intervjuer

Vår första tanke var att intervjua kommunerna i Kronoberg för att få en överblick för

deras resonemang kring DNS och införande av DNSSEC. Då ingen kommun i

Kronoberg implementerat DNSSEC på sin domän och för att vi även ville intervjua

kommuner med DNSSEC valde vi att utöka vårt intervjuområde. Vi har kontaktat

kommuner via mail till intressanta intervjuobjekt, de som svarade och ville ställa upp

bokade vi telefon- eller besökstid för intervju. De som inte svarade på utskicket

kontaktade vi via telefon för att försöka boka en intervju. Det är även två kommuner

som har valt att inte ställa upp på en intervju.

Vi har intervjuat sex kommuner, tre kommuner som infört DNSSEC, två kommuner

som inte infört DNSSEC och en kommun som påbörjat arbetet med att införa DNSSEC.

7.1.1 Intervjuresultat

Kommunerna vi intervjuat hanterar sin DNS på olika sätt, några har hand om sina egna

servrar och bara köpt domännamnet medan andra hyr tjänsten av externa företag.

Av de kommuner som har hand om sina egna servrar har valt olika system och sätt

för att upprätta sina DNS: er. De operativsystem som framför allt används är Windows

Server 2003 och 2008 och då använder de sig av Windows DNS men det är även en

kommun som använder Linux och BIND och en kommun som har allt uppsatt i en

virtuell Linuxmaskin på ett Windows operativsystem.

Det är liknade beslutfattare i alla kommunerna då IT-chefen eller IT-samordnaren

tillsammans med sina tekniker beslutar om en implementation. Det är dock inte många

av de tillfrågade kommunerna som har egen kompetens och då hyrde in en konsult som

införde DNSSEC. Alla kommuner som vi har pratat med känner till DNSSEC och vet

vad den skyddar mot.

Av de kommuner som vi har intervjuat är det bara en som har stött på problem med

införandet av DNSSEC och det är Gävle kommun som även var första kommunen och

troligtvis den första domänen som signerades med DNSSEC. Problemet var att vissa

användare inte kunde komma åt sidan efter att gavle.se hade blivit signerad. Detta

berodde på att Internetkunder som hade Telia och Tele2 som Internetleverantör körde

med BIND 9.4.1 på sina namnservrar och denna version av BIND hade en bugg så att

den satte AD-biten i DNS-protokollet fel och detta gjorde att för vissa hemmanvändarna

fungerade inte DNS-trafiken via deras routrar [38]. Förutom denna incident har ingen av

kommunerna uppmärksammat några problem med implementeringen av DNSSEC.

Tidsperioden kommunerna haft DNSSEC installerat varierar från ett par månader

upp till några år.

Ingen av de kommuner som vi har tillfrågat har märkt att de har blivit utsatta för

någon attack mot sin DNS, men de håller med om att de kan ha varit utsatta för attacker

33

utan att de har märkt det. Det är ingen av kommunerna som har tänkt eller diskuterat

över riskerna som finns kvar med DNSSEC.

De kommuner som ännu inte infört DNSSEC för diskussioner om att införa det men

tycker att dagens tillgängliga tekniker som finns för införande inte passar på deras DNS-

infrastruktur. De kommuner som har infört DNSSEC är det ofta att någon person med

kunskap som påpekat fördelarna med DNSSEC. Det är många kommuner runt

Gävleborgs län som infört DNSSEC och de har fått hjälp av samma person, Torbjörn

Eklöv som själv säger att han leder med 8-7 mot övriga Sverige.

Kostnaden för att införa DNSSEC varierar men det är inga stora kostnader det

handlar om utan oftast en engångskostnad på några tusen samt en liten kostnad för drift

och underhåll. De kommuner som har valt att låta andra företag ha hand om deras DNS

är kostnaden bara ett par hundralappar i månaden beroende på vad för webbhotell som

används och hur många domäner som används.

På frågan om varför det är så få kommuner som valt att införa DNSSEC är svaren

relativt eniga. De flesta tror att det är brist på kunskap som gör att kommunerna inte

väljer att införa DNSSEC. Även att DNSSEC beskrivs som väldigt komplext kan

avgöra. Några tror även att en av anledningen till att det är så lågt intresse kan vara att

det inte är en prioriterad fråga. Många kommuner tycker att deras DNS fungerar bra och

kännar inte av några problem.

7.2 Statistik

Statistiken hämtad från IIS visar att antalet registrerade DNSSEC-domäner ständigt

ökar med tiden. Statistiken visar även att tillväxten verkligen har tagit fart under 2010. I

dagsläget finns det dubbelt så många registrerade DNSSEC-domäner jämfört med 2009

än så länge [39]. Figurerna 7.1, 7.2 och 7.3 visar diagram över tillväxten för DNSSEC i

Sverige och att den ständigt ökar med tiden.

Figur 7.1 : Visar antalet registrerade DNSSEC-domäner under de senaste 90

dagarna.

365037003750380038503900395040004050410041504200

DNSSEC-domäner senaste 90 dagarna

34

Figur 7.2 : Visar antalet registrerade DNSSEC-domäner vid de 15 senaste

månaderna.

Figur 7.3 : Visar antalet registrerade DNSSEC-domäner vid årsskiftet samt

dagsläget.

0

500

1000

1500

2000

2500

3000

3500

4000

4500

DNSSEC-domäner vid månadsslut

0

500

1000

1500

2000

2500

3000

3500

4000

4500

2009 2010

DNSSEC-domäner vid årsskiftet samt dagsläge

35

8. Analys och Diskussion

Vi har genom experiment och litteraturstudier skapat oss en förståelse hur DNS och

DNSSEC fungerar både teoretiskt och praktiskt. DNSSEC är komplext och det är svårt

att skapa sig en uppfattning om hur det fungerar samt förstå tillvägagångssättet för ett

införande genom enbart teoretisk undersökning. Under våra experiment har vi påvisat

att framför allt DNS-protokollet innehåller flera säkerhetsbrister som enkelt kan

utnyttjas genom olika angrepp. Under vår undersökning visas att många säkerhetshot så

som MITM, cacheförgiftning tas bort genom ett införande av DNSSEC. DNSSEC

lägger till en krypterad digital signatur till DNS-data som skickas mellan server och

resolver. Däremot skyddar inte DNSSEC mot DoS-attacker. Validering av hemsidor är

en av de största fördelarna med att införa DNSSEC, besökaren vet att hemsidan som

efterfrågas kommer från rätt källa och inte blivit modifierad eller kapad på vägen och

användaren kan på så sätt säkerställa att denne inte utnyttjas att avslöja känslig

information som i sin tur kan utnyttjas av en angripare. Under litteraturstudien läste vi

att DNS skulle innehålla flera säkerhetsbrister och att DNSSEC skulle säkerställa de

flesta. Resultaten motsvarade förväntningarna under experimenten då vi testade de olika

operativsystemen, Windows Server 2003 och 2008.

I förberedelse till vår fallstudie upptäcktes att väldigt få kommuner valt att införa

DNSSEC. Utifrån våra intervjuer är det framför allt okunskap om vad DNSSEC

skyddar mot och hur införandet av DNSSEC sker som är den största anledningen till att

kommunerna valt att inte införa DNSSEC. Även att den DNS som används för tillfället

fungerar som den ska så ett införande ingen prioriterad fråga. Det skulle kanske ha varit

en prioriterad fråga om de hade råkat ut för någon attack mot sin DNS, för det är ingen

av kommunerna som har märkt av att de har blivit utsatta för någon attack.

De som valt att införa så är det ofta en drivande person inblandad som påpekat

fördelarna med DNSSEC och även hjälpt till med införandet.

Att det inte finns något krav på kommuner att behöva använda DNSSEC kan vara en

bidragande orsak att få kommuner inför DNSSEC. Kanske om ett datum skulle sättas då

alla kommuner var tvungna att använda sig av DNSSEC på sin domän hade påskyndat

införandet. Ett lämpligt förslag är att mindre kommuner hyr ut sin infrastruktur till ett

externt företag som erbjuder DNSSEC då slipper de att ha egen kunskap om hur

signeringen ska gå tillväga.

Det är inte som vi trodde att det var en kostnadsfråga då de intervjuande nämnt att

kostnaden för införande är relativt låg.

Vi tror att kompetensnivån mellan Windows- och Linuxanvändare skiljs åt och

Windowsanvändarna oftast har grafisk installationsvana och i dagsläget erbjuds endast

textbaserad installation av DNSSEC. Detta tror vi kan ha en effekt på det låga antalet

kommuner med DNSSEC, då de flesta kommuner använder Windows.

Under arbetet var det problematiskt att få intervjuer med kommuner utan DNSSEC,

vi tror att det beror på att några av de mindre kommunerna har låg kompetens inom

området och inte förstår vad DNSSEC erbjuder.

Vi har varit i kontakt med de flesta kommuner i Kronobergs län. Ingen av

kommunerna använder sig i dagsläget av DNSSEC men Växjö kommun håller på att

undersöka hur en installation av DNSSEC skulle gå till. Uppvidninge, Lessebo, Alvesta,

36

Tingsryd och Ljungby har valt att inte ställa upp på intervju om deras DNS.

Anledningarna beror på tidsbrist eller bristande sakkunnig inom området. De kommuner

som infört DNSSEC och valt att delta är Gävle-, Leksand- och Gislaveds kommun där

alla varit tillmötesgående och gärna beskrivit deras införande av DNSSEC.

Kommunerna kanske anser att säkerhetshoten mot dem är låga och därför inte inför

DNSSEC. Jämförelse mot svensk banksektorn är kommunerna flitiga att införa

DNSSEC, ingen svensk bank använder idag DNSSEC [41]. Säkerhetshoten borde vara

större gentemot banksektorn och kunderna borde vara mer utsatta, men ändå har ingen

bank infört DNSSEC.

8.2 Framtida forskning

Framtida forskning inom ämnet kan vara att genomföra en liknande undersökning som

denna inom svenska banksektorn där idag ingen bank implementerat DNSSEC. Banker

är som kommuner viktiga delar i vårt samhälle och måste erbjuda säkra tjänster.

Även undersöka hur vidareutbildning av de kommunalanställda beslutsfattare inom

IT-frågor så att de informeras om den senaste tekniken som kommer och på så sätt

kunna vara en förebild för andra organisationer i vårt samhälle.

37

Referenser

[1] S. Krishnaswamy, W.Hardake, R.Mundy. “DNSSEC in Practice: Using DNSSEC-

Tools to Deploy DNSSEC”, Conference For Homeland Security, 2009. CATCH '09.

Cybersecurity Applications & Technology, pp. 3-15, mars 2009.

[2] H.Baltzer. ”Dåligt skydd av kommunernas hemsidor”. IDG, 2010-08-17. [www]

Tillgänglig: http://www.idg.se/2.1085/1.334003/daligt-skydd-av-kommunernas-

hemsidor [Hämtad: 2010-09-01].

[3] D. Atkins. “Threat Analysis of the Domain Name System (DNS)”. ISC, 2004-08.

[www] Tillgänglig: http://www.ietf.org/rfc/rfc3833.txt [Hämtad: 2010-09-01].

[4] D.Eastlake. ”Domain Name System Security Extensions”. IBM, 1999-03. [www]

Tillgänglig: http://www.ietf.org/rfc/rfc2535.txt [Hämtad: 2010-09-01].

[5] Stiftelsen för Internetinfrastruktur. ”Hälsoläget i .SE 2009”. IIS, 2009-11-03. [www]

Tillgänglig: http://www.iis.se/docs/Rapport-Halsolaget-2009-final23.pdf [Hämtad:

2010-09-02]

[6] J.Backman, ”Rapporter och uppsatser”, Upplaga 2. Lund: Studentlitteratur; 2008.

[7] W.C.A. Wijngaards, B.J. Overeinder. ”Securing DNS: Extending DNS Servers with

a DNSSEC Validator”, Security & Privacy, vol 7, pp. 36-43, september/oktober 2009.

[8] B.Raunio, ”DNS - Internets vägvisare: tekniken som leder dig rätt på nätet”.

Stockholm: Stiftelsen för Internetinfrastruktur (.SE); 2009. s. 10-15.

[9] A. Friedlander, A. Mankin, W. Maughan, S. Crocker. ” DNSSEC: a protocol toward

securing the internet infrastructure”, Communications of the ACM, vol. 50, nr. 6, s. 44-

50, juni 2007.

[10] S.Ariyapperuma, C.Mitchell. ”Security vulnerabilities in DNS and DNSSEC”,

Second International Conference on Availability, Reliability and Security, nr. 10”, s.

335-342, april 2007.

[11] D.Karrenberg, “DNSSEC: Securing the global infrastructure of the Internet”,

Network Security, vol. 2010, nr 6, s.4-6, 2010.

[12] S. Grgic, “Protecting the Domain Name System”, The 33rd International

Convention MIPRO, s.1221-1225, 2010.

[13] J.Bau, J,C. Mitchell, “A Security Evaluation of DNSSEC with NSEC3”, Revised

and corrected version of conference paper in Network and Distributed Systems Security

(NDSS), mars 2010.

http://www.idg.se/2.1085/1.334003/daligt-skydd-av-kommunernas-hemsidor

http://www.idg.se/2.1085/1.334003/daligt-skydd-av-kommunernas-hemsidor

http://www.ietf.org/rfc/rfc3833.txt


http://www.iis.se/docs/Rapport-Halsolaget-2009-final23.pdf

38

[14] S.Krishnaswamy, W.Hardaker, R. Mundy, “DNSSEC in Practice: Using DNSSEC-

Tools to Deploy DNSSEC”, 2009 Cybersecurity Applications&Technology Conference

for Homeland Security, s.3-15, mars 2009.

[15] M.Höst, B.Regnell, P.Runeson, Att genomföra examensarbete, Lund:

Studentlitteratur; 2006.

[16]M.Gieben, ”DNSSEC: The Protocol, Deployment, and a Bit of Development”,

www.cisco.com, juni 2004 [www] Tillgänglig:

http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-2/dnssec.html,

[Hämtad: 2010-09-13]

[17] ”DNS Security Extensions (DNSSEC)”, Microsoft, Oktober 2009. [www]

Tillgänglig: http://technet.microsoft.com/en-au/library/ee683904(WS.10).aspx.

[Hämtad: 2010-09-14].

[18] ”Checklist: Implementing DNSSEC”, Microsoft, Oktober 2009. [www]

Tillgänglig: http://technet.microsoft.com/en-au/library/ee649178(WS.10).aspx.

[Hämtad: 2010-09-14].

[19] ”Säker domän (DNSSEC)”, IIS, [www] Tillgänglig:

http://www.iis.se/domaner/dnssec. [Hämtad: 2010-09-20]

[20] A.Rafting, ”Ökad tillit till Internet genom förbättrad säkerhet i

domännamnssystemet Införande och test av standarden DNSSEC”, www.pts.se,

september 2006 [www] Tillgänglig:

http://www.pts.se/upload/Documents/SE/sakerhet_domannamnssystem_2006_36_okt.p

df, [Hämtad: 2010-09-20]

[21] A-M.Eklund Löwinder, ”Nåbarhet på nätet hälsoläget i .SE 2008 ”, www.iis.se,

2008 [www] [Hämtad: 2010-09-01]

[22] A-M.Eklund Löwinder, ”Nåbarhet på nätet hälsoläget i .SE 2009 ”, www.iis.se,

2009 [www] [Hämtad: 2010-09-01]

[23] J.Eriksson , ”Domänåret 2009 visar vägen för 2010”, Loopia, 2010-03-03. [www]

Tillgänglig: https://www.loopia.se/omloopia/pressinfo-2010-03-03/. [Hämtad: 2010-09-

21]

[24] G.Nath Nayak, S.Ghosh Samaddar, ”Different Flavours of Man-In-The-Middle

Attack, Consequences and Feasible Solutions”, Computer Science and Information

Technology (ICCSIT), 2010 3rd IEEE International Conference on, vol. 5, s. 491-495,

juli 2010.

http://www.cisco.com/

http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-2/dnssec.html

http://technet.microsoft.com/en-au/library/ee683904(WS.10).aspx

http://technet.microsoft.com/en-au/library/ee649178(WS.10).aspx

http://www.iis.se/domaner/dnssec

http://www.pts.se/

http://www.pts.se/upload/Documents/SE/sakerhet_domannamnssystem_2006_36_okt.pdf

http://www.pts.se/upload/Documents/SE/sakerhet_domannamnssystem_2006_36_okt.pdf

http://www.iis.se/

http://www.iis.se/

https://www.loopia.se/omloopia/pressinfo-2010-03-03/

39

[25] C.L.Abad, R.I.Bonilla, ”An Analysis on the Schemes for Detecting and Preventing

ARP Cache Poisoning Attacks”, Distributed Computing Systems Workshops, 2007.

ICDCSW '07. 27th International Conference on, s. 60, juli 2007.

[26] M. Handley, E. Rescorla. ”Internet Denial-of-Service Considerations”. IAB, 2006-

11. [www] Tillgänglig: http://www.ietf.org/rfc/rfc4732.txt [Hämtad: 2010-09-27].

[27] P.Vixie, G. Sneeringer, M. Schleifer ”Events of 21-Oct-2002”. ISC/UMD/Cogent ,

2002-11-24. [www] Tillgänglig: http://c.root-servers.org/october21.txt [Hämtad: 2010-

09-27].

[28] P. Mockapetris. ”Domain names - implementation and specification”. ISI, 1987-11.

[www] Tillgänglig: http://www.ietf.org/rfc/rfc1035.txt [Hämtad: 2010-09-30].

[29] DNS-OARC, ”Web-based DNS Randomness Test.” DNS-OARC, 2008-07-16.

[www] Tillgänglig: https://www.dns-oarc.net/oarc/services/dnsentropy. [Hämtad: 2010-

10-11]

[30] S.Seshadri, G.Lindsay, ”DNSSEC Deployment Guide.” Microsoft, 2010-03-26.

[www] Tillgänglig: http://download.microsoft.com/download/0/F/B/0FBF9EA8-3233-

4FD2-A6CC-6E9B3A2C8362/DNS_SVR2008R2_DNSSEC.doc. [Hämtad: 2010-10-

12]

[31] N. Andersson, ”Så implementerar du dnssec”, IDG, 2009-05-04. [www]

Tillgänglig: http://www.idg.se/2.1085/1.219465/sa-implementerar-du-dnssec. [Hämtad:

2010-10-15]

[32]T.Eklöv, ”Microsoft gör DNSSEC svårt”, Internetdagarna, 2009-08-13.[www]

Tillgänglig: http://www.internetdagarna.se/track/ip-och-infrastruktur/microsoft-gor-

dnssec-svart. [Hämtad 2010-10-18]

[33] CZ.NIC Labs. ”DNSSEC Validator”. CZ.NIC, 2010-09-23. [www] Tillgänglig:

http://www.dnssec-validator.cz/. [Hämtad: 2010-10-28]

[34] ”BIND”, Internet System Consortium.[www] Tillgänglig:

http://www.isc.org/software/bind. [Hämtad: 2010-10-19]

[35] ”What is BIND and what does it do?“, Internet System Consortium.[www]

Tillgänglig: http://www.isc.org/software/bind/whatis. [Hämtad: 2010-10-19]

[36] “OpenDNSSEC”, .SE.[www] Tillgänglig:

http://www.iis.se/domaner/dnssec/opendnssec. [Hämtad: 2010-10-19]


http://c.root-servers.org/october21.txt


https://www.dns-oarc.net/oarc/services/dnsentropy

http://download.microsoft.com/download/0/F/B/0FBF9EA8-3233-4FD2-A6CC-6E9B3A2C8362/DNS_SVR2008R2_DNSSEC.doc

http://download.microsoft.com/download/0/F/B/0FBF9EA8-3233-4FD2-A6CC-6E9B3A2C8362/DNS_SVR2008R2_DNSSEC.doc

http://www.idg.se/2.1085/1.219465/sa-implementerar-du-dnssec

http://www.internetdagarna.se/track/ip-och-infrastruktur/microsoft-gor-dnssec-svart

http://www.internetdagarna.se/track/ip-och-infrastruktur/microsoft-gor-dnssec-svart

http://www.dnssec-validator.cz/

http://www.isc.org/software/bind

http://www.isc.org/software/bind/whatis

http://www.iis.se/domaner/dnssec/opendnssec

40

[37] ”Welcome to OpendDNSSEC”, OpendDNSSEC. [www] Tillgänglig:

http://www.opendnssec.org/. [Hämtad: 2010-10-19]

[38] J.Åhlund, P.Wallström ,”DNSSEC Tester av routrar för hemmabruk” IIS, 2008-02,

[WWW] Tillgänglig: http://www.iis.se/docs/Routertester.pdf. [Hämtad: 2010-10-21]

[39] ”Tillväxt”, IIS, [www] Tillgänglig:

http://www.iis.se/domaner/statistik/tillvaxt?chart=per-type#datachart-4cc53134b5f53.

[Hämtad: 2010-10-25]

[40] F.Kazunori, ”DNS Process-in-the-middle-Attack”. Japan Registry Services, 2005,

[www] Tillgänglig: http://www.icann.org/en/presentations/dns-attack-MdP-

05apr05.pdf. [Hämtad: 2010-10-25]

[41] ”Swedish banks and DNS”. Interlan, 2010, [www] Tillgänglig:

http://www.dnssecandipv6.se/bankdns/. [Hämtad: 2010-10-27]

[42] ”DNSCHECK”, IIS, [www] Tillgänglig: http://dnscheck.iis.se/. [Hämtad: 2010-10-

29]

[43] ”Tillägg för Firefox”, Mozilla [www] Tillgänglig: https://addons.mozilla.org/sv-

SE/firefox/addon/64247/. [Hämtad: 2010-10-29]

[44] ”Svenska kommuner med DNSSEC”, IIS,[www] Tillgänglig:

http://fou.iis.se/dnsseckommun/. [Hämtad: 2010-10-29]

[45] ”Säkerhetsinformation för DNS”, Microsoft,[www] Tillgänglig:

http://technet.microsoft.com/sv-se/library/cc755131%28WS.10%29.aspx. [Hämtad:

2010-11-11]

http://www.opendnssec.org/

http://www.iis.se/docs/Routertester.pdf

http://www.iis.se/domaner/statistik/tillvaxt?chart=per-type#datachart-4cc53134b5f53

http://www.icann.org/en/presentations/dns-attack-MdP-05apr05.pdf

http://www.icann.org/en/presentations/dns-attack-MdP-05apr05.pdf

http://www.dnssecandipv6.se/bankdns/

http://dnscheck.iis.se/

https://addons.mozilla.org/sv-SE/firefox/addon/64247/

https://addons.mozilla.org/sv-SE/firefox/addon/64247/

http://fou.iis.se/dnsseckommun/

http://technet.microsoft.com/sv-se/library/cc755131%28WS.10%29.aspx

Appendix A – Ordlista

AD – (Active Directory) Är en katalogtjänst från Microsoft som innehåller information

om olika resurser i ett nätverk.

APR – (Address Resolution Protocol) Är en kommunikationsmodell som används för

att koppla samman IP-adress med en MAC-adress.

BIND – (Berkeley Internet Name Domain) Är en implementation av DNS-protokollet.

Broadcast – Alla paket som skickas mottas av alla på nätverket.

Brute Force – Är en metod för som kan användas för att hitta ett lösenord genom att

testa många gissningar.

Chain of trust – Det fårs genom en validerar av varje zon från TLD(se TLD) ner till

underdomänerna.

DDoS – (Distributed Denial of Service) Är när ett stort antal går samman för att utföra

en DoS-attack.

DNS – (Domain Name) System fungerar som en telefonbok och talar om vart för

någonstans en bestämd dator finns på Internet. När användare skriver in en webbadress

till exempel www.exempel.se så går det en förfrågan till en DNS-server som slår upp

det IP-nummer som är associerat med namnet och returnerar det till webbläsaren och

användaren får tillgång till hemsidan.

DNSKEY – Innehåller en krypterad nyckel som används för att signera data i en zonfil.

Denna nyckel är antingen av typen KSK (se KSK) eller ZSK (se ZSK).

DNSSEC – (DNS Security Extention) Är ett säkerhetstillägg till DNS. Det används och

fungerar på samma sätt som DNS men istället för att som DNS (se DNS) gör skicka alla

svaren mellan servrarna i klartext så läggs det till en krypterad signatur som kan

användas för att garantera äktheten på meddelandet så användaren kan veta att denne får

tillgång till den sidan som efterfrågades.

DoS – (Denial of Service) Är en attack mot ett system med syfte att förhindra normal

användning av systemet, den vanligaste attacken är överbelastningsattack.

DS – (Delegation Signer) Läggs till i en zon för att visa att zonen har blivit digitalt

signerad och att zonen känner till äkta nyckeln för den zonen.

42

End-to-end – Är när känslig data krypteras och dekrypteras mellan de kommunicerande

parterna. Sändaren av data krypterar den och sedan så dekrypterar mottagaren och kan

läsa informationen.

Ettercap - Är ett nätverkssäkerhetsverktyg för MITM-attacker.

Hop-by-hop – Är en princip som används för att kontrollera flödet av data i ett nätverk.

På detta sätt så skickas data vidare mellan alla noder i ett nätverk.

IETF – (Internet Engineering Task Force) Är en organisation som framför allt beslutar

om nya standarder för datakommunikation för Internet. Nya standarder brukar

presenteras i olika RFC-dokument (se RFC).

IIS – (Internet Information Server) Är en serverprogramvara från Microsoft för deras

Internetbaserade tjänster.

IIS - Stiftelsen för Internetinfrastruktur, ansvariga för Sveriges toppdomän .SE.

IP – (Internet Protocol) Används för överföring av data i ett datornätverk.

ISP – (Internet Service Provider) Internetleverantör.

KSK – (Key Signing Key) Är en typ av DNSKEY(Se DNSKEY). KSK används för att

signera alla nycklar som tillhör en zon. KSK är den nyckeln som är tänkt att bli den som

validerar revolvrar (se resolver) som Trust Anchors (se Trust Anchors).

LAN – (Local Area Network) Är ett lokalt nätverk som ofta avses vara begränsat till en

byggnad eller möjligen en grupp av byggnader.

MAC – Media Access Control är en unik identifierare av nätverkskortet.

Metasploit – Är ett datorsäkerhetsprogram vilket visar sårbarheter.

MITM – (Man In The Middle) En vanlig attack inom kryptering och datorsäkerhet. En

hacker kopplar in sig på en förbindelse och avlyssnar trafiken som går mellan A och B.

Hackern kan då läsa meddelanden som skickas mellan parterna och kan även ändra

meddelanden som går mellan A och B. A och B tror att de kommunicerar med varandra

men i själva verket så skickas alla meddelanden via en mellanhand som också kan

modifiera meddelandena.

Nätfiske – Ett försök för att lura användarna på information så som lösenord eller

kreditkortsinformation.

43

PKI – (Public Key Infrastrucure) Är en metod som kan användas för att dela data

mellan datorer på ett säkert sätt över ett osäkert nätverk så som Internet.

Resolver – Namnserver som används för att göra en uppslagning på Internet och

därigenom få fram vilken IP-adress som är förknippad med vilket domännamn.

RFC – (Request For Comments) Dokument som beskriver standarder för Internet.

RR – (Resource Record) Är samlingen av DNS-data. De vanligaste typerna av RR är

Namn, Klass, Typ, Data.

TCP – (Transmission Control Protocol) Ett transportprotokoll och ett av

huvudprotokollen i TCP/IP-stacken. TCP skapar en tillförlitlig kommunikation mellan

två enheter i ett nätverk.

TLD – (Top-Level Domain) Det är den högsta nivån i Internets DNS(se DNS). Till

exempel i exempel.se så är .se toppdomänen.

Trust Anchors – Används för att garantera äktheten av en sida genom att en specifik

nyckel paras ihop med rätt data.

TSIG – (Transaction SIGnature) Ett nätverksprotokoll.

TTL – (Time To Live) Värde som anger hur länge DNS-svar ska lagras i resolvers

cacheminne.

UDP – (User Datagram Protocol) Ett transportprotokoll som används på Internet. Det är

en enklarare variant av ett transportprotokoll och har få funktioner för att rätta till

överföringsfel.

Unicast – Paket motas endast av en mottagare på nätverket.

ZSK – (Zone Signing Key) Används för att signera alla RRset i en zon.

44

Appendix B – DNS-post definition

Detta appendix innehåller detaljer om DNS-protokollet där olika definitioner förklarar

av olika format och värden [28].

Format

Alla DNS-poster är formaterade enligt figur B.1.

NAME

TYPE

CLASS

TTL

RDLENGTH

RDATA

Figur B.1 : Visar DNS-postformatet och dess fält.

Tabell B.1 beskriver varje post av DNS-postformatet, så kallade Resource Records.

Fält Beskrivning

NAME Ägarens namn, exempelvis namnet på noden denna DNS-

post tillhör.

TYPE Två oktetter vilket innehåller en av RR TYPE koder.

CLASS Två oktetter vilket innehåller en av RR CLASS koder.

TTL Ett 32-bitars heltal vilket specificerar tidsintervallet DNS-

posten ska mellanlagras innan den skall tvingas uppdateras.

RDLENGTH Osignerad 16-bitars heltal som specificerar längden i

oktetter av RDATA fältet.

RDATA Sträng av oktetter som beskriver källan. Formatet varierar

beroende på TYPE och CLASS av DNS-posten.

Tabell B.1 : Förklaring av definierade fält för DNS-poster.

TYPE värden

TYPE värden används i DNS-poster, dessa typer är en delmängd av QTYPE.

TYPE Beskrivning (Värde)

A Värdadress (1)

NS Auktoritativ namnserver (2)

MD Maildestination (3)

MF Mailforwarder (4)

CNAME Kanoniska namnet för ett alias (5)

SOA Markerar början av en zon (6)

MB Mailbox domännamn (7)

MG Mailgruppsmedlem (8)

MR Mailnamnbytes domännamn (9)

NULL Null DNS-post (10)

WKS Känd servicebeskrivning (11)

45

PTR Domännamnspekare (12)

HINFO Värdinformation (13)

MINFO Mailbox- eller Maillistinformation (14)

MX Mailutbyte (15)

TXT Textsträng (16)

Tabell B.2 : Förklaring av definierade TYPE värden.

QTYPE värden

QTYPE värden används i frågedelen av en DNS-fråga. QTYPE ersätter TYPE eftersom

alla TYPE är giltiga QTYPE.


AXFR Önskan om överföring av hela zonen (252)

MAILB Önskan om mail relaterade poster som till exempel MB, MG

eller MR (253)

MAILA Önskan om mail DNS-poster (254)

* Önskan om alla poster (255)

Tabell B.3 : Förklaring av definierade QTYPE värden.

CLASS värden

CLASS värden återfinns i DNS-poster. Tabell B.4 förklarar definitionerna och dess

värde.


IN Internet (1)

CS CSNET klass (2)

CH CHAOS klass (3)

HS Hesiod (4)

Tabell B.4 : Förklaring av definierade CLASS värden.

QCLASS värden

QCLASS värden används i frågedelen av en DNS-fråga. QCLASS ersätter CLASS och

varje CLASS är en giltig QCLASS. Dessutom används QCLASS värden som beskrivs i

tabell B.5.


* Alla klasser (255)

Tabell B.5 : Förklaring av definierade QCLASS värden.

DNS-poststandard

Följande DNS-postdefinitioner förväntas i alla klasser, i synnerhet NS, SOA, CNAME

och PTR används i alla klasser med samma format i samtliga. Eftersom dess RDATA är

känt kan alla domännamn i RDATA fält av dessa DNS-poster komprimeras.

CNAME RDATA format

CNAME posten specificerar ett primärt namn för dess ägare. Ägarens namn är ett alias.

46

MX RDATA format

MX posten specificerar en värd som utför mailutbyte åt domänägaren.

NS RDATA format

NS posten specificerar en värd som borde vara auktoritär för den specificerade

domänen.

PTR RDATA format

PTR posten pekar på någon plats i domännamnsutrymmet. Används ofta för

implementering av omvänd DNS-uppslagning.

SOA RDATA format

Formatet av SOA visas i figur B.2.

MNAME

RNAME

SERIAL

REFRESH

RETRY

EXPIRE

MINIMUM

Figur B.2 : Visar SOA-format.

Tabell B.6 beskriver varje post av SOA-formatet.

TYPE Beskrivning

MNAME Domännamnet för domänservern som är originalet eller

primär källa av data för denna zon.

RNAME Domännamnet vilket specificerar mailboxen för den person

ansvarigt för zonen.

SERIAL Osignerad 32-bitars versionsnummer av originalkopian för

zonen.

REFRESH 32-bitars tidsintervall innan zonen skall laddas om.

RETRY 32-bitars tidsintervall som borde förflyta innan en

misslyckad uppdatering bör omprövas.

EXPIRE 32-bitars tidsvärde som specificerar en övregräns av

tidsintervallet som kan förflyta innan zonen inte längre är

auktoritativ.

MINIMUM Osignerad 32-bitars minimum TTL fält som borde

exporteras med varje DNS-post från denna zon.

47

Tabell B.6 : Förklaring av definierade SOA värden.

Meddelandeformat

All kommunikation inom domänprotokollet transporteras med enskilda meddelanden.

Huvudnivån för meddelandena delas in i fem sektioner vilket figur B.3 visar.

Frågan för namnservern.

DNS-posten svarar på frågan.

DNS-posten pekar på en auktoritet.

DNS-posten innehar ytterligare information.

Figur B.3 : Visar de fem olika sektionerna för meddelandeformat.

Pakethuvudet används alltid och inkluderar fält vilket specificerar vilka kvarvarande

sektioner är närvarande och även om meddelandet är ett svar eller en fråga.

Namnsektionerna efter pakethuvudet levereras från dess standardfråga.

Frågesektionen innehåller fält vilket beskriver frågan till en namnserver. Dessa fält är

frågetyp (QTYPE), frågeklass (QCLASS) och fråga om domännamnet (QNAME). Sista

tre sektionerna är av lika format eller möjligen en tom lista av sammanlänkade DNS-

poster. Svarsektionen innehåller DNS-poster som besvarar frågan och

auktoritetsektionen innehåller DNS-poster som pekar på auktoritetservrar. Ytterligare

information kan vara DNS-poster som berör frågan, men besvarar inte frågan helt.

Pakethuvud

Pakethuvudet innehåller de fält figur B.4 illustrerar.

ID

QR| OPCODE |AA|TC|RD|RA| Z | RCODE

QDCOUNT

ANCOUNT

NSCOUNT

ARCOUNT

Figur B.4 : Visar de olika fälten i pakethuvudet.

Tabell B.7 förklarar de olika fälten ur figur B.4.

Fält Beskrivning

ID 16-bitars identifierare tilldelad av programmet som

genererar frågan. Identifieraren kopierar motsvarande svar

och används för att matcha svar till utestående frågor.

QR 1-bitsfält som specificerar om meddelandet är en fråga (0)

eller ett svar (1).

OPCODE 4-bitarsfält som specificerar frågetypen för meddelandet.

Värdena har följande beskrivning:

0: Standardfråga (QUERY).

1: Inversfråga (IQUERY).

2: Serverstatusfråga (STATUS).

Header

Question

Answer

Authority

Additional

48

3-15: Reserverat för framtida arbeten.

AA Auktoritativt svar – Biten är giltig i respons och specificerar

att svarande namnserver är auktoritativt för domännamnet i

frågesektionen.

TC Trunkering – Specificerar att meddelandet var trunkerat till

större storlek än vad som godkänds för

överföreningskanalen.

RD Rekursiv önskan – Biten kan ansättas i frågan och kopieras

till svaret. Om RD ansätts leder namnservern att utöva

frågan rekursivt.

RA Rekursiv tillgänglighet – Biten ansätts eller tas bort i ett svar

och betecknar om rekursiva frågor stöds.

Z Reserverad för framtida arbeten.

RCODE Respons kod - 4-bitasfält är del i respons. Värdena har

följande beskrivning:

0: Inget fel

1: Format fel – Namnservern misslyckades att tolka frågan.

2: Server fel – Namnservern kunde inte behandla frågan på

grund av ett problem med namnservern.

3: Namn fel – Endast meningsfull på svar från auktoritativa

namnservrar. Innebörden av denna kod är att domännamnet

refererat till frågan inte existerar.

4: Inte implementerat – Namnservern stödjer inte efterfrågad

typ av fråga.

5: Vägrar – Namnservern vägrar att utföra specificerad

operation efter motsägande av dess policy.

6-15: Reserverat för framtida arbeten.

QDCOUNT Osignerad 16-bitars heltal som specificerar antalet poster i

frågesektionen.

ANCOUNT Osignerad 16-bitars heltal som specificerar antalet DNS-

poster i svarsektionen.

NSCOUNT Osignerad 16-bitars heltal som specificerar antalet

namnserver DNS-poster i källpostsektionen.

ARCOUNT

Tabell B.7 : Förklaring av definierade fält pakethuvudet.

Frågeformat

Frågesektionen bär själva DNS-frågan och innehåller i flesta fallen dessa parametrar

definierar vad som efterfrågas. Sektionen innehåller QDCOUNT-poster av formatet som

visas i figur B.5.

QNAME

QTYPE

QCLASS

Figur B.5 : Visar format för en DNS-fråga.

Tabell B.8 förklarar de olika fälten i figur B.5.

49

Fält Beskrivning

QNAME Domännamnet representeras i sekvens av beteckningar.

QTYPE Två oktetter som specificerar typen för frågan. Värdet

inkluderar alla koder giltiga för TYPE fältet och tillsammans

med mer generella koder vilket kan matchas med mer än en

typ av DNS-post.

QCLASS Två oktetter som specificerar klassen för frågan. Till exempel

QCLASS fältet är IN för Internet.

Tabell B.8 : Förklaring av definierade fälten i DNS-frågan.

DNS-postformat

Svaret, myndigheten och tilläggande sektioner delar alla samma format: Ett

variabelnummer av DNS-posten, där numret av posten specificeras i motsvarande

räknefält i pakethuvudet. Formatet av varje DNS-post visas i figur B.6.

NAME

TYPE

CLASS

TTL

RDLENGTH

RDATA

Figur B.6 : Visar DNS-postformatet och dess fält.

Fält Beskrivning

NAME Ett domännamn vilket denna DNS-post tillhör.

TYPE Två oktetter innehållande en av RR TYPE koder. Detta fält

specificerar meningen av data i DATA fältet.

CLASS Två oktetter vilket specificerar klassen av data i RDATA

fältet.

TTL Osignerad 32-bitars heltal som specificerar tidsintervallet (i

sekunder) som DNS-posten kan mellanlagras innan den

skall tvingas uppdateras.

RDLENGTH Osignerad 16-bitars heltal som specificerar längden i

oktetter av RDATA fältet.

RDATA Sträng av oktetter som beskriver källan. Formatet varierar

beroende på TYPE och CLASS av DNS-posten.

Tabell B.9 : Förklaring av definierade fält i en DNS-post.