Azine
Om tidningen Azine
Köpa Azine
Kontakta Azine
Hjälpa till
Annonsera i Azine
About Azine English

Senaste numret
Nästa nummer
Arkiv

Kurser/Skolor
Intervjuer
Forum

ACG
SUA
ACG Göteborg
AmigaGuiden

Annonsörer:
GGS-Data

Sponsorer:
AmigaRulez (Forum)
GGS-Data
WestSide Praetorian
M.Andersson

Försäljningsställen
GGS-Data
Guru Meditation


Senaste Nummer 8 Nummer 7 Nummer 7 bilaga Nummer 6 Nummer 5++ Nummer 4 Nummer 3 Nummer 2 Nummer 1









Vill du ha din banner här?
Skriv till [email protected]!
Välkommen till hela Sveriges Amigatidning.


ACGs maskot

Linux - Del 4: DNS och hur hittar allting rätt...?

I detta nummer tänkte jag att vi skall behandla DNS och namnuppslagning samt försöka räta ut de flesta frågetecknen kring domänhantering och hur det fungerar.
Idag har de allra flesta företag och organisationer av olika slag, en hel del privatpersoner också för den delen, ett domännamn. Exempel på domännamn kan vara:
  • ggsdata.se
  • pegasos.org
  • azine.nu
  • microsoft.com
Vem som helst kan skaffa sig ett domännamn från någon av de registranter som finns runt om i världen. Personligen brukar jag alltid använda Domaininfo i Sverige (www.domaininfo.com) för att registrera domännamn.
Man registrerar en domän för en viss tidsperiod, dock minst två år. Priserna kan variera beroende på vilken top­domän som önskas.
Top­domän? Det var ett nytt ord för vissa kanske? För att inte bli riktigt långrandig med att berätta hela Internets historia skall jag fatta mig mycket kort om varför top­domäner ser ut som de gör. Exempel på top­domäner är:
  • .se
  • .pl
  • .dk
  • .com
  • .edu
  • .org
  • .gov
Under Internets begynnelse på slutet av 60­talet och under 70­talet, efter ARPA­nets frisläppande, började olika organisationer, universitet, sjukhus, företag och regeringsorgan koppla upp sig mot detta nya gemensamma nätverk av datorer och informationsutbyte.
För att kunna skilja på vilken verksamhet som anslöt sig till detta, vid den tiden amerikanska nätet, var man tvungen att adressera och gruppera dem olika.
Till exempel grupperades universitet och skolor under en gemensam top­domän som kom att heta .edu för Educational Institutes. Alla regeringsorgan under .gov för Government och alla organisationer under .org för Organisation osv.
Efterhand när andra länder anslöt sig i takt med att Internet växte började respektive lands prefix användas, exempelvis .se för Sverige, .dk för Danmark osv.
Vi har redan behandlat TCP/IP i en tidigare artikel och vi är helt på det klara med att datorer och resurser adresseras och går att nå och använda via en IP­adress vilken, enkelt förklarat, är en dators unika adress på ett globalt nätverk.
Problemet som genast uppstår, trots att det finns övermänniskor, är att komma ihåg alla dessa IP­adresser till företag, sjukhus, universitet och även till pizzerian nere på hörnet som har beställning on­line via nätet.
Tänk att behöva komma ihåg 80.69.226.133 för att kunna slå upp ett telefonnummer hos Gula Sidorna eller 80.80.20.46 för att gå in och kolla forumet på Amigarulez och tiotals andra IP­adresser för att kunna utföra sina bankärenden eller boka flygbiljetter.
Fullständigt ohållbart att hålla på så i längden. Det är mycket lättare att hålla reda på namn eller ord som lätt kan associeras med den sida eller det företag man vill besöka på nätet. Därav finns tjänsten DNS (Domain Name Service) som snurrar på tusentals DNS­servrar runt om i världen vars enda uppgift är att länka domännamn och sk. records till IP­adresser.
En DNS­server byggs upp av följande grundstenar vilka vi kommer att behandla var för sig efterhand:
  • forward zonfil
  • reverse zonfil
  • serienummer
  • records (även kallat pekare)
En zonfil kan liknas vid en databas som innehåller information om vilka namn, tillhörande gällande domän, som skall knytas till vilka IP­adresser.
Som exempel kan vi tänka oss ett företag som heter Bolaget AB och som precis har registrerat domänen bolaget.nu
Vad Bolaget AB behöver är en styck DNS­server körandes exempelvis Linux eftersom det är det OS vi behandlar i denna skolan.
DNS­tjänsten i Linux heter Bind och versionen i skrivande stund är Bind 9.2.2
Eftersom installationen av Bind inte är särskilt svår (endast installera ett DEB eller RPM paket) så tänker jag inte ta upp den biten utan fokuserar på konfigurationen.
Bolaget AB har således installerat Bind 9.2.2 på sin server och anslutit servern till Internet genom sin brandvägg. Servern sitter på företagets DMZ (DeMilitarized Zone) och har fått IP­adressen 215.46.87.15
Det första som måste göras är att skapa en zonfil, dvs. den fil i systemet som skall innehålla information om var omvärlden kan hitta deras webserver, ftpserver och eventuell mailserver m.m.
Först måste vi tala om för Bind 9.2.2 var forward zonfilen kan hittas. Filen som skall editeras är /etc/named.conf och här lägger Bolaget AB till följande information:
zone bolaget.nu {
        type master;
        file /var/named/bolaget.nu.hosts;
        also­notify {
                198.173.151.42;
                };
        notify yes;
        };
Nästa steg blir att skapa själva forward zonfilen, bolaget.nu.hosts, i /var/named och den skapas enklast med hjälp av vi eller nån annan texteditor alternativt kan man utgå från mallfilen som finns. Vi väljer att skapa den själva och då skall den se ut så här:
$ttl 3600       ; 1 hour
bolaget.nu.        IN      SOA     ns1.bolaget.nu. admin.bolaget.nu. (
                           2003090801
                           10800       ; refresh (3 hours)
                           3600        ; retry (1 hour)
                           604800      ; expire (1 week)
                           86400 )     ; minimum (1 day)
bolaget.nu.        IN      NS         ns1.bolaget.nu.
bolaget.nu.        IN      NS         ns1.granitecanyon.com.
ns1.bolaget.nu.    IN      A          215.46.87.15
www.bolaget.nu.    IN      A          215.46.87.20
mail.bolaget.nu.   IN      A          215.46.87.22
ftp.bolaget.nu.    IN      CNAME          www.bolaget.nu.
bolaget.nu         IN      MX         10 	mail.bolaget.nu.
Nu är en zonfil för bolaget.nu skapad med all information som behövs. Förklaring till ovanstående zonfil är som följer:
$ttl 3600       ; 1 hour
Detta är den tid för vilken alla records (pekare) i zonfilen skall leva innan de blir uppdaterade om ändring av innehållet i zonen sker.
bolaget.nu.        IN      SOA     ns1.bolaget.nu. admin.bolaget.nu. (
                           2003090801
                           10800       ; refresh (3 hours)
                           3600        ; retry (1 hour)
                           604800      ; expire (1 week)
                           86400 )     ; minimum (1 day)
Detta anger domännamnet och SOA record, dvs. vilken DNS­server som är ansvarig för zonen och mailadressen till dess administratör. Observera att mailadressen anges utan @ tecken. Det är viktigt att alla punkter och paranteser finns med på rätt ställe.
Siffrorna här anger först och främst serienumret på zonfilen och skall alltid inkrementeras vid varje uppdatering av innehållet. Jag väler alltid att skriva serienumret i formen: årmånaddagtillfälle dvs. år 2003, månad 09, dag 08, tillfälle 1. Efter detta är det bara att följa samma standard.
Om jag exempelvis gjorde ändringar dagen efter i två omgångar hade serienumret varit 2003090902
Resten är defaultvärden för olika timeouter och bör lämnas orörda för att inte orsaka propageringsproblem ute på Internet.
bolaget.nu.        IN      NS         ns1.bolaget.nu.
bolaget.nu.        IN      NS         ns1.granitecanyon.com.
Ovan rader talar om vem som är DNS servrar för domänen (auktorativa). Vi kan ha i princip hur många DNS servrar som helst för vår domän, men endast en master DNS server. I detta fallet är vi själva master DNS server och döper vår server till ns1.bolaget.nu
Resten av våra DNS måste förbli slave DNS­servrar vilka får en sk. Notify när zonfilen på master DNS­servern har ändrats och serienumret har inkrementerats.
I vårt fall har vi en slave DNS­server i ns1.granitecanyon.com som har IP 198.173.151.42 enligt tidigare konfiguration av /etc/named.conf dessa pekare kallas för NS pekare (Name Server).
ns1.bolaget.nu.    IN      A          215.46.87.15
Här definierar vi för första gången en A­pekare eller host record som det också kallas. Just detta record definierar vår egen DNS­server.
www.bolaget.nu.    IN      A          215.46.87.20
Ytterligare en A­pekare, men denna gången definierar vi vilken server som skall svara på www.bolaget.nu
Denna server ligger på samma DMZ som vår DNS­server, men på en annan IP­adress.
mail.bolaget.nu.   IN      A          215.46.87.22
Ännu en A­pekare som denna gången pekar ut vår mailserver.
ftp.bolaget.nu. IN CNAME www.bolaget.nu.
En ny recordtyp som heter CNAME (Canonical Name) används här. Detta kan liknas vid ett alias eller att en server är also known as.
ftp.bolaget.nu är alltså samma server som www.bolaget.nu
bolaget.nu.        IN      MX         10   mail.bolaget.nu.
Detta är en av de viktigaste pekarna för en domän, MX­pekaren eller Mail Exchanger. Pekaren definierar vilken server som skall svara på mail för domänen bolaget.nu
Siffran 10 anger prioritet och just 10 är default. Vi kan ha flera MX­pekare utifall vår ordinarie mailserver skulle tas ur bruk eller helt enkelt gå sönder.
I ett sådant läge kan man lägga upp ytterligare en MX­pekare till en annan mailserver med en högre prioritet, dvs. lägre prionummer.
Nu har vi gått igenom en standard DNS­zonfil och hur den kan se ut. Naturligtvis kan zonfiler bli väldigt komplexa med många objekt och delegering av sub­domäner (hanteras senare i denna artikel).
Mer än så här behöver man vanligtvis inte göra om man ska köra egen DNS. Den Internetleverantör (ISP) man har brukar bistå med reverse zonfil för bakåtuppslagning av namn, men innan vi tittar på det skall vi klara ut vad namnuppslagning egentligen är.
Namnuppslagning är, som sagts tidigare, till för att vi inte skall behöva komma ihåg alla IP­adresser utan istället begagna oss av namn och ord vi lätt kan referera till. Vad som händer i din dator ut mot ditt LAN eller Internet när du skall surfa eller pinga en annan dator med namn är följande:
  • Ditt kommando översätts till dataström
  • Din dator kommer att kontakta en DNS­server för att kolla upp vilken IP­adress exempelvis www.bolaget.nu har
  • DNS­servern skickar tillbaks IP­uppgifter till din dator
  • Din browser eller ditt pingkommando genomförs
  • Du får svar tillbaks i form av en websida eller Ping Reply alt. Request timeout
All kommunikation med DNS­servrar sker genom portarna TCP 53 och UDP 53 varför det är viktigt att dessa öppnas genom eventuell brandvägg.
Exempel med hjälp av kommandot nslookup:
C:\>nslookup
Default Server:  dns1.sigma.se
Address:  62.127.210.140> set q=any
> www.hillnet.se
Server:  dns1.sigma.se
Address:  62.127.210.140Non-authoritative answer:
www.hillnet.se  internet address = 194.236.106.180hillnet.se      nameserver = ns2.firewall1.nu
hillnet.se      nameserver = ns1.granitecanyon.com
> set q=ptr
> 194.236.106.180
Server:  dns1.sigma.se
Address:  62.127.210.140Non-authoritative answer:
180.106.236.194.in-addr.arpa    name = as1-6-6.dp.m.bonet.se106.236.194.in-addr.arpa        nameserver = dns.umea.se
106.236.194.in-addr.arpa        nameserver = dns.norrnod.se
106.236.194.in-addr.arpa        nameserver = dns.bostream.com
106.236.194.in-addr.arpa        nameserver = dns.bostream.net
106.236.194.in-addr.arpa        nameserver = dns2.bostream.net
dns.bostream.com        internet address = 212.217.211.20
dns.bostream.net        internet address = 81.26.228.2
dns2.bostream.net       internet address = 81.26.226.2
Vad är det vi har fått fram här? Jo, detta är ett forwarduppslag över vilken IP­adress www.hillnet.se har och kommit fram till att www.hillnet.se har IP­adressen 194.236.106.180
Samt ett reverseuppslag över vilket namn som är kopplat till IP­adressen 194.236.106.180 och fått fram att det är as1­6­6.dp.m.bonet.se
Detta verkar ju inte stämma kan man tycka, men faktum är att detta är korrekt även om det i vissa fall kan orsaka bekymmer att en DNS inte rapporterar tillbaks samma namn oberoende av forward eller reverseuppslagning.
I ovan fall är det vår ISP som kontrollerar reverseuppslagningen för ett helt IP­nät, nämligen 194.236.106.0/24 och eftersom det hänger flera kunder på samma nät finner man att administration av reverseuppslagning inte är värt tiden eller pengarna då det är frågan om väldigt många kunder.
Om man som företag äger ett IP­nät eller en del av ett IP­nät kan man välja att själv också köra reverseuppslagningen på sin DNS server för att undvika problem med exempelvis vissa mailservrar som automatiskt gör en reverseuppslagning för att garantera authority på den trafik man mottager och inte utsätter mailservern för malicious trafik eller annan trafik med onda avsikter.
Vi väljer i vårt exempel här att själva hantera reverse zon precis som vi redan har satt upp vår forward zon.
Först måste vi tala om för Bind 9.2.2 var reverse zonfilen kan hittas. Filen som skall editeras är /etc/named.conf och här lägger Bolaget AB till följande information:
zone 87.46.215.in-addr.arpa IN {
        type master;
        file var/named/87.46.215.in-addr.arpa;
        also-notify {
                198.173.151.42;
                };
        notify yes;
        };
Notera att vi definierar IP­nätet bakvänt utan sista oktetten därför att vi skall nu täcka in hela nätet 215.46.87.0 med vår reverse zon.
Nästa steg blir att skapa själva reverse­zonfilen, 87.46.215.in­addr.arpa, i /var/named och den skapas enklast med hjälp av vi eller nån annan texteditor alternativt kan man utgå från mallfilen som finns. Vi väljer att skapa den själva och då skall den se ut så här:
$ORIGIN .
$TTL 3600       ; 1 hour
87.46.215.in-addr.arpa IN SOA  ns1.bolaget.nu. admin.bolaget.nu. (
                      2003090801 ; serial
                      10800      ; refresh (3 hours)
                      3600       ; retry (1 hour)
                      604800     ; expire (1 week)
                      86400 )     ; minimum (1 day)
              NS      ns1.bolaget.nu.
              NS      ns1.granitecanyon.com.
$ORIGIN 87.46.215.in-addr.arpa.
15            PTR     ns1.bolaget.nu.
20            PTR     www.bolaget.nu.
22            PTR     mail.bolaget.nu.
Nu har vi talat om för Bind 9.2.2 att svara med samma namn vid namnuppslagning oavsett om det sker via forward eller reverse.
Så långt är allting frid och fröjd, men vi har en sak kvar och det är vår slave DNS­server som måste vara medveten om att den skall hantera en backup av våra forward och reverse zonfiler utifall vår egen master DNS­server skulle tas ur bruk eller helt enkelt bestämma sig för att lägga av nån dag.
I princip är det samma sak vid konfiguration av /etc/named.conf, men vi slipper skriva zonfilerna då dessa kommer att replikeras automatiskt när en uppdatering av zonfilerna på master DNS­servern är gjord.
För forward zonfil på slave DNS­server:
zone bolaget.nu IN {
        type slave;
        file var/named/bolaget.nu.hosts;
        masters { 215.46.87.15; };
};
För reverse zonfil på slave DNS­server:
zone 87.46.215.in-addr.arpa {
        type slave;
        file var/named/87.46.215.in-addr.arpa;
        masters { 215.46.87.15; };
};
Med lite tålamod skall nu våra zonfiler per automatik dyka upp i rätt kataloger på slave DNS­servern efter att Bind 9.2.2 har laddats om (zone reload).
Nu kommer vi till en lite mer sofistikerad del av DNS­hanteringen, nämligen delegering av subdomäner.
Man skulle ju kunna tänka sig att Bolaget AB köper upp eller skaffar sig avdelningar som skall lyda under moderorganisationen.
Vi kan arbeta med teorin at Bolaget AB skaffar sig en avdelning för utveckling av mjukvara för diskmaskiner.
Denna utvecklingsavdelning kommer att heta Bolaget Softwash AB och precis som moderbolaget vill man ansluta sig till Internet och ha sina egna servrar.
Nu är det så beskaffat att Softwash inte sitter på samma ort som moderbolaget, utan sitter i en helt annan del av landet med sin egen ISP.
Precis som moderbolaget sätter de upp sin DNS­server på liknande sätt, med undantaget för domännamnet och det faktum att de inte bryr sig om att använda en slave DNS server:
zone softwash.bolaget.nu {
        type master;
        file /var/named/softwash.bolaget.nu.hosts;
        };
Och zonfilen:
$ttl 3600       ; 1 hour
softwash.bolaget.nu.    IN      SOA     ns1.softwash.bolaget.nu. admin.softwash.bolaget.nu. (
                        2003090801
                        10800      ; refresh (3 hours)
                        3600       ; retry (1 hour)
                        604800     ; expire (1 week)
                        86400 )    ; minimum (1 day)
softwash.bolaget.nu.       IN   NS      ns1softwash..bolaget.nu.
ns1.softwash.bolaget.nu.   IN   A       194.235.87.9
www.softwash.bolaget.nu.   IN   A       194.235.87.10
mail.softwash.bolaget.nu.  IN   A       194.235.87.11
softwash.bolaget.nu.       IN   MX  10  mail.softwash.bolaget.nu.
När allt detta är gjort för Softwash måste moderbolaget göra sin del av arbetet, nämligen att delegera subdomänen till Softwash egen DNS­server.
Bolaget AB måste då uppdatera sin forward zonfil så att den kommer att se ut så här:
$ttl 3600       ; 1 hour
bolaget.nu.     IN   SOA   ns1.bolaget.nu. admin.bolaget.nu. (
                       2003090901
10800 ; refresh (3 hours) 3600 ; retry (1 hour) 604800 ; expire (1 week) 86400 ) ; minimum (1 day) bolaget.nu. IN NS ns1.bolaget.nu. bolaget.nu. IN NS ns1.granitecanyon.com. softwash.bolaget.nu. IN NS ns1.softwash.bolaget.nu. ns1.softwash.bolaget.nu IN A 194.235.87.9 ns1.bolaget.nu. IN A 215.46.87.15 www.bolaget.nu. IN A 215.46.87.20 mail.bolaget.nu. IN A 215.46.87.22 ftp.bolaget.nu. IN CNAME www.bolaget.nu. bolaget.nu. IN MX 10 mail.bolaget.nu.
Observera att serienumret är inkrementerat.
Nu har vi behandlat DNS­hantering i Linux och jag hoppas att detta mörka fenomen har klarnat något och att vi ser fler DNS­servrar dyka upp i framtiden.
Johan / [email protected]


Hemsidorna underhålls av Magnus Andersson