sou · GRB359d2 · 2004-01-01 00:00:00 — Man skulle kunna använda talen: Koppla dig till datorn som har adress 10244753! ... eller var det 10244735 ... eller 10244357? Rent tekniskt fungerar det, men människans hjärna är dålig på att komma ihåg långa sifferserier. Man vill mycket hellre säga åt sitt system Koppla dig till datorn som heter besk!. Datorn kan tolka namnet besk och på något sätt slå upp vilken adress just besk har, och sedan koppla sig till den adressen. Bara den människa som en gång ställer i ordning systemen behöver bekymra sig om vilken faktisk adress som besk har, men så snart det är inskrivet i uppslagstabellen så kan man sluta bry sig. Det går ju att slå upp i sagda tabell. På Internet förde man länge en central sådan tabell som innehöll namn på alla datorer på Internet och vilken adress de hade. Tabellen distribuerades till samtliga maskiner som var anslutna till det då för tiden tämligen hanterliga lilla nätet, så att maskinerna kunde hålla reda på vad alla andra hette och vilka adresser de hade. Tabellen blev längre... och längre... och längre. Varje dator måste dessutom ha ett unikt namn för att det inte skulle bli några krockar. När tabellen hade blivit ett antal tusen rader lång, och en ansenlig andel av nätets kapacitet gick åt till att skicka denna tabell kors och tvärs mellan alla datorer, insåg man varthän det var på väg och uppfann ett nytt system – domännamnssystemet (DNS). DNS innebar två radikala skillnader: För att ge flera datorer möjlighet att ha samma namn, införde man längre namn med flera namn- delar. I början grundade sig namndelarna på vilken typ av organisation man tillhörde, och vad organisationen hette. infördes landskoderna, och någon i respektive land fick ansvaret för tilldelningen av namn inom det landet. Man skrotade den gemensamma tabellen, och skapade ett system med databasservrar som hänvisar till varandra enligt samma hierarkiska system som namnen följer. Ingen dator har alltså mer information än vad den själv ansvarar för och vad som behövs för att knyta ihop den med övriga servrar i . Genom att fråga sig fram kan man nu hitta den information man söker. Eftersom följande text kommer att handla en del om databaser och hantering av dem, är det viktigt att först klargöra några begrepp. En uppslagsnyckel är en textsträng eller ett tal som man använder för att hitta fram till andra data. Om man vill veta telefon- nummer och skall titta i sin lilla telefonbok så slår man på P som i och där står det antagligen 01 – 17 47 11 är strängen man använder för att hitta fram till rätt telefonnummer, och den kallas uppslagsnyckel. information man ville åt var ju själva telefonnumret: den information som man har, och som man använder för att hitta annan information. Värdet är den information man letar efter. En post är just en kombination av en nyckel och ett värde. Ofta innehåller posten mer information, t.ex. vad det är för typ av värde. En post kan också innehålla flera olika värden av samma eller olika typ, t.ex. Tel 01 – 17 47 11 0701 – 47 33 00 Minnesstigen 23; 100 99 DATABO Denna post har uppslagsnyckeln . För att sedan hitta precis den information man vill ha måste man bestämma sig lite noggrannare – är man ute efter telefonnumret eller adressen? I databassammanhang kallar man ofta de olika delarna i en post för fält. I DNS-sammanhang har man i stället flera poster med samma uppslagsnyckel, och sedan olika typer av poster beroende på vilken typ av information som finns lagrad i dem. Om detta system tillämpades i telefonboken ovan skulle det se ut som 01 – 17 47 11 0701 – 47 33 00 När man vill ha tag i information använder man alltså både sök- nyckel och posttyp för att hitta rätt. Skillnaden mellan uppslagning och sökning är viktig. Vid en uppslagning har man en klar och tydlig söknyckel och förväntar sig ett (eller möjligen flera) klara tydliga värden. Man har t.ex. ett namn och vill ha tag i den personens telefonnummer. Man slår upp det och förväntar sig ett svar, möjligen några få om personen har fler än ett telefonnummer. Vid en sökning har man en icke entydig söknyckel och man förväntar sig ett urval som svar. Ur detta urval väljer man sedan en söknyckel med vars hjälp man gör en uppslagning. –Han hette något på P och jag behöver hans telefon- nummer! –Här är en lista på alla som börjar på P. Vem av dem menar du? –Jag menar . Ge mig telefonnummer! –Han har två: 01 – 17 47 11 och 0701 – 47 33 00. I detta exempel är söknyckeln först inte väl definierad. Den är något som börjar på P. En sökning leder till en lista på alternativa nycklar – ett urval av alla nycklar som finns i databasen. Från den listan kan man sedan välja den nyckel man tycker passar bäst – i detta fall. Med hjälp av denna specifika nyckel kan man nu göra en uppslagning och få reda på det eftersökta värdet. DNS-systemet kan inte på något sätt hantera sökningar – det kan endast utföra uppslagningar. Man måste alltså alltid ha fullt klart för sig exakt vilket namn det är man vill slå upp i DNS- systemet. Tekniskt sett ser ett domännamn ut så här: Ett domännamn är sammansatt av noll eller fler domändelar. Varje domändel består av en kombination av bokstäver (dock endast A–Z), siffror och tecknet bindestreck. En domändel får inte börja med bindestreck. Stor och liten bokstav tolkas lika. Domän- delarna fogas samman till en sammanhängande sträng, och de olika domändelarna separeras med hjälp av tecknet punkt. Den domändel som står längs till höger kallas toppdomän (top level domain, TLD), och domändelen direkt till vänster om toppdomänen kallas ofta för huvuddomän. Längden på ett domännamn begränsas av följande värden: Hela namnet, inklusive alla punkter, får maximalt vara 255 tecken, samt, varje domändel måste ha minst ett tecken och maximalt 63 tecken (punkten oräknad). Med hjälp av lite matematik kommer man fram till att man alltså kan ha maximalt 126 nivåer i ett domännamn. Dessa längdgränser är sällan eller aldrig något praktiskt hinder. Domännamnen följer en strikt hierarki som bildar ett matema- tiskt träd, och det utgår från ett centralt namn – roten. Figur 1: Domännamnsträdet. När man tolkar ett domännamnsträd läser man namnen nedifrån och upp. I trädet ovan kan vi alltså utläsa namn som bunyip.com., , admin.acme.se., cafax.se., se., osv. Figur 2: Några domännamn. Domännamnen lagras som uppslagsnycklar i databasen, och man kopplar olika typer av information, dvs. olika värden, till uppslags- nycklarna. Datorer på Internet kan sedan slå upp information i databasen och använda den. Det vanligaste man lagrar i DNS- databasen är Internetadresser. En dators identitet på Internet är egentligen dess adress (numret). Genom att lagra ett domännamn i databasen och koppla en Internetadress som värde till den uppslagsnyckeln, så ger man datorn ett namn. Man kan slå upp namnet i databasen och få reda på dess adress, och därmed nå fram till den datorn. Alla webbservrar finns lagrade i DNS, och när man skriver in en URL i sitt webbverktyg (t.ex. Netscape) så används en del av URL:en som uppslagsnyckel i DNS för att man skall få fram webbserverns adress på Internet. Man kan lagra annan typ av information i DNS-databasen också. DNS-systemet används t.ex. för att hålla reda på vilken dator som är e-postserver för en viss domän. Vill man skriva brev till så slår man upp . i DNS och frågar efter tillhörande e-postserver. Man får då namnet på en dator som svar, och kan sedan på vanligt sätt slå upp den datorns adress genom en andra slagning i databasen. Sedan är det bara att koppla upp sig mot den adressen och skicka brevet. Det är viktigt att inse att alla domännamn fungerar på precis samma sätt, principiellt sett. Det är människan som väljer hur namnen skall användas genom att koppla ihop olika typer av information med olika namn i DNS-databasen. Det är alltså ingen- ting som hindrar att en webbserver heter pc3.acme.se. eller att en vanlig PC har namnet (endast) se. eller att en mailadress ser ut som Domännamnen matas in i filer i DNS-servrar som är anslutna till Internet. I servrarna körs programvara som läser in filerna och sedan lyssnar efter DNS-frågor från nätverket och gör sitt bästa för att svara på dem. En sådan databasfil kan innehålla poster som ser ut som: Ur datan ovan kan man utläsa att den som har skrivit filen vill tala om för omvärlden att det finns en dator som heter . med adressen 192.168.3.31 (A = Address), att det finns en annan dator som heter pc3.acme.se. och som har adressen 192.168.4.11, samt att man kan skicka e-post till adresser som slutar på @. till den dator som heter mailgw1.super-ip.net. så kommer den datorn att se till att e-posten kommer dit den skall (MX = Mail eXchanger). Om det nu kommer frågor till DNS-servern ovan så kommer den att svara med det den vet. Om någon frågar Vad har datorn pc3.acme.se. för adress?, så kommer den att svara 192.168.4.11. I teorin skulle man kunna lagra alla domännamn i en och samma server. Ingenting i systemdesignen förhindrar att man gör det, men det blir inte praktiskt. Om vi går tillbaka till jämförelsen med nummerbyrån, så skulle man kunna ha en nummerbyrå för hela världen. Det fungerar inte rent praktiskt eftersom det skulle behövas oändligt många telefonister, oändligt stora kataloger för dem, en gigantisk ström av uppdateringar från alla i hela världen som flyttar eller byter nummer, samt att det innebär att hela världen blir beroende av en enda informationspunkt för att kunna ringa. I DNS-världen har man samma problem. Det går inte att ha all information i en och samma server av praktiska skäl. Man har i stället delat upp informationen så att olika servrar har hand om olika delar av den. Vid varje punkt i ett domännamn kan man införa en teknisk ansvarsgräns. Två saker är viktiga här: för det första är det fråga om att man kan ha en gräns vid varje punkt, men man måste inte; för det andra är det fråga om tekniska gränser, dvs. gränser och signalering mellan servrar, inte om vilken organisation eller administration som har ansvar för namnen i sig. Mellan servrarna som har hand om olika informationsmängder finns sedan ett system av hänvisningar. Genom att fråga sig fram och med hjälp av hänvisningarna kan man alltid hitta fram till den server som har hand om en viss del av informationen. Hänvisnings- systemet skulle kunna bli väldigt komplext om alla skall kunna hänvisa till alla andra, men för att undvika det problemet så följer hänvisningarna domännamnsträdet helt slaviskt. Tjuvknepet i DNS-världen är att man inte i förväg talar om för någon att det finns hänvisningar i systemet. Alla datorer tror att det bara finns en nummertjänst. Det finns en namnserver som har hand om roten till DNS-systemet. Den innehåller bara en liten, liten databas (mindre än 1/10 av en vanlig PC-diskett). I den databasen finns bara hänvisningar. Om man frågar denna rotnamn- server någon DNS-fråga så kommer man alltid bara att få till svar Jag vet inte, prata med honom därborta!, men det är just det som är det viktiga, rotnamnservern håller reda på vem man skall prata med. Hänvisningarna kan finnas i alla nivåer i databasen, och rotnamnservern är bara den första man frågar. Man kan bli hänvisad , men börjar man med rotnamnservern så kan man alltid komma fram dit man skall. 4.3Uppslagning: ett exempel Låt säga att vi vill veta vad webbservern . har för Internetadress. Det vi skall slå upp i DNS-databasen är alltså adressposten för namnet . Vi frågar alltså rotnamn- servern vad . har för adress. Figur 3: En fråga, steg 1: rotnamnservern och hänvisning. Rotnamnservern svarar på sitt vanliga manér: Jag vet inte, men jag ser att det du frågar om slutar på se., och då skall du prata med den där datorn där borta, för det är den som har hand om allt som slutar på se.. Vi blir alltså hänvisade till en annan dator som förväntas känna till mer. Vi skickar då samma fråga till denna se.- server: Vad har . för adress?. Figur 4: En fråga, steg 2: se.-servern och vidare hänvisning. Till svar får vi kanske ytterligare en hänvisning: Jag vet inte, men jag ser att det du frågar om slutar på . och då skall du prata med den servern därborta.. Vi går vidare igen, och ställer nu samma fråga för tredje gången, nu till en tredje dator: Vad har . för adress?. Figur 5: En fråga, steg 3: svaret. Sannolikt får vi nu veta svaret: . har adressen 192.168.3.31.. Äntligen kan vi koppla upp oss mot webbservern och hämta de webbsidor vi var ute efter. Beskrivningen ovan lämnar bl.a. följande frågor öppna: Hur vet man var rotnamnservern finns? För att man alltid skall kunna ringa någonstans, så är telefonnumret till nummerupp- lysningen publicerat och gjort allmänt känt, genom media och informationskampanjer. Folk kan det utantill, och ingen behöver tveka om vilket nummer som är rätt. Eftersom alla känner till det så går det inte att förfalska. På samma sätt måste alla datorer som vill kunna använda DNS-systemet veta vilken adress rot- namnservern har. Internetadressen till rotnamnservern är alltså Den finns publicerad på flera ställen, och tillhandahålls av operatörer och andra i branschen. Alla namnservrar har den listan liggande i en fil, och man kan lätt kopiera den mellan olika namnservrar. Vad händer om rotnamnservern stannar eller tappar kontakten med nätverket? Det finns inte bara en enda rotnamnserver. Det finns totalt 13 rotnamnservrar i världen och alla har identiska kopior av databasen. Om en tillfälligt försvinner väljer man bara en annan. Det finns följaktligen egentligen 13 olika adresser att hålla reda på. Programvaran som ställer frågor läser in de 13 adresserna från en fil och väljer sedan helt automatiskt vilken rotnamnserver den vill prata med och byter om det blir nöd- vändigt. Det är alltså inte kritiskt att alla rotnamnservrar är tillgängliga. Internet skulle klara sig alldeles utmärkt även om hälften av dem försvann. Hur vet man var se.-servern finns? Det ingår i själva hän- visningen som kommer från rotnamnservern. Rotnamnservern vet alltså var den finns och talar alltid om det när den hänvisar. Redundans på alla nivåer Vad händer om se.-servern stannar eller tappar kontakten med nätverket? På samma sätt som med rotnamnservern så finns det inte bara en server som håller reda på alla namn som slutar på se. I fallet se. finns det sju servrar som har identiska kopior av den delen av databasen. När en rotnamnserver hänvisar, så hänvisar den till alla sju. Fråga någon av de här sju datorerna, med de här sju adresserna. Alla av dem vet mer än jag. Hur ser man till att kopiorna är identiska? Servrar som skall ha identiska kopior av en viss del av databasen är konfigurerade så att en av dem är masterserver (kallades tidigare primary server). De övriga servrarna, slavservrarna (secondary servers), i gruppen kontrollerar med jämna mellanrum om masterserverns exemplar av databasen har ändrats genom att ställa en speciell fråga till den. Om en slavserver upptäcker att masterservern har en nyare version av innehållet i databasen än vad den själv har, ber den masterservern att skicka över den nya versionen av innehållet. För enkelhets skull kopieras i allmänhet hela databasdelen vid varje sådant tillfälle, inte bara ändringarna. Skall något ändras i en viss del av DNS-databasen, så ändrar man alltså i masterservern för den delen av databasen, varefter slavservrarna kopierar informationen till sig, och alla kommer att ha identiska kopior. Det blir alltså vanligen ett visst tidsglapp just vid uppdateringar, när masterservern har en nyare version av databasinnehållet än vad slavservrarna har. Eftersom man oftast bara ändrar små detaljer i databasen, så är kopiorna i alla fall nästan rätt till dess att kopieringen har skett fullt ut, så det gör inte så mycket. Moderna masterservrar talar också om för sina slavar när det har skett en uppdatering, så att slavarna snabbt kan kopiera en ny version av databas- delen. Blir det inte väldigt hög belastning på rotnamnservrarna? Inte så hög som man skulle kunna tro. Anledningen är att inte alla frågeställare går till rotnamnservern först. En frågeställare sparar nämligen alla svar . Om frågeställaren i exemplet ovan vill ha tag i adressen till pc3.acme.se. så kommer den ihåg att Jag frågade rotnamnservern om ett namn som slutade på se. men då fick jag bara en hänvisning till svar. Jag går direkt till någon av se.- servrarna han hänvisade till.. Eftersom även svar nummer två ovan sparades kan man till och med hoppa över nästa steg med samma resonemang. Jag frågade en se.-server om ett namn som slutade på . och då fick jag bara en Jag går direkt på acme.se.-servern. Varken rotnamnservern eller se.-servern behöver alltså bli inblandade i denna andra fråga, och belastningen på dem minskar drastiskt. Gäller frågan i stället datorn server.cafax.se. så kan man hoppa över steg ett, men inte steg två. Detta sätt att gömma undan svaren nära till hands och återutnyttja dem kallas cachening (av franskans cache = gömställe) och är en vanlig teknik för att spara resurser i många datorsammanhang. Systemet med hänvisningar och cachening är fiffigt ur flera syn- vinklar: dels skapar det en lokalitet i systemet som gör att den som har ansvar för själva informationen lätt kan uppdatera sin del av databasen utan att blanda in andra, dels minskar belastningen på servrarna högre upp i systemet. Hänvisningarna kallas på DNS-språk för delegeringar. En DNS- databasdel innehåller enkelt uttryckt alla uppslagsnycklar som slutar på ett visst domännamn utom de namn man har delegerat ut. Låt oss gå tillbaka till namnträdet. Man kan tänka sig att när DNS-systemet startades låg allting i samma fil på samma server. Efterhand har man delat ut ansvaret för en viss domän till någon annan, och då flyttar man bort all information om den domänen ur den befintliga servern och lägger den i en ny server. I den gamla servern stoppar man in en hänvisning till den nya servern i stället för all gammal information. Figur 6: Före delegering av se.-domänen. Figur 7: se.-domänen delegeras ut till en annan server. Delegering av domäner sker på samma sätt på alla nivåer i DNS. Det är alltså fullt möjligt att ur se.-domänen i sin tur delegera ut t.ex. domänen . Det skulle se ut så här i vårt träd. Figur 8: . delegeras ut ur se. Vi kan se att information om . fortfarande ligger kvar hos rotnamnservern i vårt exempel, och att information om . ligger kvar hos den server som har hand om se. Följande princip gäller alltså: om man inte har delegerat ut ett domännamn, ligger det tekniska ansvaret för databasen för den domänen hos den server som har den omslutande (eller överliggande, om man vill) domänen, och den omslutande domänen kan finnas flera steg upp i trädet (. handhas inte av com. utan av roten i detta exempel). Det finns två typer av DNS-tjänster en dator kan tillhandahålla. Den kan innehålla en del av databasen och svara på frågor angående den del av databasen den innehåller, som jag har beskrivit ovan, men den kan också vara av typen tjänst till andra lokala datorer att leta upp svaret på vilken DNS-fråga som helst. De flesta vanliga datorer har inte programvara som klarar att traversera DNS-trädet, dvs. att gå till rotnamnservern, följa hänvisningar (kanske i flera steg), cachea information osv. Det är ett omfattande arbete som kräver en hel del programkod. Att skicka en enstaka DNS-fråga är däremot inte så svårt, så det klarar alla datorer . För att lösa problemet finns det DNS-servrar som hjälper till att svara på frågor. Till dem kan man ställa vilken DNS- fråga som helst, varvid de så att säga på uppdrag går ut och traverserar (letar igenom) DNS-trädet, följer hänvsningar, cachear och allt som skall till. När de har hittat svaret skickas det tillbaka till frågeställaren. Frågeställaren har alltså inte behövt göra något mer än att skicka en enda fråga till en viss bestämd, närbelägen server och sedan bara vänta på svaret. Figur 9: Resolvern hjälper till att hitta DNS-information. Resolvern cachear som sagt alla svar den får från andra servrar. Om en (annan?) frågeställare kommer strax efter och frågar efter samma information som resolvern har hämtat fram, så finns ju svaret i cachen, och resolvern har då ingen anledning att upprepa manövern utan svarar med var den redan vet. Figur 10: Resolvern svarar ur sin cache om den kan. DNS-systemet är troligen världens största distribuerade databas. Var och en kan sköta sin egen del av databasen. Denna lokala administration underlättar arbetet att hålla databasen uppdaterad, men eftersom det inte har funnits någonting i DNS som verifierar vem som har stoppat in vilken information, så leder det också till att det är lätt att ljuga – dvs. stoppa in falsk information och t.ex. utge sig för att vara någon annan än den man egentligen är. Falsk DNS-information öppnar möjligheter för att stjäla annan information (e-post och annat) och störa transaktioner (elektronisk handel, fakturor m.m.). Det är också viktigt att med säkerhet kunna veta att något inte existerar i DNS, så att inte frånvaron av information kan förfalskas. Särskilt påtagliga blir problemen om man vill använda dynamisk DNS, dvs. man vill tillåta datorer på nätet att införa förändringar i DNS-informationen i körande DNS-system. Det är då extra viktigt att säkerställa att informationen kommer från rätt källa. Problemen har naturligtvis uppmärksammats och det finns nu tekniker för betydligt säkrare hantering av DNS-information med hjälp av Secure DNS (DNSSEC). Grundconcepten i DNSSEC är checksummor och asymmetrisk kryptering. Checksummor är tal man får fram genom att applicera en slug matematisk algoritm på en viss informationsmängd. Algoritmen är så utformad att minsta ändring av informationen leder till en förändring av checksumman. Om den ärliga DNS-servern räknar ut checksumman för alla sina poster i DNS, och sedan krypterar cheksummorna en efter en, samt bilägger den krypterade checksumman till respektive post när den svarar på DNS-frågor, så kan frågeställaren beräkna en egen checksumma för och jämföra den egna med den medskickade checksumman. Om checksummorna är lika kan man vara säker på att informationen inte har förvanskats på vägen, och att den verkligen kommer från rätt avsändare. För att detta skall fungera måste frågeställaren kunna dekryptera den medskickade checksumman. Detta kan man åstadkomma med asymmetrisk kryptering. Vid asymmetrisk kryptering har man alltid två kryptonycklar som bildar ett par; en nyckel för att kryptera med, och en annan för att dekryptera med. DNS- administratören för en domän beräknar checksummor för alla sina poster, och krypterar dem med den ena nyckeln. Den nyckeln håller han mycket hemlig. Genom att publicera den andra nyckeln (den för dekryptering) vitt och brett, kan alla som så vill få tag i den och använda den för att dekryptera de medsända check- summorna vid DNS-trafik. Kvar är nu bara problemet att kontrollera att det är rätt dekrypteringsnyckel man har fått tag i. För att klara det problemet har DNSSEC inbyggda mekanismer för att även tillhandahålla dekrypteringsnycklarna på ett genomtänkt och säkert sätt. Dekryp- teringsnycklarna lagras också som poster i DNS, och är därmed allmänt tillgängliga. Nycklarna förses med checksummor av precis samma typ som all annan DNS-information, och man kan då även verifiera nycklarnas äkthet. Frågeställaren måste kunna lita på roten till all information, och måste ha tillgång till en nyckel från början för att komma igång. Denna nyckel kommer att vara så allmänt känd att det kommer att bli omöjligt att förfalska den. Denna nya säkerhetsteknik för DNS är ganska komplicerad men höjer säkerheten drastiskt. Det kommer att ställas betydligt större krav på DNS-frågeställarna om de vill kunna utnyttja tekniken. Det blir många checksummor att räkna och mycket dekrypterande att göra och bägge är resurskrävande transaktioner. är den nya tekniken helt bakåtkompatibel vilket gör att befintliga DNS- system som inte kan eller vill utnyttja säkerhetstekniken kommer att kunna fortsätta köra precis som vanligt, utan några större förändringar i resursåtgången.