Domain Name System – DNS

Det här kapitlet behandlar DNS översiktligt. Det är ett utdrag ur ett mer omfattande kapitel i boken. Hur vi klarade oss innan DNS behandlas. Namnstrukturer och toppdomäner gås igenom. Hur DNS-frågor görs och hur svaren mellanlagras och behandlas. Kapitlet är tänkt att kunna läsas fristående men fungerar bäst om du vet hur TCP/IP fungerar.

DNS är ett protokoll för att i ett globalt nätverk av DNS-servers kunna ställa frågor och få svar. Om den aktuella servern inte känner till svaret så kan den svara med en hänvisning till en annan server istället. Program för DNS och protokollet har funnits i tjugo år och fungerar enligt samma principer. Två saker krånglar till det om du vill förstå DNS:

  • Användningen och begreppen har ändrats med tiden. Eftersom DNS fungerar väl globalt så finns det grupper som vill lägga in fler och fler funktioner i strukturen.
  • I Windows används också begreppet domäner. Från början hade Windows-domäner ingenting med DNS att göra, men med Windows Server 2000 och senare 2003 används DNS även för detta. Tanken är att förenkla men eftersom de flesta organisationer inte vill visa sin interna struktur externt så blir det i alla fall komplext. (Tanken med DNS var från början att alla DNS:er ska kunna fråga varandra.)

Nodnamn (host name) och domännamn (domain name) är två olika saker. FQDN är ett namn som fungerar i DNS-strukturen och kan närmast översättas med komplett domännamn.

I det här kapitlet utgår vi från dagens begrepp och hur grundfunktionerna i DNS används. DNS kan även användas för lastdelning och det kan användas för dynamiska uppdateringar då en nod byter IP-adress (Dynamic DNS enligt RFC 2136). Det finns även ett tilllägg DNSSEC med vars hjälp man kan upptäcka förfalskade DNS-data. Dessa funktioner behandlas dock inte i detta kapitel.

Så här långt har guiden mest handlat om IP-adresser. Men de flesta användare använder inte IP-adresser utan kommer bara i kontakt med nodnamn. I den här guiden används benämningen nodnamn, på engelska används ofta begreppen ”host name”. I DNS används begreppet domännamn (domain name) vilket även omfattar namn som www.bolag.se. Ett mer exakt begrepp är det engelska FQDN, Fully Qualified Domain Name. Jag har använt begreppet komplett domännamn eller FQDN nedan för att särskilja det från nodnamn (det är inte ovanligt att en dator har FQDN som www.bolag.se medan nodnamnet speglar maskinens uppbyggnad som 2GXeonDuo).

Hosts-filen

internet och TCP/IP har en gång fungerat utan DNS men i praktiken kan vi inte vara utan det idag. I stort sett alla TCP/IP-implementationer har kvar den tidiga metoden i form av en hosts-fil. I Windows XP nås den under C:WINDOWSsystem32driversetc. I filen finns i princip två kolumner, den högra är nyckeln till det vi letar med. När vi får träff så kontrolleras vad som står till vänster. Om vi till exempel skriver in sekvensen ”x.acme.com” i en webbläsare så fungerar i stort sett alla program så att de använder proceduren ”gethostbyname”. Och från hosts-filen kan vi då erhålla resultatet 38.25.63.10.

102.54.94.97    rhino.acme.com    # source server
38.25.63.10     x.acme.com        # x client host
127.0.0.1       localhost

Testa själv

Du kan enkelt testa hur hosts-filen fungerar. I de flesta Linux-varianter kan man välja om DNS ska användas i första hand eller om hosts-filen ska användas. I Windows används hosts-filen till att uppdatera den lokala DNS-cachen på klienten.

Ta reda på en IP-adress som används och styr ett komplett domännamn som www.kth.se till denna IP-adress via ett tillägg till hostsfilen. Mata sedan in domännamnet i en webbläsare. Du kommer att styras enligt hosts-filen. Även efter att denna ändring tas bort ur hosts-filen ligger denna information kvar ett tag, detta beror på att man mellanlagrar DNS-information (alltså även i en vanlig arbetsstations resolver).

Namnstrukturer

DNS inför två stora förändringar jämfört med hosts-filer. För det första blir det svårt att genomföra globala förändringar om varje dator har en lokal fil. Under internets tidiga år gjorde man så att det fanns en masterfil som användare kunde hämta regelbundet. Men den här modellen håller inte om vi kräver att ändringar ska slå igenom fort och kunna hantera miljontals användare. DNS hämtar istället bara den information som behövs, och den hämtas när den behövs. En nyckel till att hantera informationen effektivt är sedan att svar mellanlagras (cachas).

DNS hämtar bara den information som behövs och informationen mellanlagras.

DNS införde dessutom en namnstruktur. Tidigare hade varje nod ofta ett enkelt namn som rhino eller alma. Men om det nu fanns två servers med samma namn. Vem är mest alma om två universitet hade samma datornamn? Och hur ska vi hantera alla maskiner som har namn som anknyter till funktioner, typ mailserver, postman, webserver och nameserver?

Ett komplett domännamn innehåller normalt minst tre nivåer. Två exempel är www.firma.se och mail.bolag.com. Detta kallas som sagt ett FQDN och utläses i det första fallet som noden ”www” i domänen ”firma.se”. Ett komplett domännamn går hela vägen från den enstaka noden ända upp till roten (ibland understryker man detta genom att lägga till en extra punkt som refererar till roten, till exempel ”www.firma.se.”). Ett komplett domännamn går ofta att översätta till en IP-adress, men det är ofta intressant att ställa andra frågor än bara IP-adresser. Vi kan till exempel fråga vilken nod som är ansvarig för domänen, vi kan fråga om det finns en e-post server med mera.

Toppdomäner

Nationella toppdomäner betecknas ofta ccTLD’s: Country Coded Top Level Domains. De generiska betecknas gTLD’s: Generic Top Level Domains.

Sedan länge har toppdomänerna funnits i två varianter. Nationella toppdomäner som se, no och de samt generiska som com och net. De generiska utökades under 2000 till 2002 och omfattar idag:

Under 2007 tillkom fler nya domäner som cat, jobs, mobi, travel. Andra förslag var mail och tel.

Toppdomännamn.

Generiska toppdomäner styrs av ICANN. Hur de används har styrts av riktlinjer för respektive domän. De nationella subdomänerna har fungerat olika i olika länder. I England har de till exempel ofta använt subdomäner som co och ac under sin toppdomän uk. Amerikanska bolag använde sällan domänen us utan de generiska. I Sverige var man under 1990-talet väldigt restriktiv men utdelning under ”.se” och krävde registrerade varumärken, föreningar eller aktiebolag. Enskilda firmor registrerades under länsbokstäver (detta harmonierar med hur bolagsnamnen hanteras). Från 2003 gäller dock principen först till kvarn under .se-domänen och konflikter löses i efterhand.

Eftersom det under 1990-talet var enklare att registrera com, net och org-domäner så blev de ofta populära och till och med svenska statliga utredningar dök upp under com-domänen. Under 1990-talet började även namnpirater att registrera organisatoriska domäner eller vanliga felslagningar av populära domäner för att sälja dem vidare. Den praktiska lösningen på detta blev att sökmotorer används oftare eftersom vi inte vet om vi ska söka på ”bolag.com” eller ” bolag.net” eller ”bolagab.se”. Och i princip kan den som administrerar en domän bara styra hur subdomäner till just den domänen delas ut.

Med toppdomäner och en namnstruktur får vi ordning på namnen så att de blir unika. Vi kan skilja på alma.kth.se och alma.lth.se. Högst upp (det vi kallar roten ologiskt nog) har vi alla namn. De så kallade rotservrarna känner sedan till de knappt 300 toppdomänerna och vilka namnservrar som har vidare information. Poängen är sedan att de hänvisar till dessa servrar för mer information. På samma sätt kan ett par maskiner vara ansvariga för se-domänen, men de innehåller främst information om varje subdomän som registreras och vilken namnserver som har informationen. Om vi granskar domänen kth.se så ser vi att det finns två noder vid namn www och alma.

Toppdomäner högst upp följs av subdomäner.

Däremot är fy och troligen även ke subdomäner som delegeras vidare. I DNS-strukturen hanteras enkla nodnamn och domäner på samma sätt. Från namnen i sig kan vi inte se att www är en nod och ke är en subdomän. (Det finns dock ett antal konventioner som till exempel www för en server som svarar på port 80 och ns för den nod som hanterar domäner.) Därför skulle vi få meddelandet ”Non Existing Domain” förkortat som NXDOMAIN om vi frågade efter det felaktiga ww.kth.se.

Resolvers

En vanlig arbetsstation eller PC innehåller en liten DNS-resolver. Applikationer skickar som sagt en uppkopplingsbegäran med kommandot gethostbyname. DNS-resolvern på din PC löser detta men den tar hjälp av en fullödig DNS. Denna skiljer sig från din PC:s enkla på så sätt att den kan ställa rekursiva frågor. Ur PC:ns synpunkt ställs frågan till en DNS (1) och strax efter kommer svaret (8).

En DNS har en tabell med IP-adresser till de 13 rotservrar som finns globalt. Frågan skickas till en av dessa. Rotservern svarar (3) med att den är just rotserver, men den här frågan avseende se-domänen är delegerad till en (eller fler) servrar. Till DNS-protokollet hör också möjligheten att lägga till extra information för att minska antalet frågor, så ett fält ”additional information” innehåller information om IP-adressen till ns.sunic.se. Vår DNS skickar nu frågan till ns.sunic.se (4) som svarar att information om kth.se har delegerats vidare. Eventuellt sker liknande delegering en eller två gånger till men tillslut hamnar vi hos en DNS som är ansvarig för denna domän. Denna svarar med IP-adressen för www.kth.se (7). Vår DNS kan nu leverera svaret till vår PC-klient (8). Hemligheten med DNS är alltså att servrarna hela tiden delegerar frågan till någon som vet. Gott ledarskap alltså.

Stora DNS:er kan ställa rekursiva frågor.

Svaren från en DNS innehåller även tidsvärden (Time To Live). Detta gör att svaren kan mellanlagras och här ligger mycket av effektiviteten. Nästa gång vår DNS behöver fråga om något som avser hela se-domänen så vet den att den kan skicka frågan till ns. sunic.se. Rotservern behöver inte belastas igen. Om en annan klient skickar samma fråga till vår DNS så kan den direkt svara med IPadressen. Hur länge svaren ska sparas kan variera. Typiska värden kan vara 8 till 24 timmar. Kortare och längre värden förekommer, till exempel brukar rotservrarna meddela att svar vad gäller toppdomäner kan mellanlagras i sju dygn.

Eftersom svar mellanlagras tar det tid innan ändringar slår igenom. Vill man byta IP-adress på en maskin bör man först ställa ner tidsvärdet så den lagras kort tid och sedan genomföra förändringen. Har man sin DNS utlagd till en operatör tar det även tid innan de genomför förändringen, speciellt om man ska byta vilken server som är ansvarig för en domän, en så kallad domain transfer. Felaktiga ändringar får stort genomslag och säkerhetsmässigt vill operatörerna vara säkra på att den som begär flytt och ändringar är behörig. Ändringar kompliceras också ofta av att fler servrar blandas in.

Eftersom DNS är en viktig del av internet behövs redundans. Om du försökt registrera en ny domän så har du säkert fått frågan om vilka maskiner som ansvarar för domänen. Det räcker inte med att ange en adress utan två. Förr användes begreppen primary och secondary DNS dessa har idag ersatts av master och slave. En master-DNS kan ha flera slave-DNS. Det är master-DNS som innehåller informationen i original och slave-DNS kollar regelbundet efter förändringar och hämtar vid behov uppdaterad information. Överliggande domän har normalt vetskap om två eller fler servers så DNS-frågorna kan besvaras utan att vara beroende av enstaka servrar.

Fråga och svar

Nedan visas en inspelning av ett paket till och från en DNS-server. UDP och port 53 används som väntat.

För att kunna matcha svar med fråga används en identitet (2 byte). Sedan följer 16 bitar som används för flaggor, här kan vi se att det är en standardfråga och DNS-servern förväntas använda en rekursiv sökning. I övrigt består en DNS-fråga av fyra delar: question (fråga), answer (svar), authority (behörighet) och additional (tillägg).

Några vanliga posttyper.

Efter flaggorna följer information om huruvida dessa delar används och deras antal. I detta fall följer en fråga och den byggs upp. Frågan innehåller vår söknyckel samt två fält: typ och klass. Klassen är enkel då den i praktiken alltid är IN, det vill säga internet. Typen av fråga varierar. Det finns cirka 50 olika posttyper (type) definierade varav några av de vanligaste syns här till höger.

 

I svaret ser vi inte bara själva IP-adressen utan också information om hur länge svaret kan mellanlagras (TTL Time To Live). Vi ser också att den server som svarat inte är ansvarig (authority) för domänen. Servern svarar också med att den tillåter rekursiva frågor.

 

Om man använder kommandot ”dig” i Unix för att felsöka i DNS får man svar som stämmer väl med hur DNS-frågor och svar ser ut. Om allt går bra erhålls svaret NOERROR, vid problem får man ofta meddelandet NXDOMAIN samt information om vilken DNS som svarat detta. På detta sätt kan man se hur långt namnupplösningen fungerade.

Baklängesuppslagning

DNS-strukturen kan användas åt andra hållet. Vi kan allstå få svar på frågan ”Om vi har en IP-adress vad motsvarar det för domännamn?” Baklängesuppslagning görs av flera applikationer i samband med loggning, felsökning och verifiering. DNS bygger på att den mest signifikanta delen finns till höger (med början i toppdomänen).

IP-adresser har den mest signifikanta delen till vänster så man löser upp adresser från vänster till höger. En konvention är att man har reserverat domänen ”in-addr.arpa” för baklängesuppslagning. Normalt tar DNS och även verktyg som nslookup och dig hand om detta själv. Vill vi veta domännamnet för exempelvis 192.3.4.5 så kommer själva frågan ha formen ”5.4.3.192.in-addr.arpa” men det slipper vi som användare oftast tänka på.

Stöd för IPv6 i DNS

DNS är en nyckelfunktion för införandet av IPv6. Posttypen AAAA för IPv6-adresser kom med tidigt i arbetet med version 6. Även baklängesuppslagning togs fram ganska tidigt, idag sker det via domänen ip6.arpa som är reserverad för baklängesuppslagning (PTR-poster) inom IPv6. Däremot skedde DNS-frågor i många år fortfarande via IPv4. (Det var samma sak med routingprotokoll först, de kunde hantera IPv6-information men data utbyttes via IPv4.) Med Windows Vista och ett par Linuxvarianter kan din DNS-resolver idag ställa DNS-frågor över IPv6.

DNS-funktionen blir som sagt viktig med IPv6. Ett skäl är att IPv6-adresser kan vara långa och svåra att komma ihåg, vi behöver DNS för att kunna arbeta med namn istället. Ett annat skäl är att DNS kan styra vilken adress och vilket protokoll som kommer att användas. Om noden www.mittbolag.se har både en A- samt en AAAA-post men DNS bara frågar efter A-posten kommer applikationen att styras mot IPv4. Om DNS frågar efter bägge posterna kan applikationen välja, men då måste informationen hanteras mellan resolver och applikation och inte bara använda en enkel förfrågan typ GetHostByName.

Om DNS fortsätter att bara fråga efter A-poster kommer införandet av IPv6 att fördröjas. Det är alltså viktigt för framtiden att DNS kan hantera IPv6-förfrågningar.

Säkerhet och DNS

DNS är en vital del av internet och strukturen har utsatts för flera attacker, främst mot rotservrarna. Hittills har angriparna inte lyckats och internet skulle inte sluta fungera om en rotserver slogs ut. (De flesta frågorna till rotservrarna är fel delvis beroende på manuella felstavningar.)

Men DNS är känsligt och med ett lite mindre perspektiv kan en angripare ställa till med mycket. I en dåligt skyddad DNS kan någon ändra informationen så att frågor efter till exempel www.internetbank.se styrs till fel ställe. På samma sätt kan ett virus ändra i hosts-filen. Dessa metoder har använts historiskt för angrepp. Ytterligare ett sätt är att bygga ett litet program som lyssnar efter DNS-frågor och sedan skickar ett snabbt felaktigt DNS-svar. Det spelar då ingen roll att rätt svar kommer senare, DNS-klienten tar det första svaret.

För att förbättra situationen med DNS så finns en förbättrad variant som heter DNSsec. I DNSsec används digitala signaturer för att verifiera svaren.

Information från DNS-servrar har också kunnat användas vid attacker. Angripare hämtar information från en DNS och ser vilka servrar som har intressanta namn och får direkt information om dess IP-adress. Den mest använda programvaran för DNS-servrar, BIND, har historiskt sett haft flera brister som har rättats till.

Referenser

RFC 1034 och 1035 - DNS
www.internetstiftelsen.se - Information .se-domänen. Här finns även viss information om DNSsec.
www.isc.org - ISC utvecklar programmet BIND, en populär DNS-server. Manualen till BIND ger en bra bild av modern DNS.