• No results found

8. Analys och Diskussion

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.

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.

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:

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:

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.

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)

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.

TYPE Beskrivning (Värde)

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.

TYPE Beskrivning (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.

TYPE Beskrivning (Värde)

* 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

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.

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.

Related documents