Introduktion till DNS och programmet bind

DNS står för Domain Name System och är det system som hanterar domännamn och datornamn på Internet (och lokala nätverk). DNS används framförallt till för översättning mellan datornamn och IP-adresser. Utan DNS måste man hålla reda på IP-adresserna för de datorer som man vill kunna nå. DNS är ett globalt system för att ge vettiga namn på datorer (och annan nätverksutrustning) på Internet som är lättare att komma ihåg än IP-adresser.

DNS kan ses som en stor global distribuerad databas där många organisationer hanterar och sköter om sin domän eller sina domäner. DNS är ett hierarkiskt system organiserat som ett träd (upp och nervänt träd) med roten högst upp och toppdomänerna direkt under. Rot-domänen skrivs med en punkt.

DNS skiljer inte på stora och små bokstäver. Domänamn skrivs med namnen från den lägsta nivån upp till rotdomänen med en punkt mellan delarna. Exempel: teknik.bolaget.se. eller ekonomi.bolaget.se. eller bigcompany.com. Rotdomänen kan man dock utelämna i många sammanhang och då blir det teknik.bolaget.se utan en avslutande punkt. De tecken som är tillåtna i namn är bokstäverna a till z, siffrorna 0 till 9 och bindestreck - där bindestreck dock måste ha bokstäver och eller siffror före och efter. Ett standardiseringsarbete finns för lokala tecken som bland annat å, ä och ö i domännamn. Ett DNS-namn kan vara namnet på en domän eller namnet på en dator (eller annan nätverksutrustning). Ett DNS-namn kan också vara både en domän och namnet på en dator på samma gång. Detta fungerar eftersom det egentligen inte är någon skillnad mellan namn på en domän och namn på en dator.

Hierarki och delegering

DNS är hierarkiskt ordnat från rot-domänen och nedåt. Högst upp finns en organisation som ansvarar för hela DNS-trädet, rot-zonen och nedåt. Denna organisation vill inte behöva hantera alla data för alla toppdomänerna utan lämnar över ansvaret, delegerar, till andra organisationer som får ta hand om en eller flera toppdomäner (se, com, org, net, nu, no, fi etc.). När en organisation registrerar ett domännamn under en toppdomän brukar organisationen få ansvaret för sin domän, zon, delegerad till sig. Nedan har Bigcompany fått delegerat till sig att ansvara över bigcompany.com och Bolaget har fått delegerat bolaget.se till sig. Bolaget har sedan delegerat vidare teknik.bolaget.se till teknikavdelningen på företaget så att teknikavdelningen kan hantera alla namn under teknik.bolaget.se. Varje ansvarsområde som är delegerat till någon kallas för en zon. Det är samma sak som att den den del som en namnserver är auktorativ för utgör en zon, d.v.s att den är ansvarig för den delen av DNS. Se bild nedan. teknik.bolaget.se är en egen zon men ligger inom domänen bolaget.se på samma sätt som ekonomi.bolaget.se också ingår i domänen bolaget.se.

Historik

I Internets barndom bestod nätet av ett fåtal datorer och på den tiden hade man en fil i varje dator som innehöll alla datorers namn och deras IP-adresser. Alla fick regelbundet kopiera filen till sina datorer. /etc/hosts är en kvarleva sedan den tiden. När Internet växte blev detta system otympligt och DNS skapades 1983 och uppdaterades senare 1987. Specifikationerna för DNS finns i RFC1034 och RFC1035.

Namnservrar

En namnserver som är huvudansvarig för en zon kallas för master eller masterserver för denna zon. Det är i masterservern som nya uppgifter läggs in och det är där ändringar görs för zonen. Om masterserver går ner och blir onåbar går det inte längre att komma åt och slå upp uppgifterna för den aktuella zonen. Därför finns slavservrar som kopierar alla data från masterservern. Masterservrar och slavservrar är auktorativa för zonen. Det bör alltid finnas minst två auktorativa servrar för varje zon. En auktorativ server måste inte själv finnas i den zon som den är auktorativ för.

En DNS-server kan vara master för en zon och på samma gång slav för en annan zon.

Äldre beteckning på en masterserver är primärserver och för slavserver sekundärserver.

Namnuppslagning

Om man sitter ute i världen någonstans och ska slå upp vad www.bolaget.se har för IP-adress för att kunna gå dit fungerar det på följande sätt.

Den egna datorn, arbetsstationen, frågar den lokala namnservern efter vad www.bolaget.se har för IP-adress.
Denna namnserver känner inte till detta utan den frågar i sin tur en rot-server.
Rot-servern vet inte svaret på frågan men den kan svara med det den känner till nämligen vilka namnservrar som ansvarar för toppdomänen se.
Nu går vår lokala namnserver till en av de auktorativa namnservrarna för se och frågar den om www.bolaget.se.
Namnservern för toppdomänen se känner inte till det men den vet vilka namnservrar som ansvarar för bolaget.se.
Vår lokala namnserver går nu till en av de auktorativa namnservrarna för bolaget.se och frågar den om IP-adressen för www.bolaget.se och får slutligen ett svar.
Vår lokala namnserver sparar svaret i sin cache och ger ett svar till arbetsstationen. Den tid som den lokala namnservern sparar svaret innan den kastar bort det kallas Time To Live, TTL. TTL-värdet anges av den auktorativa namnservern som gav det slutgiltiga svaret.

De svarta pilarna representerar frågor och de grå representerar svar. Den del i den egna arbetstationen som sköter om att slå upp saker i DNS kallas resolver. Konfiguration av resolvern i ett linuxsystem görs i filen /etc/resolv.conf .

En namnserver som tar emot en fråga och som sedan själv frågar vidare, som den lokala namnservern ovan, är en rekursiv namnserver. En namnserver som svarar med ett så bra svar den kan ge utan att själv fråga vidare är en iterativ namnserver. Rot-namnservrarna och toppdomänservrarna är alla normalt iterativa namnservrar. De har tillräckligt mycket att göra ändå med att bara ge svar på frågor. Rekursiva namnservar brukar spara alla svar i en minnescache. På så sätt kan den ge svar direkt utan att behöva gå ut på Internet och ta reda på svaren om någon frågar efter sådant som den har sparat i sin cache. Det gör att antalet DNS-frågor på Internet minskar.

Överföring av all information om en hel zon kallas zonöverföring.

Resolvern

Den del i den egna datorn som sköter om att fråga en namnserver efter DNS-uppgifter kallas resolver. Resolvern konfigureras i filen /etc/resolv.conf . I den anges de namnservrar som ska användas för att slå upp saker i DNS. Upp till tre rader med namnservrar kan förekomma i /etc/resolv.conf . Exempel:

nameserver 1.2.3.4 
nameserver 10.11.12.13 
nameserver 172.22.1.17

Förutom att ange namnservrar kan det vara praktiskt att slippa behöva skriva domännamn vid uppslagning av namn inom den egna domänen. För detta finns direktivet search. Den eller de domännamn som står efter search används när namnuppslagningar görs på ett namn som inte är ett fullständigt domännamn, d.v.s. utan punkter. Om t.ex. domänernerna teknik.bolaget.se och bolaget.se står efter ett searchdirektiv och en uppslagning görs på namnet dumburk då börjar resolvern med att fråga efter dumburk.teknik.bolaget.se och om denna finns får resolvern ett svar och den stannar där. Om dumburk.teknik.bolaget.se inte finns fortsätter resolvern med dumburk.bolaget.se . Vid uppslagning av namn med punkter börjar resolvern med att slå upp hela det angivna namnet. Finns inte det fortsätter den med att lägga till teknik.bolaget.se på slutet av det som ska slås upp och finns inte den fortsätter den med att istället lägga till bolaget.se i slutet av namnet som ska slås upp.

search teknik.bolaget.se bolaget.se
nameserver 1.2.3.4 
nameserver 10.11.12.13 
nameserver 172.22.1.17

Olika typer av poster i DNS

Några av de typer av poster som finns i DNS som man kan och i flera fall bör ha med i sin namnserver är:

SOA, Start Of Authority, innehåller namn på en auktorativ namnserver för den aktuella zonen, e-postadress till en ansvarig person för zonen (med @ utbytt mot en punkt), standardvärden för hur ofta slavservrar ska fråga mastern om det finns några ändringar, hur länge slavservrarna ska spara data de får från mastern, standardvärde för TTL m.m. För detaljer se avsnittet zonfiler.
NS, anger en namnserver som är auktorativ (master eller slav) för zonen.
MX, anger en e-postserver som är den e-postserver som ska användas för att skicka e-post till användare som finns på denna domän.
A, uppslagning från domännamn till IP-adress.
PTR, uppslagning från IP-adress till domännamn.
TXT, ett textfält för allmän textinformation.
HINFO, information om hårdvutyp och operativsystem i en dator. Exempel: PC linux
CNAME (Canonical name), aliasnamn. Dessa bör användas sparsamt då de ofta leder till problem.

Namnserverprogramvara

Till Linux finns det flera programvaror för att skapa sig en namnserver men den vanligaste är bind. Programmet bind följer med i de flesta linuxdistributioner. Om bind inte följer med i din favoritdistribution så finns den att ladda ner från https://www.isc.org/bind/

Alternativ till bind är djbdns, http://cr.yp.to/djbdns.html , NSD, http://www.nlnetlabs.nl/nsd/ och bundy.

Beskrivningarna nedan går igenom hur inställningar görs i bind.

Huvudkonfigurationen för bind

Från och med bind version 8 används filen named.conf som vanligtvis ligger i katalogen /etc .

Kommentarer i huvudkonfigurationsfilen skrivs med # eller // där resten av raden tolkas som en kommentar. Kommentarer kan även skrivas som /* kommentar */ där kommentaren kan gå över flera rader.

Konfigurationen består av ett antal block som inleds med ett nyckelord som talar om vad det är för typ av block. Nyckelorden kan vara acl, options, controls, zone, key, server, trusted-keys, logging, lwres eller view. Ett block skrivs som:

nyckelord argument { };

Det får endast finnas ett options-block. I ett block ingår ett eller flera direktiv. Alla block och alla direktiv måste avslutas med semikolon.

nyckelord argument { direktiv; direktiv; };

I huvudkonfigurationen anges vilka zoner som servern är master respektive slav för och det går att styra vilka som får använda namnservern, etc.

Ett litet exempel på en konfigurationsfil.

// En enkel konfiguration options { listen-on port 53 { any; }; listen-on-v6 port 53 { ::1; }; directory "/var/named"; }; zone "." IN { type hint; file "named.ca"; };

I options anges standardoptioner som t.ex. vilken port bind ska lyssna på och på vilka nätverksinterface den ska lyssna, var zonfilerna finns. Ovan anges att den för IP v4 ska lyssna på port 53 på alla nätverksinterface, för IP v6 endast på port 53 på loopackinterfacet, och directory anger att zonfilerna ligger i katalogen /var/named.

Inställningarna för en zon ges i ett block som inleds med zone. För att hitta rot-servrarna lägger man in ett zon-block för "." där informationen för den aktuella zonen laddas från filen named.ca (d.v.s. /var/named/named.ca). Typen hint anger att det som står i den filen är en hint, tips, om var rot-namnservrarna finns.

Type anger hur bind ska hantera den aktuella zonen. De alternativ som finns är: hint, master och slave.

Om servern ska sättas upp att vara master för zonen bolaget.se behövs ett zon-block för bolaget.se. Denna kan se ut enligt följande.

zone "bolaget.se" { type master; file "bolaget.zone"; };

Notera att zon-namnet ska stå inom citattecken, ", och att alla rader inom blocket och blocket självt ska avslutas med semikolon.

För bakåtuppslagning finns en en domän in-addr.arpa. under vilka alla IP-adresserna ska stoppas in. IP-adresser skrivs normalt från vänster till höger och delegeras från vänster till höger. Någon kan t.ex. ansvara för 192 och delegera vidare 192.168. DNS-namn skrivs istället med delegeringsordningen från höger till vänster. Exempel: teknik.bolaget.se. Detta ger att IP-adressen 192.168.22.2 skrivs 2.22.168.192.in-addr.arpa. i DNS.

För att i DNS kunna hantera bakåtuppslagning för IP-adresser till namn behövs en zon i serverkonfigurationen. Om servern är master för denna blir det.

zone "22.168.192.in-addr.arpa" { type master; file "22.168.192.rev"; };

Delegering av bakåtuppslagning kan endast ske där punkter skrivs i IP-adressen, d.v.s på jämna oktetter. T.ex. 192, 192.168 eller 192.168.22. Dock finns det ett par fula metoder för att gå runt den begränsningen. Se nedan för mer detaljer.

Företaget bolaget.se är vän med företaget annatbolag.se och bestämmer sig för att agera slavserver åt zonen annatbolag.se.

zone "annatbolag.se" { type slave; masters { 192.168.22.17; }; file "slave/annatbolag.zone"; };

Type slave talar om att servern är slav för denna zon. Masters anger vilka servrar som denna server ska hämta sin information från. Det kan vara en masterserver och eller slavservrar. IP-adresserna skrivs inom { } och varje IP-adress avslutas med semikolon ; . En eller flera IP-adresser kan användas. Kom ihåg att avsluta alla block och direktiv med semikolon. File anger ett filnamn där hämtade data ska sparas. I detta fall sparas data i filen annatbolag.zone i underkatalogen slave, d.v.s. /var/named/slave/annatbolag.se . Filen skapas om den inte existerar. Katalogen /var/named/slave måste finnas.

I filen finns ofta en inkludering av en nyckelfil som används för autentifiering av kommandon till servern om konfigurationsfilen till rndc /etc/rndc.conf inte finns. include "/etc/rndc.key";

Om man själv editerar named.conf rekommenderas att den kontrolleras med named-checkconf. Se avsnittet felsökning.

Ett exempel på en named.conf

// En named.conf options { directory "/var/named"; }; zone "." IN { type hint; file "named.ca"; }; zone "bolaget.se" { type master; file "bolaget.zone"; }; zone "annatbolag.se" { type slave; masters { 192.168.22.17; }; file "slave/annatbolag.zone"; }; zone "22.168.192.in-addr.arpa" { type master; file "22.168.192.rev"; };

Starta och starta om bind

Med kommandot rndc kan bind stoppas, fås att på nytt ladda in konfiguration och zonfiler, slå på och av extra spårutskrifter/debugutskrifter etc..

Namnservern bind startas normalt från ett startscript som finns i de flesta linuxdistributioner. Processen och programmet heter named. Det går även att starta bind genom att köra igång programmet named. För att stoppa bind går det att använda rndc.

rndc start: Startar servern.
rndc stop: Sparar pågående uppdateringar och stoppar servern.
rndc halt: Stoppar servern.
rndc status: Visar om servern kör eller ej och om servern kör ger den information om antal zoner etc.
rndc reload: Laddar in konfigurationen och alla zoner på nytt utan att stoppa processen.
rndc reconfig: Laddar in konfigurationen och alla nya zoner. Gamla zoner läses inte in på nytt.
rndc trace: Ökar debugnivå på processen vilket ger mer debugutskrifter.
rndc notrace: Sätter debugnivån till 0 vilket avslutar alla debugutskrifter.
rndc flush: Gör så att servern kastar alla data som den har sparat i sin cache.

All loggning som bind gör sker via syslog. Vanligt är att loggning sker till filen /var/log/named.

Zonfiler

En zonfil är en datafil där alla data om en zon finns lagrade. Zonfiler är rena textfiler med poster som SOA och t.ex. A och NS etc. Kommentarer i zonfilen skrivs med semikolon ; där resten av raden är en kommentar. Alla tidsangivelser är i sekunder. Det går dock att tala om enhet genom att skriva M, H, D eller W efter tidsangivelsen. 15M innebär 15 minuter, 3H innebär 3 timmar, 1D innebär 1 dygn och 1W är en vecka.

TTL

Lämpligt är att börja med zon-fil med att ange standardvärdet för TTL, Time To Live, d.v.s. värdet för hur länge andra namnservrar ska få spara data från denna domän i sin cache. TTL är ingen post. TTL anges med:

$ttl 38400

Poster

En post i en zonfil består av:
namn ttl klass rr parameter
där namn är ett DNS-namn, ttl är ett TTL-värde, klass är typ av protokoll som den gäller för där standard är IN, Internet Protocol, rr anger vad det är för typ av post (SOA, NS, A etc.) och parameter är parameter eller värde för denna post. TTL och klass kan utelämnas.

SOA

I alla zonfiler ska det finnas en SOA-post som första post som talar om vilken dator som är masterserver för zonen och som ger en e-postadress till en ansvarig, där @ i e-postadressen är utbytt mot en punkt. Vidare innehåller SOA-posten ett serienummer för denna zon. Serienumret ska man alltid ändra, öka på värdet, varje gång man ändrar i zon-filen. Lämpligt är att låta serienumret vara datum för när zonfilen ändras plus två extra siffror som räknas upp från 00 till 99 om det behövs. Det ger att man kan uppdatera en zonfil 100 gånger under ett dygn med den formen på serienummer. Refresh-värdet anger hur ofta slavservrar ska fråga mastern om det finns några nya data. Detta gör de genom att hämta serienumret och se om det har ökats på eller ej. Om både denna och den andra servern kör bind 8 eller senare skickas en NOTIFY och detta fält används då inte.

Retry används om mastern har varit otillgänglig där retry-värdet talar om hur ofta slavservrarna ska försöka kontakta masterservern igen och igen och igen för att se om den åter är nåbar. Expire anger när slavservrarna ska kasta alla data för zonen när de inte längre får kontakt med masterservern. Det sista värdet slutligen anger hur länge cachning av negativa svar ska sparas, d.v.s om någon DNS frågar efter en post som inte finns så kan den DNS-servern komma ihåg att det inte fanns något svar på den frågan ifrån den här servern. Värdet anger hur länge den ska komma ihåg. En SOA-post kan se ut enligt nedan.

bolaget.se. IN SOA ns.bolaget.se. root.bolaget.se. ( 2005010400 ;serial 10800 ;Refresh 3600 ;Retry 604800 ;Expire 38400 ); Negative cache

En post sträcker sig över en rad men för att SOA-posten ska vara mer lättläst vill man ha den över flera rader med kommentarer och då skrivs den del som sträcker sig över flera rader inom parenteser (). Notera punkten i slutet av alla domännamn. Om denna punkt utelämnas kommer bind att lägga på det zonnamn som står i named.conf så i detta fall skulle det bli t.ex. ns.bolaget.se.bolaget.se. istället för ns.bolaget.se . Detta gäller i alla delar av alla zonfiler. För zonfilen läggs det aktuella zonnamnet till på slutet om ett domännamn inte slutar med en punkt.

IN kan utelämnas då Internet Protocol är standardvärde.

NS

Efter SOA är det brukligt att lägga in en eller flera NS-poster. NS-posterna nedan talar om att datorn ns.bolaget.se och datorn ns.annatbolag.se är auktorativa för bolaget.se. Det namn som NS pekar på måste ha en A-post med en IP-adress antingen i denna zon eller i en annan zon som ligger på denna namnserver eller någon annan namnserver ute i världen.

bolaget.se. NS ns.bolaget.se. bolaget.se. NS ns.annatbolag.se.

A

A-poster är de som står för uppslagningen från namn till IP-adress.

ns.bolaget.se. IN A 192.168.22.5 www.bolaget.se. IN A 192.168.22.7

IN kan utelämnas och då blir det istället:

ns.bolaget.se. A 192.168.22.5 www.bolaget.se. A 192.168.22.7

Det går även utmärkt att ge en domän en IP-adress t.ex. bolaget.se. Den kan exempelvis sättas att peka på webbserverns IP-adress.

bolaget.se. A 192.168.22.7

Flera namn kan peka på samma IP-adress.

www.bolaget.se. A 192.168.22.7 mail1.bolaget.se. A 192.168.22.7

För att sätta ett specifikt ttl-värde för en post kan värdet skrivas in i posten. Detta gäller alla typer av poster. Exempel på en A-post med TTL satt till 10 sekunder.

www.bolaget.se. 10 A 192.168.22.7

Att ha kort TTL på A-poster där flera A-poster med samma namn pekar på olika IP-adress kallas round-robin och är en halvhyfsad lastbalansering. För organisationer med mycket trafik till sina servrar är det dock bättre att använda någon form av hårdvarulastbalansering. Nedan har www.bolaget.se. 4 IP-adresser och en TTL på 2 sekunder för dessa.

www.bolaget.se. 2 A 192.168.22.7 www.bolaget.se. 2 A 192.168.22.10 www.bolaget.se. 2 A 192.168.22.11 www.bolaget.se. 2 A 192.168.22.12

MX

MX talar om var e-postservrarna för den aktuella domänen finns. Det går utmärkt att ha flera MX-poster. Efter MX ska ett tal ges, prioritet, och den MX-post med lägst tal är den som omvärlden kommer att använda i första hand och om den är onåbar försöker de med nästa.

bolaget.se. MX 10 mail1.bolaget.se. bolaget.se. MX 20 mail2.bolaget.se. bolaget.se. MX 30 mail3.bolaget.se.

Här kommer omvärlden att i första hand försöka kontakta mail1.bolaget.se. , i andra hand mail2.bolaget.se. och i sista hand mail3.bolaget.se.

CNAME

CNAME bör man oftas undvika att använda. Det är i de flesta fall bättre att låta flera namn peka på samma IP-adress med A-poster. Annars är formen aliasnamn CNAME annatnamn. Ett alias måste peka på en A-post. Det är inte tillåtet att ha t.ex. MX-poster till CNAME.

ftp.bolaget.se. CNAME www.bolaget.se.

AAAA

AAAA-poster fungerar på samma sätt som A-poster men för IPv6-adresser.

mail1.bolaget.se. AAAA FDEC:BA98::74:3210:1234

Ett exempel på en zonfil för bolaget.se.

$ttl 38400 bolaget.se. IN SOA ns.bolaget.se. root.bolaget.se. ( 1104409727 ;serial 10800 ;Refresh 3600 ;Retry 604800 ;Expire 38400 ); Negative cache bolaget.se. NS ns.bolaget.se. bolaget.se. NS ns.annatbolag.se. bolaget.se. MX 10 mail1.bolaget.se. bolaget.se. MX 20 mail2.bolaget.se. bolaget.se. MX 30 mail3.bolaget.se. gw1.bolaget.se. A 192.168.22.1 ns.bolaget.se. A 192.168.22.5 www.bolaget.se. A 192.168.22.7 mail1.bolaget.se. A 192.168.22.7 mail2.bolaget.se. A 192.168.22.5 mail3.bolaget.se. A 192.168.22.17

PTR

PTR används för uppslagning från IP-adress till DNS-namn. Eftersom PTR-poster ligger i en annan zon än framåtuppslagningen brukar dessa ligga i en egen fil.

5.22.168.192.in-addr.arpa. PTR ns.bolaget.se.

Observera att det är viktigt med den avslutande punkten på DNS-namnet.

Förenklingar

Som tidigare nämnts om ett namn inte avslutas med en punkt lägger bind till zonnamnet på slutet. Detta går att utnyttja för att förkorta namnen i zonfilerna. Likaså kan DNS-namnet utelämnas i början på en rad då är det namnet från föregående rad som gäller även för denna rad. Detta går att göra över många rader. Istället för att skriva zonnamnet går det att använda @.

$ttl 38400 @ IN SOA ns.bolaget.se. root.bolaget.se. ( 1104409727 ;serial 10800 ;Refresh 3600 ;Retry 604800 ;Expire 38400 ); Negative cache NS ns NS ns.annatbolag.se. MX 10 mail1 MX 20 mail2 MX 30 mail3 gw1 A 192.168.22.1 ns A 192.168.22.5 www A 192.168.22.7 mail1 A 192.168.22.7 mail2 A 192.168.22.5 mail3 A 192.168.22.17

Exempel på bakåtuppslagning

Exempel på bakåtuppslagning för 192.168.22. Zonen blir då 22.168.192.in-addr.arpa. Även här kan man använda förkortningar enligt beskrivningen ovan.

$ttl 38400
@ SOA ns.bolaget.se. root.bolaget.se. (
         1104409727 ;serial
         10800 ;Refresh
         3600 ;Retry
         604800 ;Expire
         38400 ); Negative cache

       NS  ns.bolaget.se.
       NS  ns.annatbolag.se.

1   PTR gw1.bolaget.se.
5   PTR ns.bolaget.se.
7   PTR www.bolaget.se.
17   PTR mail3.bolaget.se.

Här är det viktigt att DNS-namnen avslutas med en punkt eftersom namnen annars kommer att sluta på 22.168.192.in-addr.arpa. T.ex. blir gw1.bolaget.se
gw1.bolaget.se.22.168.192.in-addr.arpa.

Delegering

I namnservern för en zon går det att stoppa in så att den delegerar vidare en underdomän. För exemplet med bolaget.se och den separata underdomänen, zonen, teknik.bolaget.se ska namnservern för bolaget.se delegera vidare teknik.bolaget.se till en annan namnserver. För att åstadkomma detta behövs två poster i zonen för bolaget.se. En post som talar om vilken eller vilka datorer som är ansvariga för teknik.bolaget.se och även IP-adressen till de som annars inte går att slå upp i DNS. Exemplet nedan är från zonfilen för bolaget.se och där går ns (ns.bolaget.se.) att slå upp men ns.teknik.bolaget.se. går inte att slå upp för det är ns.teknik.bolaget.se. som har hand om den informationen och det går inte att fråga ns.teknik.bolaget.se. om man inte vet vad ns.teknik.bolaget.se. har för IP-adress. För att avhjälpa detta används ett så kallat glue record (en klisterpost), en A-post för den namnserver som annars inte går att slå upp.

Nedan delegerar ns.bolaget.se. subdomänen teknik.bolaget.se. till servern ns.teknik.bolaget.se. Servern ns.teknik.bolaget.se. är master för zonen och ns.bolaget.se är slav för zonen. I zonfilen finns även ett glue record för ns.teknik.bolaget.se. som pekar på 172.22.1.42.

teknik NS ns teknik NS ns.teknik ns.teknik A 172.22.1.42

Om man själv editerar zonfilerna rekommenderas att de kontrolleras med named-checkzone. Se avsnittet felsökning.

Delegering av delar av IP-adressrymder

Om en organisation har hand om och ansvarar för bakåtuppslagningen för ett nät med adresser så kan normalt inte andra organisationer som får några adresser i detta nät själva hantera bakåtuppslagningen för sina adresser. Dock finns det ett par mindre vackra men fullt fungerande metoder att gå runt denna begränsning.

Inte sköta om bakåtuppslagningen själv utan se till att ha god hand med de som man får sin adress från.
Skapa en subdomän, egen zon, för varje IP-adress där dessa sedan delegeras till de som vill hantera sin egna bakåtuppslagning.
Skapa några stycken subdomäner, zoner, och sedan sätta upp CNAME för IP-adresserna som pekar på namn i dessa subdomäner. Subdomänerna delegeras till de som vill hantera sin egna bakåtuppslagning.

Här följer ett exempel på metod 2 och 3.

Metod 2: En subdomän, zon, för varje IP-adress

Organisationen foo.com får sina IP-adresser 192.168.22.1 - 192.168.22.31 från sin leverantör ISP.net. Nu vill foo.com själva hantera bakåtuppslagningen för sina IP-adresser. foo.com har två namnservrar som hanterar deras DNS, ns1.foo.com och ns2.bar.com. ISP.net har en namnserver som heter ns.isp.net vilken de använder som master för alla sina DNS-zoner.

ISP.net skapar subdomäner, zoner, för varje IP-adress som de delegerar vidare till ns1.foo.com och ns2.bar.com.

Träd som visar IP-adress-zonerna längst ner.

I ISP.net:s zonfil för 22.168.192.in-addr.arpa. stoppar de in följande rader:

ISP.net:s zonfil

$ttl 38400 @ SOA ns.isp.net. root.isp.net. ( 1104409727 ;serial 10800 ;Refresh 3600 ;Retry 604800 ;Expire 38400 ); Negative cache NS ns.isp.net. NS ns.annatbolag.se. 1.22.168.192.in-addr.arpa. NS ns1.foo.com. 1.22.168.192.in-addr.arpa. NS ns2.bar.com. 2.22.168.192.in-addr.arpa. NS ns1.foo.com. 2.22.168.192.in-addr.arpa. NS ns2.bar.com. Ett antal liknande rader. 30.22.168.192.in-addr.arpa. NS ns1.foo.com. 30.22.168.192.in-addr.arpa. NS ns2.bar.com. 31.22.168.192.in-addr.arpa. NS ns1.foo.com. 31.22.168.192.in-addr.arpa. NS ns2.bar.com.

Nu kan organisationen foo.com stoppa in en zon för varje IP-adress i sin named.conf.

foo.com:s named.conf

zone "1.22.168.192.in-addr.arpa" { type master; file "1.22.168.192.in-addr.arpa.zone"; }; zone "2.22.168.192.in-addr.arpa" { type master; file "2.22.168.192.in-addr.arpa.zone"; }; Ett antal liknande zoner. zone "30.22.168.192.in-addr.arpa" { type master; file "30.22.168.192.in-addr.arpa.zone"; }; zone "31.22.168.192.in-addr.arpa" { type master; file "31.22.168.192.in-addr.arpa.zone"; };

Slutligen måste foo.com skapa en zonfil för varje subdomän, zon.

Zonfilerna för subdomänerna, zonerna

$ttl 38400 @ SOA ns1.foo.com. root.foo.com. ( 1104409727 ;serial 10800 ;Refresh 3600 ;Retry 604800 ;Expire 38400 ); Negative cache NS ns1.foo.com. NS ns2.bar.com. PTR burken.foo.com. ; PTR för zonen, t.ex. 17.22.168.192.in-addr.arpa. $ttl 38400 @ SOA ns1.foo.com. root.foo.com. ( 1104409727 ;serial 10800 ;Refresh 3600 ;Retry 604800 ;Expire 38400 ); Negative cache NS ns1.foo.com. NS ns2.bar.com. PTR www.foo.com. ; PTR för zonen, t.ex. 29.22.168.192.in-addr.arpa.

bar.com:s named.conf

Bar.com skapar liknande rader som foo.com i sin named.conf men byter ut "type master" mot "type slave". I namnservern för bar.com ska inga zonfiler skapas då dessa automatiskt skapas när namnservern gör en zonöverföring från foo.com:s namnserver.

Metod 3: Några subdomäner med CNAME:s som pekar ner i dessa

Leverantören isp.net skapar några subdomäner, zoner, under 22.168.192.in-addr.arpa. som de kallar subnet1 till subnet4. Subnet1 delegeras vidare till foo.com. I zonen 22.168.192.in-addr.arpa skapar isp.net CNAME för varje IP-adress som pekar på namn i dessa subdomäner.

Träd som visar subdomänerna Subnet1
till subnet4

ISP.net:s zonfil för 22.168.192.in-addr.arpa.

$ttl 38400 @ SOA ns.isp.net. root.isp.net. ( 1104409727 ;serial 10800 ;Refresh 3600 ;Retry 604800 ;Expire 38400 ); Negative cache NS ns.isp.net. NS ns.annatbolag.se. 1.22.168.192.in-addr.arpa. CNAME 1.subnet1.22.168.192.in-addr.arpa. 2.22.168.192.in-addr.arpa. CNAME 2.subnet1.22.168.192.in-addr.arpa. 3.22.168.192.in-addr.arpa. CNAME 3.subnet1.22.168.192.in-addr.arpa. fler rader. 30.22.168.192.in-addr.arpa. CNAME 30.subnet1.22.168.192.in-addr.arpa. 31.22.168.192.in-addr.arpa. CNAME 31.subnet1.22.168.192.in-addr.arpa. subnet1.22.168.192.in-addr.arpa. NS ns1.foo.com. subnet1.22.168.192.in-addr.arpa. NS ns2.bar.com.

Delar av organisationen foo.com:s named.conf

foo.com lägger in zonen subnet1.22.168.192.in-addr.arpa i sin named.conf.

zone "subnet1.22.168.192.in-addr.arpa" { type master; file "subnet1.22.168.192.in-addr.arpa.zone"; }; Organisationen foo.com:s zonfil för subnet1.22.168.192.in-addr.arpa. foo.org skapar sedan en zonfil för subnet1.22.168.192.in-addr.arpa och stoppar in PTR-poster för de CNAME-namn som ISP.net har i sin zon 22.168.192.in-addr.arpa, alltså det namn som aliasen pekar på. Exempel 1.subnet1.22.168.192.in-addr.arpa. $ttl 38400 @ SOA ns1.foo.com. root.foo.com. ( 1104409727 ;serial 10800 ;Refresh 3600 ;Retry 604800 ;Expire 38400 ); Negative cache NS ns1.foo.com. NS ns2.bar.com. 1 PTR burken.foo.com. 2 PTR annanburk.foo.com. flera rader 30 PTR www2.foo.com. 31 PTR servern.foo.com.

bar.com:s named.conf

I named.conf på namnservern för bar.com ska en likadan zon stoppas in som i named.conf på namnservern ns1.foo.com där "type master" ska bytas ut mot "type slave".

Mer om bakåtuppslagning för delar av adressrymder finns att läsa i RFC 2317.

Felsökning

För kontroll av fel i konfigurationen finns programmen named-checkconf och named-checkzone. named-checkconf används för att kontrollera att filen /etc/named.conf har korrekt syntax.

[root@dumburk ~]# named-checkconf

Om named-checkconf inte ger någon utdata är allt ok.

För att kontrollera att en zonfil har korrekt syntax kan man använda named-checkzone. Till kommandot ska man ange vilken zon det gäller och vilken fil det gäller.

[root@dumburk ~]# named-checkzone foo.org /var/named/foo.org.hosts zone foo.org/IN: loaded serial 1104409727 OK

Då named-checkzone säger OK på slutet är allt som det ska med den aktuella zonfilen.

För felsökning av DNS-uppslagningar finns flera olika verktyg bland annat programmen dig och host. Här beskrivs hur man använder host men samma saker går även att göra med dig. Den enklaste uppslagningen, namn till IP-adress, görs med host följt av domännamn.

[kjell-e@dumburk ~]$ host www.lysator.liu.se www.lysator.liu.se has address 130.236.254.11

Svaret på frågan ses på rad 2 ovan.

Med host går det att slå upp alla typer av poster. Standard är A-poster men andra typer av poster kan anges med flaggan -t till host. Exempel: för att ta reda på vilken eller vilka datorer som har hand om e-post för lysator.liu.se behöver man slå upp MX för lysator.liu.se.

[kjell-e@dumburk ~]$ host -t mx lysator.liu.se lysator.liu.se mail is handled by 10 mail.lysator.liu.se.

Svaret på frågan ses på rad 2 ovan.

För att ta reda på vilka namnservrar som är auktorativa för en domän behöver man slå upp NS för denna domän.

[kjell-e@dumburk ~]$ host -t ns lysator.liu.se lysator.liu.se name server ns-slave.ifm.liu.se. lysator.liu.se name server ns.lysator.liu.se. lysator.liu.se name server nsauth.isy.liu.se.

Här är det 3 st namnservrar som är auktorativa för lysator.liu.se. För att ta reda på vad ns.lysator.liu.se har för IP-adress är det bara att skriva:

[kjell-e@dumburk ~]$ host ns.lysator.liu.se ns.lysator.liu.se has address 130.236.254.2

Svaret på frågan ses på rad 2 ovan.

Slå upp namn från IP-adress kan göras med:

[kjell-e@dumburk ~]$ host 130.236.254.11 11.254.236.130.in-addr.arpa domain name pointer www.lysator.liu.se.
eller med:
[kjell-e@dumburk ~]$ host -t ptr 130.236.254.11 11.254.236.130.in-addr.arpa domain name pointer www.lysator.liu.se.

Fråga andra namnservrar

Ovan ställs alla frågor till den lokala namnservern (en av de som anges i resolv.conf). För att fråga en annan namnserver för att få reda på vad den har för uppfattning om en zon anger man namn eller IP-adress till denna namnserver sist på raden. För att t.ex. fråga ns.liu.se vad den anser att www.lysator.liu.se har för IP-adress blir det:

[kjell-e@dumburk ~]$ host www.lysator.liu.se ns.liu.se Using domain server: Name: ns.liu.se Address: 130.236.1.9#53 Aliases: www.lysator.liu.se has address 130.236.254.11

Zonöverföring

En zonöverföring är en överföring av alla data för en hel zon. Detta kan göras med:

[kjell-e@dumburk ~]$ host -t axfr lysator.liu.se

Om zonöverföringen tillåts visas alla data om zonen. Om zonöverföring inte tillåts blir svaret istället ett felmeddelande i stil med:

Trying "lysator.liu.se" Host lysator.liu.se not found: 5(REFUSED) ; Transfer failed.

Lite övrigt

Om man har en dator med flera nätverksinterface och vill att bind endast ska lyssna på något eller några av dessa går det att åstadkomma med direktivet listen-on. Detta direktiv bör lämpligtvis stå under options i huvudkonfigurationsfilen (named.conf). Om bind t.ex. ska lyssna på 1.2.3.4 och 5.6.7.8 blir det.
listen-on { 1.2.3.4; 5.6.7.8; };

Hela option kan då se ut så här:
options { directory "/var/named"; listen-on { 1.2.3.4; 5.6.7.8; }; };

Slå av rekursiva uppslagningar från alla utom från lokala nätverk

Om man vill att bara datorer på lokala nätverk ska få göra rekursiva namnuppslagningar på denna DNS-server så går det att åstadkomma med allow-recursion. Ange till allow-recursion vilka som ska få göra rekursiva uppslagningar.

Exempel:
Nedan skapar vi först en ACL kallad localnets som innehåller de lokala näten 192.168.1.0/24, 172.22.0.0/16 och datorn med IP-adress 1.2.3.4. Direktivet allow-recursion stoppas in i option-blocket och till den anger vi localnets, 10.10.10.3 och 127.0.0.0 som är de enda som ska få göra rekursiva namnuppslagningar. Det är bra att tillåta nätet 127.0.0.0/8 i annat fall kan program på DNS-servern inte göra rekursiva namnuppslagningar.

acl localnets { 192.168.1.0/24; 172.22.0.0/16; 1.2.3.4; } options { directory "/var/named"; allow-recursion { localnets; 10.10.10.3; 127.0.0.0/8; }; };

Nu får bara de angivna datorerna göra rekursiva namnuppslagningar. Alla andra får dock fortfarande fråga vår namnserver om namn som den har hand om.

Dokumentation till bind

Den officiella sidan för bind är https://www.isc.org/bind/

Till DNS och bind finns även en bra bok:
DNS and BIND, 5th Edition
By Paul Albitz, Cricket Liu
February 2009

Dokumentation till DNS/bind finns även på:

Debians dokumentation.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".