I denna artikeln ska jag gå igenom hur ni installerar en namnserver med BIND på FreeBSD. Alla exempel har testats på FreeBSD 4 och 5 men jag får inte betalt för detta så jag tror inte jag behöver påminna er om att allt ni gör sker på egen risk och att varken jag eller någon förknippad med Swehack kan hållas ansvarig för eventuella fel som kan hända. Nu fortsätter vi!
Förut har jag haft BIND igång på FreeBSD 4, jag minns tyvär inte vad det var för named version bara att det var en jävla gammal FreeBSD installation, typ 4.1 eller liknande. För er som är intresserade så har FreeBSD 4.1 named 8.2.3-REL. Alla exempel här har för det första kopierats från de gamla namnservrarna som använde FreeBSD 4 och för det andra testats på FreeBSD 5.1 och 5.2 med BIND 9.3.1. De används för tillfället på FreeBSD 5.4 med BIND 9.3.1. Detta ska inte spela någon större roll eftersom BIND eller named inte har ändrat mycket på ett bra tag förutom eventuella buggar.
I FreeBSD 4 system så var /etc/namedb en riktig katalog men i FreeBSD 5 system har dom ändrat sökvägen till /var/named/etc/namedb och gjort en länk från /etc/namedb till /var/named/etc/namedb. Detta har inte så stor betydelse eftersom vi senare i named.conf kan ange vilken sökväg som helst men vi håller oss till standarden så att folk inte blir förvirrade.
En annan sak jag minns är att i FreeBSD 4 angav du själv vad katalogen för dina SOA filer skulle heta men på FreeBSD 5 har dom skapat flera saker åt dig, bland annat en färdig och väldigt bra named.conf fil och en master katalog. Vi ska använda denna master katalogen för våra SOA filer. Notera att i BIND som skickades med FreeBSD före 5.x serien så fanns inte denna katalogen och man fick skapa den själv, precis som med mycket annat som jag faktiskt går igenom här.
Nu, innan jag fortsätter, så måste jag förklara lite om BIND och DNS så vi inte är helt lost när vi börjar konfigurera vår första namnserver. För det första så betyder DNS Domain Name System och inte Server som många tror. Jag kommer alltså använda uttrycket DNS ofta i artikeln eftersom det helt enkelt betyder "DomänNamns System". Katalogen jag pratade om tidigare, /var/named/etc/namedb, har precis allt som behövs för att konfigurera en fullt fungerande namnserver. Den enda filen jag kan tänka mig som ligger utanför är ju då den binära, exekverbara filen named som har legat i /usr/sbin ett bra tag.
Lite kort om DNS
Då ska vi gå igenom lite hur DNS trafik fungerar, jag kommer förklara detta i extremt enkla termer så att alla förstår och det är egentligen allt ni behöver veta för att ha er egen namnserver. När en klient vill slå upp en ip-adress så kollar den vilka namnservrar som är auktoritativa för det ip-nummret och gör en förfrågan till den första servern eller ibland en slumpmässig namnserver bland dessa auktoritativa namnservrar.
När den då frågar så har den bara en ip-adress, då kollar namnservern något som kallas för PTR eller "Pointer Record". Detta är en rad i en viss konfigurationsfil på namnservern som pekar de ip-adresser namnservern är auktoritativ för till sina respektive namn. I vissa fall så finns inget PTR för en ip-adress och detta är helt normalt eftersom det inte behövs utan endast används vid omvända DNS frågor.
Nu när klienten i fråga har frågat vår namnserver efter ett namn som ip-nummret pekar mot så kan vi säga att ip-adressen inte hade någon PTR och inget namn hittades, detta gör inget för då hittar klienten destinationsdatorn med hjälp av ip-adressen. Det jag precis beskrev händer inte så ofta eftersom program helst vill arbeta med ip-adresser men ibland måste ett program ha ett namn för ip-adressen och då kommer vi in på omvända DNS frågor eller som det heter på engelska, "Reverse DNS".
Då tänker vi oss en helt annan situation där en klient slår upp ett namn och vill ha namnets ip-adress, för utan en ip-adress kommer ingen eller inget någonstans på internet. Namnen är ENDAST till för att underlätta användningen av internet, detta måste ni förstå innan vi går vidare.
Situationen jag beskrev ovan kan relateras till IRC nätverk, en IRC server vill gärna slå upp ett namn som hör till ip-adressen klienten ansluter ifrån så att den kan visa detta namn när en klient använder IRC nätverket. Detta är hur folk kan använda roliga namn på IRC, dom förknippar först sitt namn med en ip-adress i något som kallas en SOA fil och sedan samma ip-adress med sitt namn i en PTR fil. När vi nu går igenom processen en IRC-server går igenom om en klient ansluter till den så för det första hittar IRC servern klientens ip-adress i de paket som skickas till servern.
Som sagt så är ip-adressen viktigast men IRC servern vill gärna göra ett försök till att få ett namn som tillhör ip-adressen så den gör en fråga till ip-adressens auktoritativa namnservrar och hittar att ip-adressen 654.405.3.215 pekar mot namnet dhcp1-654-405-3-215.hbg3.core.swehack.se vilket är ett vanligt format på så kallade DHCP adresser som internetleverantörer brukar dela ut till sina kunder. Observera att ip-adressen inte är riktig.
Jag hoppas verkligen ni förstår hur jag menar, jag är trots allt inte någon utbildad lärare så jag ska försöka visa processen en gång till med lite "textkonst".
Klient A ansluter till server B, server B tar då emot ip-adress C från klient A. Då tar server B och gör en fråga till namnserver D som är en auktoritativ namnserver för ip-adress C. Namnserver D letar i sina PTR filer efter ip-adress C och hittar den samt skickar ett svar till server B att ip-adress C för klient A pekar mot namn E. Hade då server B gjort en fråga till den auktoritativa namnservern för namn E så hade den fått reda på en ip-adress, denna ip-adress måste då peka mot namn E och då har vi gjort en omvänd DNS fråga för klient A och vet nu både dess ip-adress(C) och dess namn(E) så vi kan nu låta klienten(A) gå in på IRC nätverket och chatta med sitt namn(E) så att alla ser.
Hittar servern(B) inget namn i PTR hos namnservern(D) eller om namnet pekar mot en annan ip-adress så kommer servern(B) självklart fortsätta använda ip-adressen för att prata med klienten(A) men den kommer också inte att ha något namn(E) för klienten(A) så klienten kommer inte kunna visa upp något roligt namn när den chattar på IRC.
Ojoj, det var väldigt jobbigt men det är svårt att förklara något man lever och jobbar med varje dag, för mig är allt detta en självklarhet.
Konfiguration
Nu fortsätter vi med artikeln om BIND på FreeBSD. En namnserver som använder BIND har flera olika konfigurationsfiler men huvudfilen som styr allt är named.conf. I den står vilka kataloger som ska användas och var dom andra konfigurations filerna ska ligga. I named.conf måste vi också lägga till varje "zon" som namnservern ska använda. En zon är bland annat en domän så vi kommer prata om zoner när vi menar domännamn, varje zon eller domän kommer faktiskt få sin egen konfigurationsfil. Nu kommer jag visa er hur man lägger till PTR filer för ip-klasser, det är inte många som kan göra detta men för er som vill ha egna namnservrar med reverse dns så borde ni kontakta er leverantör av ip-adresser och rikta eventuella frågor dit för hur man routrar ip-adresser till ett nät är en helt annan artikel. Trots det tänker jag visa er hur en PTR fil ska se ut och då tänker jag basera mina exempel på de PTR filer jag har i mina namnservrar men byta ut alla ip-adresser mot interna ip-adresser.
Formatet på en zonfil används i flera andra konfigurationsfiler för named. Här får ni se en fullt fungerande named.conf och sen ska vi titta på de filer som defineras här i named.conf filen.
% more /etc/namedb/named.conf
options {
directory "/etc/namedb";
version "975.4.2";
pid-file "/var/run/named.pid";
dump-file "master/named_dump.db";
listen-on { 192.168.0.53; };
allow-transfer { 192.168.1.53; };
also-notify { 192.168.1.53; };
};
zone "." {
type hint;
file "named.root";
};
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "localhost.rev";
};
/* ########################################################################## */
zone "polisen.us" {
type master;
file "master/polisen.us";
};Som ni kan se rakt av så använder den C liknande kommentarer och vi börjar med options. Detta är vanliga konfigurationsalternativ för named. Först vilken katalog named ska arbeta i, det är denna katalogen som ska innehålla alla konfigurationsfiler för named. Sedan fortsätter vi med lite standardalternativ och på listen-on kan ni ange flera olika ip-adresser för att simulera två namnservrar. Det finns ett litet antal myndigheter som kräver mer än en namnserver, dom är inte många men de få som gör det kräver oftast inte mer än två.
Tänker ni simulera två olika namnservrar så krävs det oftast endast två externa ip-adresser som named lyssnar på men tänker ni faktiskt ha två olika fysiska namnservrar så ser ni att jag har lagt till två rader på slutet av options. Detta är för att den andra namnservern ska få veta när den första läser in sina SOA filer samt få överföra SOA filer från den första till sig själv. Det är endast de maskiners ip-adresser ni har i allow-transfer som får kopiera namnserverns filer till sig själv. En namnserver som är slav måste göra detta från en namnserver som är en "master".
Ni ser att jag lagt till en zon som heter ".", detta är en fil som innehåller alla root namnservrar på internet och den behövs för att er namnserver ska veta vart den ska slå upp namn. Sen har ni också en zon som heter "0.0.127.IN-ADDR.ARPA", detta är zonen för localhost. Som ni kanske minns så är localhost domänen för er lokala dator i UNIX. Detta är en reverse DNS zon alltså för omvänd DNS. Hittills har vi gått igenom saker som ni inte behöver röra för att ha en fungerande namnserver, named.root finns där som standard men inte localhost.rev så den ska ni få se här nedan men kom ihåg att den ska aldrig ändras utan är något som kan ligga statiskt på er namnserver.
% more /etc/namedb/localhost.rev
$TTL 259200
@ IN SOA ns1.swehack.se. dns.swehack.se. (
2000102702 ; serial
21600 ; refresh
3600 ; retry
1814400 ; expire
259200 ) ; default_ttl
@ IN NS ns1.swehack.se.
1 IN PTR localhost.Ni tittar nu på en sorts mall för alla era zonfiler. De zonfiler ni sedan kommer ha i master katalogen kommer ha lite mer information men det som jag brukar kalla "huvudet" på filen är likadant. Nu menar jag allt ner till raden "@ IN NS ns1.swehack.se.". Vi ska inte gå igenom denna filen eftersom den för det första är helt oviktig om ni bara vill ha en namnserver och för det andra är ofullständig. Vi ska istället gå igenom en zonfil för en av de domäner ni kan ha i er namnserver. I vårt exempel ska vi ta hand om domänen polisen.us så vi har pekat den från en ICANN registrar till ns1.swehack.se som är namnet på vår namnserver.
Som ni såg tidigare så har jag lagt till en zon i named.conf, den ser ut så här.
zone "polisen.us" {
type master;
file "master/polisen.us";
};Detta är en hel zon för BIND och säger till den vad zonen heter, var dess fil ligger och lite andra saker. Vi har inte mycket i vår zon men ni kan ha mycket mer, läs manualen för BIND. Detta är dock allt som behövs, raden "type master;" visar att detta är huvudfilen för zonen som ligger på huvudnamnservern. En så kallad "master". Det går även att göra så kallade slavar eller "slaves", dessa måste läggas till i allow-transfer och also-notify raderna i named.conf på huvudservern. En domän kan ha hur många namnservrar som helst, den kan till och med ha endast slavar men där det finns slavar måste det finnas en master.
Alltså skulle vi kunna peka polisen.us mot 5 slavar och ingen master men det finns ändå en master där någonstans som har domänen polisen.us i sig och låter slavarna kopiera den från sig. Vissa registrarer i världen är väldigt noga med sånt här och har vissa krav på er som DNS operatör, det är dock för mycket för mig att gå igenom här.
På raden "file "master/polisen.us";" anger vi var zonfilen för domänen polisen.us är, detta kan alltså vara precis var som helst men är relativt till directory raden under options i named.conf. Nu ska vi ta en titt i polisen.us filen. Vissa kanske inte vill döpa sina filer till domänens namn, det är helt ok, dom kan heta precis vad som helst så länge det som defineras i named.conf zonerna är det riktiga. Här nedan ser ni filen polisen.us som ligger i master katalogen.
% more /etc/namedb/master/polisen.us
$TTL 86400
@ IN SOA ns1.swehack.se. dns.swehack.se. (
2002121822 ; serial
43200 ; refresh
21600 ; retry
604800 ; expire
86400 ) ; default_ttl
; Mailserver.
@ IN MX 5 mail.swehack.se.
@ IN MX 10 mail1.swehack.se.
mail IN A 192.168.0.25
localhost IN A 127.0.0.1
; DNS servrar.
@ IN NS ns1.swehack.se.
; IP utan www.
@ IN A 192.168.0.80
; Resten av domänen.
www IN A 192.168.0.80
ftp IN A 192.168.0.80
jag.hatar IN A 192.168.0.111De flesta av er vill nog veta vad alla siffror längst upp i filen betyder, det vill jag berätta men jag sparar det till sist så ska vi gå igenom hela toppen av en zonfil. Ni kan också se att i zonfilerna så använder vi ; för att göra en rad till en kommentar. Innan vi fortsätter ska ni veta att som de flesta andra konfigurationsfiler läser vi denna från vänster till höger, ser ni ett @ tecken så betyder det att raden eller regeln, som vissa tycker om att kalla det, gäller för hela domänen och inte någon speciell subdomän.
Står det något annat till vänster så gäller den regeln för den subdomänen, så allt som står längst till vänster förutom @ tecken betyder att ni precis har skapat en subdomän till er domän. Så enkelt var det. Som ni kan se så är www en subdomän, detta är ett misstag som jag sett erfarna IT-tekniker göra i flera år. Fakta är att en domän endast är polisen.us, inget annat, om vi tar isär domänen polisen.us så har vi något som kallas en toppdomän eller ccTLD, det är "us" i detta fallet. Ett exempel på en rad som definerar www subdomänen i en zonfil för BIND skulle se ut så här.
www IN A 192.168.0.80
Vi börjar med namnet på själva subdomänen, sen har vi ett A som anger att detta är för IPv4 istället för IPv6 som använder AAAA. Till sist ser ni destinationen för regeln som är en ip-adress. Jag rekommenderar att använda ip-adresser men det finns de som har behov för att använda ett namn och då ser det ut så här.
www IN CNAME namn.doman.tld.
Lägg märke till punkten på slutet, alltid när ett namn används i zonfiler så ska det följas av en punkt för att avsluta raden.
Går vi nu tillbaka till vår zonfil så var vi vid MX pekarna, här ser ni att vi har två MX pekare som pekar till två olika servrar. Detta är endast för inkommande e-post, alltså SMTP(in) som vissa säger.
@ IN MX 5 mail.swehack.se. @ IN MX 10 mail1.swehack.se.
Siffran ni ser efter MX är vilken plats den raden har i ordningen av alla MX regler, anger ni att mail.swehack.se har 5 så kommer den väljas före mail1.swehack.se som har 10. På detta viset kan man ha en sorts backup av servrar som hanterar e-posten för om en inte fungerar så väljs den andra. Det är absolut inget måste att ha mer än en utan endast ett exempel, ni kan också ha vilka siffror som helst för att bestämma ordningen och om ni har flera med samma tal så kommer en av dom väljas slumpmässigt.
Fortsätter vi neråt har vi en vanlig subdomänsrad som definerar en subdomän som heter mail.polisen.us och pekar mot en server, denna servern måste ju då ta emot mail.polisen.us på rätt sätt, eller inte. Under den raden har vi en standard rad som talar om var localhost är, denna är ett krav för en fungerande BIND. Längre ner har vi en rad som definerar vilka namnservrar domänen ligger i, det är inget måste att ha alla namnservrar som är slavar och har kopierat domänen men ni bör ha master servern här.
Nästa rad är något som ni borde förstå vid det här laget om ni läst det jag skrivit ovan. Ett @ tecken betyder som sagt att denna regeln gäller för hela domänen och den pekar mot en ip-adress så om man skriver in polisen.us kommer man till den ip-adressen som sedan tar över pekningen.
Vid det här laget borde ni förstå hur man gör egna subdomäner som pekar till olika ip-adresser, om inte så ska jag gå igenom sista raden i polisen.us filen ändå.
jag.hatar IN A 192.168.0.111
Här har vi regeln för domänen jag.hatar.polisen.us som pekar mot ip-adressen 192.168.0.111. Så enkelt var det och ni kan göra hur långa subdomäner som helst. Så länge ni kommer ihåg några små saker, domänen har ni redan definerat i named.conf tillsammans med dess fil, i själva filen anger ni faktiskt allt UTOM själva domänen.
Därför blir reglerna som dom blir, man skriver endast vad som ska komma före domänen. Ni kan också använda ett UNIX wildcard tecken i zonfilerna för att göra så kallade wildcard domäner. Det betyder att den tar precis-vad-som-helst.polisen.us och ett exempel har ni nedan.
* IN A 192.168.0.111
Med denna regeln så kan folk komma till 192.168.0.111 oavsett vad dom skriver framför polisen.us. Ni måste självklart hålla ordning på var ni lägger en wildcard regel och tänka på att man läser en zonfil uppifrån och ner, från vänster till höger.
En sak jag måste notera är att min struktur på mina zonfiler inte behöver vara som er, jag har lärt mig det mesta som jag kan av en person som kallar sig DmenC och detta är den struktur han använder på sina zonfiler. En sak som folk föredrar att använda en viss struktur för är toppen av zonfilerna, nu ska vi gå igenom alla de där konstiga siffrorna vi hoppade över förut. Här nedan har vi ett exempel.
$TTL 86400
@ IN SOA ns1.swehack.se. dns.swehack.se. (
2002121822 ; serial
3600 ; refresh
900 ; retry
172800 ; expire
86400 ) ; default_ttlVi börjar med att förklara något som kallas TTL eller "Time To Live". Detta är ett numeriskt värde som förut alltid var i skunder men på senare tid har fått stöd för andra format som timmar, dagar osv. Vi ska dock ange det i sekunder för det är så jag lärt mig. Först lite fakta, en timme är 3600 sekunder, ett dygn(24 timmar) är 86400 sekunder och två dygn(48 timmar) är 172800 sekunder. Ni behöver inte vara exakta här men jag har en vana att räkna ut exakta tider på dygn. Vid speciella tillfällen brukar man använda mindre värden som en minut eller liknande men det får ni lista ut själva när det behövs. När vi nu fortsätter med en förklaring av TTL så måste ni förstå lite om exakt vad namnservrar gör.
Vi tar ett exempel, en namnserver hos Telia noterar var den kan hitta polisen.us om någon av telias kunder känner för att kontakta den domänen. Den noterar då en TTL för att veta när den ska uppdatera sin information. Ibland när vi gör olika tester eller experiment så brukar vi sätta TTL till ett lågt värde så att det snabbt uppdateras och vi snabbt kan se resultat hos klienter. Det värde som $TTL har i toppen av en zonfil måste stämma överens med värdet ni ser längre ner vid kommentaren default_ttl.
På nästa rad har vi lite information för andra namnservrar, det säger att ns1.swehack.se är auktoritativ för zonen. Som vanligt avslutas hostnamn med en punkt och på just denna raden föredrar jag att ni också har ett mellanrum efter punkten för annars kan det bli problem för BIND att veta var namnet slutar. På samma rad har ni också något som ser ut som ett hostnamn men i själva verket är en e-post adress. Jag vet faktiskt inte om detta är ett måste när man jobbar med BIND men om det är något som måste finnas där så hade jag använt en väldigt enkelt e-post adress om jag var ni.
Eftersom en punkt i detta fallet ersätter ett @ tecken så kan det bli otroligt svårt för andra program att läsa en e-post adress om den har flera punkter i sig innan den verkliga platsen för @ tecknet. Vad jag vet finns det ingen praktisk användning av e-post adressen utan den läser olika registrarer så att dom ska veta hur dom ska kontakta dig, det kan även vara så att andra försöker läsa den med automatiska program och då är det bra att ha en enkel adress. I detta fallet betyder dns.swehack.se e-post adressen dns@swehack.se.
Nu ska vi gå igenom alla de konstiga siffrorna på de följande raderna. Först har vi något som vi kallar serial eller serienummer, detta är en rad med siffror vars värde måste öka varje gång ni har ändrat något i zonfilen och ska uppdatera namnservern. Ni gör endast ändringar i master servern och det är endast där värdet ska öka. Det kvittar egentligen hur mycket värdet ökar med så länge det blir större än värdet som BIND på master och alla andra slave servrar har i minne. Ett serienummer i BIND måste följa vissa begränsnigar, det är en 32 bitars osignerad integer med ett maximalt värde av 4 294 967 295. När en slave server ser att serienummret för en zonfil på master servern har ändrats så hämtar den hela zonfilen och uppdaterar sin egen information nästa gång den uppdateras.
På tal om uppdatering av namnservern så ska vi göra en liten avstickare för att förklara vad det betyder. När ni först startar named med /usr/sbin/named -c /etc/namedb/named.conf så läser den in alla zonfiler i minnet så om ni ändrar en zonfil så kommer denna ändringen inte uppfattas av named förrän ni startar om named processen och den läser in alla zonfiler i minnet. Ni kan döda named och starta den igen eller så kan ni skicka HUP signalen till den så den startar om så snabbt som möjligt och inte tappar några DNS frågor. Då skriver ni bara killall -HUP named för att döda named processen så den startar om.
Värdet som kallas refresh är hur ofta slave servern ska komma tillbaka till master servern och kolla efter en uppdaterad databas. Retry värdet är tiden som slave servern ska vänta innan den försöker kontakta igen om master servern inte svarade första gången. Värdet för expire är hur länge en slave server fortsätter att svara på klientfrågor efter att master servern slutat svara, när en master server slutar svara så går frågorna naturligt över till en slave server och eftersom master har denna tiden i sin zonfil så vet slave servrarna hur länge dom ska fortsätta svara på frågor om domänen innan dom också slutar svara för just den zonfilen. Då är oftast zonfilen borttagen från master.
Nu kan ni testa er namnserver genom att skriva dig @ns1.swehack.se polisen.us från något UNIX baserat system med dig kommandot. Ni kan faktiskt skriva exakt det jag precis sa för medan jag skrev denna artikeln så har jag även satt upp en namnserver enligt mina egna exempel på ns1.swehack.se med polisen.us domänen. Resultatet borde bli något som följande.
% dig @ns1.swehack.se polisen.us ; <<>> DiG 9.3.0 <<>> @ns1.swehack.se polisen.us ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25431 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;polisen.us. IN A ;; ANSWER SECTION: polisen.us. 86400 IN A 82.99.44.9 ;; AUTHORITY SECTION: polisen.us. 86400 IN NS ns1.swehack.se. ;; Query time: 365 msec ;; SERVER: 82.99.47.153#53(ns1.swehack.se) ;; WHEN: Sat Aug 6 21:54:53 2005 ;; MSG SIZE rcvd: 72
Det är nog allt ni behöver veta just nu, jag kommer antagligen uppdatera denna artikeln. Skicka gärna in synpunkter till nocturnal [AT] swehack.se eller skriv dom på forumet.