20
Jan
11

Mot en möjlig decentralisering av DNS-hierarkin?

Internet som det ser ut idag är högst beroende av tjänsten DNS (Domain NameSystem) som kan ses som en av grundbultarna i internets infrastruktur. DNS går i all enkelhet ut på att man kan komma åt resurser på nätverket (internet i de flesta fall) utan att kunna resursens ip-adress. Istället kan man använda en adress som är meningsfull för människor, istället för siffror som är omöjliga att komma ihåg när det existerar miljontals webbsidor på internet.

På senare tid har nätaktivister börjat ifrågasätta strukturen med hur tilldelningenav adresser ser ut på global nivå, genom att rikta kritik mot vad man har sett som en onödig centralisering. Då vi idag ser en riktning från stater och myndigeter mot att försöka reglera kommunikationen på internet på olika sätt så blir det därmed intressant att se om det är möjligt att förändra eller utveckla ett alternativ till DNS-hierarkin innan det blir till ett problem. Men för att se om och hur det skulle kunna gå att genomföra så bör vi förstå mer om hur DNS fungerar i detalj.

Det går naturligtvis lika bra att komma åt resurser på nätverket genom enbart ip-numret, men människans minneshantering skiljer sig från en dators. Där en dator utan problem kan spara långa strängar av till synes meningslösa kombinationer av tal så kan samma uppgift vara ohanterbar för en människa. När det gäller att komma ihåg ip-adresser så aktualiserades det som ett problem redan på 70-talet när ARPAnet, föregångaren till dagens internet, var under utveckling i USA.För att lösa problemet med en ständigt växande samling med ip-nummer så skapade man “Name Servers”, för att kunna låta egenskaperna hos en namngiven resurs på nätverket skötas på en given plats. Detta medförde att man nu enbart behövde veta den fysiska adressen (ip-adressen) till namnservern samt namnet på resursen man ville ha åtkomst till för att kunna få det.

Namnservern skickar efter att ha fått en förfrågan (query) från en klient i nätverket ip-adressen tillbaka så att klienten sen i sin tur kan skapa en åtkomst till den resurs som personen vill använda. Namnservern medförde därmed att man kan lägga till, ta bort och modifera resurser på en enda server, vilket gjorde klienternas åtkomst till nätverkets resurser mycket enklare. Det som fungerade i början av utvecklingen av ARPAnet blev dock mer och mer ohållbart desto mer klienter blev anslutna och nätverket därmed växte. På namnservern så hanterades alla anslutna klienter med en enda fil, HOSTS.TXT, som då innehöll namn och adresser. Den sköttes av Network Information Center på Stanford Research Institute och fick därav namnet SRI-NIC. Administratörer på ARPAnet skickade in sina förändringar av namn och adresser till NIC som då manuellt uppdaterade filen en eller två gånger i veckan.

När nätverket växte så blev inläggen i filen oöverskådliga samtidigt som trafikensom följde av uppdateringsprocessen medförde en betydande belastning av dåtidens i jämförelse långsamma uppkopplingar. För varje uppdatering av HOSTS-filen så kom nämligen trafik från en användare som vill ta hem den uppdaterade filen från SRI-NIC:s server, vilket var ett problem som mångfaldigades i och med övergången till TCP/IP-protokollet. Man började därför att snickra på en ersättare till HOSTS.TXT som skulle lösa problemen genom att tillåta lokal administration samtidigt som denna data skulle vara tillgänglig för hela nätverket.

Decentralisering av administrationen skulle därmed lösa problemet med belastningen från all trafik till en enda server, samtidigt som man lämnade själva uppdateringen till systemadministratörerna i det givna nätverket som var anslutet till ARPAnet. Men man introducerade även ett hierarkiskt system för “namespace”, alltså hur själva nätverksadresserna skulle se ut. Dessa medförde att resurser i olika nätverk nu kunde ha samma namn men ändå inte krocka med varandra på nätverket då introduktionen av adresserna gjorde att dessa även pekade på nätverken dom fanns i och inte bara resursen i sig.

DNS-databasen är numera distribuerad över hela världen och innehåller inlägg som kallas Resource Records, vilka består av information om “adress mapping”och “reverse-lookup pointer” som är information om ip-till-hostname respektivehostname-till-ip. Det går även att skapa underdomäner till en domän (exempelvis bilder.sida.com) som vidare reflekterar resursens grupp- och nätverkstillhörighet. Rotdomänen ligger högst upp i hierarkin och representeras av en punkt i slutet av adresserna, men utesluts allt som oftast ur adresserna. Därefter kommer toppdomänerna som finns i två kategorier; gTLD som är .com-, .org-, .mil-domäner, samt ccTLD som är landsspecifika domäner som .se, .fr, etc.

Det finns individuella delar av DNS-databasen som kallas zoner som är placerade på speciella namnservrar, där då administratörerna för de lokala domänerna sköter sina egna namnservrar och zoner. Namnservrarna har komplett information över zonerna dom har hand om genom att ladda denna information från en fil eller en annan namnserver. Zoner innebär att man bryter ner domäner till mer lätthanterliga enheter genom att delegera ansvaret för queries till en mer decentraliserad nivå, så att ansvariga för toppdomänen inte behöver ha information om resurserna som finns på underdomänerna.

Detta sker även med underdomäner till underdomäner om det är ett stort nätverk. Skillnaden mellan en domän och en zon är att domäner innehåller mer information än namnservern behöver då den även innehåller data som delegeras till andra namnservrar. Zonerna är kopplade till just delegering och inkluderar därmed inte delegerad data.Datan i en zon innehåller information som pekar på den korrekta namnservernsom är ansvarig för en underdomän, så om en användare kontaktar en namnserver vill ha tag i data som finns en underdomänen så svarar namnservern i sin tur med att ge information om vilken namnservern som användaren ska kontakta.Först därefter får användaren information om vilket IP-nummer som är relevant.

Så långt om hur DNS fungerar lite i praktiken där vi har sett att lösningen påARPAnets överbelastningsproblem löstes av att man flyttade ner administrationentill de lokala nätverken. Men det finns fortfarande en central organisation somsköter allokeringen av IP-adresser, rootservrar och toppdomäner. Denna ideella organisation heter The Internet Corporation for Assigned Names and Numbers(ICANN) och sköter numera de uppgifter som tidigare föll en rad andra organisationer på uppdrag av USA:s regering.

Tre uppgifter som ICANN sköter är viktiga i sammanhanget, nämligen att uppställa kriterier för bildandet av nya Regional Internet Registries (RIR), administrering av de landsspecifika toppdomänerna (ccTLD) och såväl som dom generella (gTLD) samt att man sköter en unik rootserver. Det är den sistnämnda funktionen som är viktigast i sammanhanget då det är dessa namnservrar som ligger längst upp i DNS-hierarkin genom att dessa ansvarar för toppdomänerna och deras underdomäner. Internetanvändare kommunicerar dock först med Local Internet Registries (LIR:s)som i de flesta fall är internetleverantörer, men ibland även myndigheter och storaföretag.

En LIR måste ha ett avtal med den organisation som är regionalt ansvarig, kallad för Regional Internet Registries (RIR:s) men även den nationella om det finns någon (NIR:s). Så vi kan se att en användares dator därmed först och främst riktar en förfrågan till sin ISP som sen går vidare till NIR som i sin tur slussar vidare den till sin RIR. Vägarna som en förfrågan tar på internet är alltså ibland svåra att förutsäga, men är ändå ett system som fungerar just tack vara sin decentralisering i dagens internet med dess höga trafiknivåer.

Om nu DNS är så decentraliserat, vari ligger då problemet? Kritiken som har riktats mot ICANN från förespråkare av ett internet som även i framtiden ska vara öppet har menat att problemet ligger i att organisationen verkar som en centralnod. Detta skiljer sig inte bara från hur DNS-systemet i övrigt är uppbyggt, utan även hur internets öppna struktur rent generellt ser ut, där varje uppkopplad nod kan nå varje annan uppkopplad nod.

ICANN står under USA:s lagar och då mycket av de lagförslag som föreslårregleringar av internet kommer just i USA så är man därmed känslig för inskränkningar genom att infrastrukturen då är centraliserad till en part. Det finns ett amerikanskt lagförslag vid namn “Combating Online Infringement and Counterfeits Act” (COICA) som går ut på att man ska kunna blockera domäner som bryter mot amerikansk upphovsrättslagstiftning, även om det är troligt att även domäner som pekar på andra sorters innehåll kan komma att blockeras med.

En rad med kända ingenjörer och programmerare som var med i konstruktionen av dagens internet har skrivit ett öppet brev till senatens juridiska utskott där domprotesterar mot vad man ser som en grov inskränkning av internets infrastruktur. Man menar att om man börjar införa censur hos rootdomänerna så kommer dom alternativa rootservrarna att bli mycket mer populära än dom är idag, vilket mandå menar skulle leda till konflikter i stil med det man såg hos det tidiga ARPAnet. Internet Architecture Board, som föddes 1979 som en organisation under USA:s försvarsmyndighet, har uttalat sig mycket kritiskt mot alternativa rootservrar på grund av vad man menar som teknologiska orsaker i ett memo redan från 2000.

“Put simply, deploying multiple public DNS roots would raise a very strongpossibility that users of different ISPs who click on the same link on a web pagecould end up at different destinations, against the will of the web pagedesigners.”

Detta verkar dock inte stämma då de flesta av dessa alternativa rootservrar dels delegerar trafik vidare till dom rootservrar som körs av ICANN och dels delgererar till dom alternativa toppdomänerna som administreras av alternativa organisationer utan ICANN:s tillstånd. Men det handlar då om att de alternativa rootservrarna måste samarbete för att man inte ska komma åt olika delar av nätet genom att använda olika alternativa servrar.

Vissa av dessa organisationer verkar dock vara mycket seriösa i sin vision om ett öppet internet, och samarbeter både med företag och myndigheter ibland för ideella och ideologiska orsaker, men även för profit. Bland de mer till synes ideologiskt drivna hittar vi bland annat Public Root som administreras av Internet Names Authorization & Information Center. Men situationen som den ser ut nu är att ICANN:s rootservrar är helt ohotade i sin dominans, medan vi ser en del entusiasters DNS-tjänster nå endast en bråkdel avtotala internetanvändarna. En lösning på problemet verkar därmed vara att bygga in anslutningarna till de alternativa rootservrarna hos internetleverantörerna, men det gör ISP:erna i sin tur känsliga för lagstiftning.

En annan lösning vore att bygga in anslutningen till alternativa rootservrar i exempelvis webbläsare (som det redan finns dylika plugins för) samtidigt som man yrkar för en ökad samordning mellan de olika alternativa DNS-tjänsterna. Man kan även tänka sig mjukvarulösningar som förhandsgranskar och jämför adresser genom olika DNS-tjänster och låter webbläsaren avgöra vilken adress som man troligen skulle till. Men för att försöka dra en slutsats så tror jag att lagförslagen som vill begränsa och reglera internet inte kommer sluta att komma. Det innebär att vare sig det kommer innebära teknologiska problem eller inte så kommer alternativa tjänster bli mer aktuella. Den bästa situationen vore att gå mot utvecklingen av mjuvarulösningar som sköter de alternativa DNS-tjänsterna bättre.


0 Svar till “Mot en möjlig decentralisering av DNS-hierarkin?”



  1. Kommentera

Lämna en kommentar

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Logga ut / Ändra )

Twitter-bild

You are commenting using your Twitter account. Logga ut / Ändra )

Facebook-foto

You are commenting using your Facebook account. Logga ut / Ändra )

Ansluter till %s


Blog Stats

  • 3,870 hits
Creeper

 

januari 2011
m ti o to f l s
« Okt    
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Follow

Get every new post delivered to your Inbox.