Introduktion

DNS, eller domännamnsystemet, är ofta en svår komponent att få rätt när man lär sig att konfigurera webbplatser och servrar. Även om de flesta förmodligen väljer att använda de DNS-servrar som tillhandahålls av deras webbhotell eller deras domänregistrerare finns det vissa fördelar med att skapa egna DNS-servrar.

I den här guiden kommer vi att diskutera hur man installerar och konfigurerar Bind9 DNS-servern som auktoritativa DNS-servrar på Ubuntu 14.04-maskiner. Vi kommer att ställa in dessa två Bind-servrar för vår domän i en primär-sekundär konfiguration.

Förutsättningar och mål

För att kunna slutföra den här guiden måste du först vara bekant med en del vanlig DNS-terminologi. Kolla in den här guiden för att lära dig mer om de begrepp som vi kommer att implementera i den här guiden.

Du behöver också minst två servrar. En kommer att vara för den ”primära” DNS-servern där zonfilerna för vår domän kommer att komma ifrån och en kommer att vara den ”sekundära” servern som kommer att ta emot zondata genom överföringar och vara tillgänglig i händelse av att den andra servern går ner. På så sätt undviker du faran med att ha en enda felpunkt för dina DNS-servrar.

I motsats till caching- eller forwarding-DNS-servrar eller en DNS-server med flera användningsområden svarar endast auktoritativa servrar på iterativa förfrågningar för de zoner som de är auktoritativa för. Detta innebär att om servern inte vet svaret kommer den bara att tala om för klienten (vanligtvis någon typ av DNS-server som löser upp frågor) att den inte vet svaret och ge en hänvisning till en server som kanske vet mer.

Authoritative-only DNS-servrar är ofta en bra konfiguration för hög prestanda, eftersom de inte har någon överbelastning för att lösa rekursiva frågor från klienter. De bryr sig bara om de zoner som de är utformade för att betjäna.

I den här guiden kommer vi faktiskt att hänvisa till tre servrar. De två namnservrarna som nämns ovan plus en webbserver som vi vill konfigurera som värd i vår zon.

Vi kommer att använda dummy-domänen example.com för den här guiden. Du bör ersätta den med den domän som du konfigurerar. Det här är uppgifterna om de maskiner som vi ska konfigurera:

Syfte	DNS FQDN	IP-adress
Primärnamnsserver	ns1.example.com.	192.0.2.1
Sekundär namnserver	ns2.example.com.	192.0.2.2
Webserver	www.example.com.	192.0.2.3

När du har läst den här guiden bör du ha två auktoritativa namnservrar som endast är auktoritativa och som har konfigurerats för dina domänzoner. Namnen i den mittersta kolumnen i tabellen ovan kommer att kunna användas för att nå dina olika värdar. Med hjälp av den här konfigurationen kommer en rekursiv DNS-server att kunna returnera data om domänen till klienter.

Inställer värdnamnet på namnservrarna

Innan vi går in på konfigurationen av våra namnservrar måste vi se till att vårt värdnamn är konfigurerat på rätt sätt på både vår primära och sekundära DNS-server.

Begynna med att undersöka /etc/hosts-filen. Öppna filen med sudo privilegier i din textredigerare:

sudo nano /etc/hosts

Vi måste konfigurera den här filen så att den identifierar varje servers värdnamn och FQDN korrekt. För den primära namnservern kommer filen att se ut ungefär så här till en början:

127.0.0.1 localhost127.0.1.1 ns1 ns1. . .

Vi bör ändra den andra raden så att den hänvisar till vår specifika värd- och domänkombination och pekar denna till vår offentliga, statiska IP-adress. Vi kan sedan lägga till det okvalificerade namnet som ett alias i slutet. För den primära servern i det här exemplet skulle du ändra den andra raden till följande:

127.0.0.1 localhost192.0.2.1 ns1.example.com ns1. . .

Spara och stäng filen när du är klar.

Vi bör också ändra filen /etc/hostname så att den innehåller vårt okvalificerade värdnamn:

sudo nano /etc/hostname

ns1

Vi kan läsa in det här värdet i det system som körs för tillfället genom att sedan skriva:

sudo hostname -F /etc/hostname

Vi vill genomföra samma procedur på vår sekundära server.

Start med filen /etc/hosts:

sudo nano /etc/hosts

127.0.0.1 localhost192.0.2.2 ns2.example.com ns2

Spara och stäng filen när du är klar.

Ändra sedan filen /etc/hostname. Kom ihåg att endast använda den faktiska värden (bara ns2 i vårt exempel) för den här filen:

sudo nano /etc/hostname

ns2

Läs återigen filen för att ändra det aktuella systemet:

sudo hostname -F /etc/hostname

Dina servrar bör nu ha sina värddefinitioner inställda korrekt.

Installera Bind på båda namnservrarna

På var och en av dina namnservrar kan du nu installera Bind, DNS-servern som vi kommer att använda oss av.

Programvaran Bind finns tillgänglig i Ubuntus standardförvaringsutrymmen, så vi behöver bara uppdatera vårt lokala paketindex och installera programvaran med hjälp av apt. Vi kommer också att inkludera dokumentationen och några vanliga verktyg:

sudo apt-get updatesudo apt-get install bind9 bind9utils bind9-doc

Kör det här installationskommandot på dina primära och sekundära DNS-servrar för att skaffa lämpliga filer.

Konfigurera den primära Bind-servern

När vi nu har installerat programvaran kan vi börja med att konfigurera vår DNS-server på den primära servern.

Konfigurera optionsfilen

Den första saken som vi kommer att konfigurera för att komma igång är named.conf.options-filen.

Bind DNS-servern är också känd som named. Den huvudsakliga konfigurationsfilen finns på /etc/bind/named.conf. Denna fil kallar på de andra filerna som vi faktiskt kommer att konfigurera.

Öppna optionsfilen med sudo privilegier i din editor:

sudo nano /etc/bind/named.conf.options

Nedan har de flesta av de kommenterade raderna strukits för att göra det kortfattat, men generellt sett bör filen se ut så här efter installationen:

options { directory "/var/cache/bind"; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

Den viktigaste saken som vi behöver konfigurera i denna fil är rekursion. Eftersom vi försöker konfigurera en auktoritativ server vill vi inte aktivera rekursion på den här servern. Vi kan stänga av detta i blocket options.

Vi kommer också att välja att inte tillåta överföringar. Vi kommer att åsidosätta detta i individuella zonspecifikationer senare:

options { directory "/var/cache/bind"; recursion no; allow-transfer { none; }; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

När du är klar sparar och stänger du filen.

Konfigurera den lokala filen

Nästa steg som vi måste ta är att specificera de zoner som vi vill kontrollera den här servern. En zon är en del av domänen som är delegerad för hantering till en namnserver och som inte har vidaredelegerats till andra servrar.

Vi konfigurerar example.com-domänen och vi kommer inte att vidaredelegera ansvaret för någon del av domänen till andra servrar. Så zonen kommer att täcka hela vår domän.

För att konfigurera våra zoner måste vi öppna filen /etc/bind/named.conf.local med sudo privilegier:

sudo nano /etc/bind/named.conf.local

Denna fil kommer inledningsvis att vara tom förutom kommentarer. Det finns andra zoner som vår server känner till för allmän hantering, men dessa specificeras i named.conf.default-zones-filen.

För att börja måste vi konfigurera forwardzonen för vår example.com-domän. Forward zone är den konventionella namn-till-IP-upplösning som de flesta av oss tänker på när vi diskuterar DNS. Vi skapar ett konfigurationsblock som definierar den domänzon vi vill konfigurera:

zone "example.com" {};

Notera: Många DNS-verktyg, deras konfigurationsfiler och dokumentation använder termerna ”master” och ”slave” medan DigitalOcean i allmänhet föredrar alternativa deskriptorer. För att undvika förvirring har vi valt att använda termerna ”primary” och ”secondary” för att beteckna relationer mellan servrar, och endast använda ”master” eller ”slave” när ett konfigurationsdirektiv kräver det.

Inom det här blocket lägger vi till hanteringsinformation om den här zonen. Vi anger förhållandet mellan den här DNS-servern och zonen. Detta är type master; i exempelzonen som följer eftersom vi konfigurerar den här maskinen som den primära namnservern för alla våra zoner. Vi pekar också Bind till den fil som innehåller de faktiska resursposterna som definierar zonen.

Vi kommer att hålla våra primära zonfiler i en underkatalog som heter zones i Bind-konfigurationskatalogen. Vi kommer att kalla vår fil db.example.com för att låna konvention från de andra zonfilerna i katalogen Bind. Vårt block kommer att se ut så här nu:

zone "example.com" { type master; file "/etc/bind/zones/db.example.com";};

Vi vill tillåta att den här zonen överförs till vår sekundära server, vi måste lägga till en rad som denna:

zone "example.com" { type master; file "/etc/bind/zones/db.example.com"; allow-transfer { 192.0.2.2; };};

Nästan ska vi definiera den omvända zonen för vår domän.

En bit om omvända zoner

Om den organisation som gav dig dina IP-adresser inte gav dig ett nätverksintervall och delegerade ansvaret för det intervallet till dig, kommer din omvända zonfil inte att refereras och kommer att hanteras av organisationen själv.

Med webbhotellleverantörer tas den omvända mappningen vanligtvis om hand av företaget självt. Med DigitalOcean skapas till exempel omvänd mappning för dina servrar automatiskt om du använder maskinens FQDN som servernamn i kontrollpanelen. De omvända mappningarna för den här handledningen kan till exempel skapas genom att namnge servrarna så här:

I fall som dessa, eftersom du inte har tilldelats en hel del adresser att administrera, bör du använda den här strategin. Strategin som beskrivs nedan tas upp för fullständighetens skull och för att den ska kunna tillämpas om du har tilldelats kontroll över större grupper av sammanhängande adresser.

Reversionszoner används för att koppla tillbaka en IP-adress till ett domännamn. Domännamnssystemet utformades dock ursprungligen för framåtriktade mappningar, så det krävs lite eftertanke för att anpassa detta för att möjliggöra omvända mappningar.

Den information som du måste ha i åtanke för att förstå omvända mappningar är följande:

• I en domän är den mest specifika delen av adressen till vänster. För en IP-adress är den mest specifika delen till höger.
• Den mest specifika delen av en domänspecifikation är antingen en subdomän eller ett värdnamn. Detta definieras i zonfilen för domänen.
• Varje underdomän kan i sin tur definiera fler underdomäner eller värdnamn.

Alla omvända zonmappningar definieras under den särskilda domänen in-addr.arpa, som kontrolleras av Internet Assigned Numbers Authority (IANA). Under denna domän finns ett träd som använder subdomäner för att kartlägga varje oktett i en IP-adress. För att se till att IP-adresserna är lika specifika som vanliga domäner är okteterna i IP-adresserna faktiskt omvända.

Så vår primära DNS-server, med en IP-adress på 192.0.2.1, skulle läsas omvänt som 1.2.0.192. När vi lägger till den här värdspecifikationen som en hierarki som finns under domänen in-addr.arpa kan den specifika värden refereras till som 1.2.0.192.in-addr.arpa.

Då vi definierar enskilda värdar (som den ledande ”1” här) i själva zonfilen när vi använder DNS, skulle zonen som vi konfigurerar vara 2.0.192.in-addr.arpa. Om vår nätverksleverantör har gett oss ett /24-block av adresser, till exempel 192.0.2.0/24, skulle de ha delegerat denna in-addr.arpa-del till oss.

Nu när du vet hur du anger det omvända zonnamnet är den faktiska definitionen exakt densamma som för forward-zonen. Under example.com-zondefinitionen gör du en omvänd zon för det nätverk som du har fått. Återigen är detta förmodligen bara nödvändigt om du har delegerats kontroll över ett block av adresser:

zone "2.0.192.in-addr.arpa" { type master; file "/etc/bind/zones/db.192.0.2";};

Vi har valt att döpa filen till db.192.0.2. Detta är specifikt om vad zonen konfigurerar och är mer lättläst än den omvända notationen.

Spara och stäng filen när du är klar.

Skapa filen för den framåtriktade zonen

Vi har berättat för Bind om våra framåtriktade och bakåtriktade zoner nu, men vi har ännu inte skapat filerna som kommer att definiera dessa zoner.

Om du minns det, så angav vi att filerna skulle ligga i en underkatalog som heter zones. Vi måste skapa denna katalog:

sudo mkdir /etc/bind/zones

Nu kan vi använda några av de redan existerande zonfilerna i katalogen Bind som mallar för de zonfiler vi vill skapa. För den framåtriktade zonen kommer filen db.local att ligga nära det vi behöver. Kopiera den filen till underkatalogen zones med det namn som används i filen named.conf.local.

sudo cp /etc/bind/db.local /etc/bind/zones/db.example.com

Medans vi gör detta kan vi också kopiera en mall för den omvända zonen. Vi kommer att använda db.127-filen, eftersom den är en nära matchning för vad vi behöver:

sudo cp /etc/bind/db.127 /etc/bind/zones/db.192.0.2

Öppna nu filen för den framåtriktade zonen med sudo-privilegier i din textredigerare:

sudo nano /etc/bind/zones/db.example.com

Filen kommer att se ut så här:

$TTL 604800@ IN SOA localhost. root.localhost. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;@ IN NS localhost.@ IN A 127.0.0.1@ IN AAAA ::1

Den första sak som vi behöver vill göra är att ändra SOA (start of authority) posten som startar med den första @ symbolen och fortsätter fram till den avslutande parentesen.

Vi måste ersätta localhost. med namnet på den här maskinens FQDN. Den här delen av posten används för att definiera en namnserver som kommer att svara auktoritativt för den zon som definieras. Detta kommer att vara den maskin som vi konfigurerar nu, ns1.example.com. i vårt fall (lägg märke till den avslutande punkten. Detta är viktigt för att vår post ska registreras korrekt!).

Vi vill också ändra nästa del, som faktiskt är en speciellt formaterad e-postadress där @ ersätts av en punkt. Vi vill att våra e-postmeddelanden ska gå till en administratör av domänen, så den traditionella e-postadressen är [email protected]. Vi skulle översätta detta så att det ser ut som admin.example.com.:

@ IN SOA ns1.example.com. admin.example.com. (

Nästa del som vi måste ändra är serienumret. Värdet på serienumret är hur Bind berättar om den behöver skicka uppdaterad information till den sekundära servern.

Anmärkning: Att inte öka serienumret är ett av de vanligaste misstagen som leder till problem med zonuppdateringar. Varje gång du gör en ändring måste du öka serienumret.

En vanlig metod är att använda en konvention för att öka numret. Ett tillvägagångssätt är att använda datumet i formatet ÅÅÅÅÅMMDD tillsammans med ett revisionsnummer för dagen som läggs till på slutet. Så den första revideringen som gjordes den 05 juni 2014 kan ha serienumret 2014060501 och en uppdatering som görs senare samma dag kan ha serienumret 2014060502. Värdet kan vara ett 10-siffrigt nummer.

Det är värt att anta en konvention för att underlätta användningen, men för att hålla saker och ting enkla för vår demonstration kommer vi bara att ställa in vår till 5 för tillfället:

@ IN SOA ns1.example.com. admin.example.com. ( 5 ; Serial

Nästan kan vi göra oss av med de tre sista raderna i filen (de längst ner som börjar med @) eftersom vi kommer att göra våra egna.

Det första vi vill fastställa efter SOA-posten är namnservrarna för vår zon. Vi anger domänen och sedan våra två namnservrar som är auktoritativa för zonen, med namn. Eftersom dessa namnservrar kommer att vara värdar inom själva domänen kommer det att se lite självhänvisande ut.

För vår guide kommer det att se ut så här. Återigen, var uppmärksam på de avslutande punkterna!:

; Name serversexample.com. IN NS ns1.example.com.example.com. IN NS ns2.example.com.

Då syftet med en zonfil främst är att mappa värdnamn och tjänster till specifika adresser, är vi inte klara än. Alla program som läser den här zonfilen kommer att vilja veta var ns1– och ns2-servrarna finns för att få tillgång till de auktoritativa zonerna.

Så härnäst måste vi skapa A-posterna som kommer att associera namnservarnamnen till de faktiska IP-adresserna för våra namnservrar:

; A records for name serversns1 IN A 192.0.2.1ns2 IN A 192.0.2.2

Nu när vi har A-posterna som framgångsrikt löser upp våra namnservrar till deras korrekta IP-adresser, kan vi lägga till ytterligare poster. Kom ihåg att vi har en webbserver på en av våra värdar som vi vill använda för att visa vår webbplats. Vi kommer att peka förfrågningar för den allmänna domänen (example.com i vårt fall) till den här värden, liksom förfrågningar för värden www. Det kommer att se ut så här:

; Other A records@ IN A 192.0.2.3www IN A 192.0.2.3

Du kan lägga till ytterligare värdar som du behöver definiera genom att skapa ytterligare A-poster. Referera till vår guide om DNS grunder för att bekanta dig med några av dina alternativ för att skapa ytterligare poster.

När du är klar ska filen se ut ungefär så här:

$TTL 604800@ IN SOA ns1.example.com. admin.example.com. ( 5 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;; Name serversexample.com. IN NS ns1.example.com.example.com. IN NS ns2.example.com.; A records for name serversns1 IN A 192.0.2.1ns2 IN A 192.0.2.2; Other A records@ IN A 192.0.2.3www IN A 192.0.2.3

Spara och stäng filen när du är klar.

Skapa filen för den omvända zonen

Nu har vi konfigurerat den framåtriktade zonen, men vi måste konfigurera filen för den omvända zonen som vi angav i vår konfigurationsfil. Vi skapade filen redan i början av förra avsnittet.

Öppna filen i din textredigerare med sudo privilegier:

sudo nano db.192.0.2

Filen ska se ut så här:

$TTL 604800@ IN SOA localhost. root.localhost. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;@ IN NS localhost.1.0.0 IN PTR localhost.

Vi kommer att gå igenom i stort sett samma procedur som vi gjorde med den framåtriktade zonen. Justera först domännamnet, administratörens e-postadress och serienumret så att det stämmer exakt överens med vad du hade i den förra filen (serienumret kan vara annorlunda, men bör ökas):

@ IN SOA example.com. admin.example.com. ( 5 ; Serial

Tillbaka, radera ut raderna under den avslutande parentesen i SOA-rekordet. Vi kommer att ta den sista oktetten av varje IP-adress i vårt nätverksområde och mappa tillbaka den till den värdens FQDN med hjälp av en PTR-post. Varje IP-adress bör bara ha en enda PTR-post för att undvika problem i vissa programvaror, så du måste välja det värdnamn som du vill göra en omvänd mappning till.

Om du till exempel har en e-postserver installerad vill du förmodligen ställa in den omvända mappningen till e-postnamnet, eftersom många system använder den omvända mappningen för att validera adresser.

Först måste vi ställa in våra namnservrar igen:

; Name servers IN NS ns1.example.com. IN NS ns2.example.com.

Nästan kommer du att använda den sista oktetten i den IP-adress du hänvisar till och peka tillbaka den till det fullt kvalificerade domännamnet som du vill återvända med. I vårt exempel använder vi detta:

; PTR Records1 IN PTR ns1.example.com.2 IN PTR ns2.example.com.3 IN PTR www.example.com.

När du är klar ska filen se ut ungefär så här:

$TTL 604800@ IN SOA example.com. admin.example.com. ( 5 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;; Name servers IN NS ns1.example.com. IN NS ns2.example.com.; PTR records1 IN PTR ns1.example.com.2 IN PTR ns2.example.com.3 IN PTR www.example.com.

Spara och stäng filen när du är klar.

Testa filerna och starta om tjänsten

Konfigurationen för den primära servern är nu klar, men vi måste fortfarande implementera våra ändringar.

För att starta om vår tjänst bör vi testa alla våra konfigurationsfiler för att se till att de är korrekt konfigurerade. Vi har några verktyg som kan kontrollera syntaxen i var och en av våra filer.

Först kan vi kontrollera filerna named.conf.local och named.conf.options med hjälp av kommandot named-checkconf. Eftersom båda dessa filer är källor till skelettfilen named.conf kommer den att testa syntaxen för de filer vi ändrat.

sudo named-checkconf

Om detta returnerar utan några meddelanden betyder det att filerna named.conf.local och named.conf.options är syntaktiskt giltiga.

Nästan kan du kontrollera dina enskilda zonfiler genom att skicka domänen som zonen hanterar och zonfilens plats till kommandot named-checkzone. Så för vår guide kan du kontrollera den framåtriktade zonfilen genom att skriva:

sudo named-checkzone example.com /etc/bind/zones/db.example.com

Om filen inte har några problem bör den tala om för dig att den laddat in rätt serienummer och ge ”OK”-meddelandet;

zone example.com/IN: loaded serial 5OK

Om du stöter på några andra meddelanden betyder det att du har ett problem med din zonfil. Vanligtvis är meddelandet ganska beskrivande om vilken del som är ogiltig.

Du kan kontrollera den omvända zonen genom att skicka in-addr.arpa-adressen och filnamnet. För vår demonstration skulle vi skriva detta:

sudo named-checkzone 2.0.192.in-addr.arpa /etc/bind/zones/db.192.0.2

Det här borde ge dig ett liknande meddelande om att du laddar in rätt serienummer:

zone 2.0.192.in-addr.arpa/IN: loaded serial 5OK

Om alla dina filer checkar ut kan du starta om din Bind-tjänst:

sudo service bind9 restart

Du bör kontrollera loggarna genom att skriva:

sudo tail -f /var/log/syslog

Håll ett öga på den här loggen för att se till att det inte finns några fel.

Konfigurera den sekundära bindningsservern

När vi nu har konfigurerat den primära servern kan vi gå vidare och konfigurera den sekundära servern. Detta kommer att vara betydligt enklare än den primära servern.

Konfigurera optionsfilen

Även här börjar vi med filen named.conf.options. Öppna den med sudo privilegier i din textredigerare:

sudo nano /etc/bind/named.conf.options

Vi kommer att göra exakt samma ändringar i den här filen som vi gjorde i vår primärservers fil.

options { directory "/var/cache/bind"; recursion no; allow-transfer { none; }; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

Spara och stäng filen när du är klar.

Konfigurering av den lokala konfigurationsfilen

Nästan kommer vi att konfigurera named.conf.local-filen på den sekundära servern. Öppna den med sudo privilegier i din textredigerare:

sudo nano /etc/bind/named.conf.local

Här kommer vi att skapa var och en av våra zonspecifikationer på samma sätt som vi gjorde på den primära servern. Värdena och några av parametrarna kommer dock att vara olika.

Först kommer vi att arbeta med den framåtriktade zonen. Börja på samma sätt som du gjorde i den primära filen:

zone "example.com" {};

Den här gången ska vi ställa in type till slave eftersom den här servern fungerar som en sekundär för den här zonen. Detta innebär helt enkelt att den får sina zonfiler genom överföring snarare än en fil på det lokala systemet. Dessutom ska vi bara ange det relativa filnamnet istället för den absoluta sökvägen till zonfilen.

Anledningen till detta är att Bind för sekundära zoner lagrar filerna /var/cache/bind. Bind är redan konfigurerat för att leta i denna katalogplacering, så vi behöver inte ange sökvägen.

För vår forward-zon kommer dessa detaljer att se ut så här:

zone "example.com" { type slave; file "db.example.com";};

Slutligt kommer vi i stället för allow-transfer-direktivet att ange de primära servrar, med IP-adress, som den här servern kommer att acceptera zonöverföringar från. Detta görs i ett direktiv som heter masters:

zone "example.com" { type slave; file "db.example.com"; masters { 192.0.2.1; };};

Detta avslutar vår specifikation av forward-zoner. Vi kan använda samma exakta format för att ta hand om vår specifikation av den omvända zonen:

zone "2.0.192.in-addr.arpa" { type slave; file "db.192.0.2"; masters { 192.0.2.1; };};

När du är klar kan du spara och stänga filen.

Testning av filerna och omstart av tjänsten

Vi behöver faktiskt inte göra något av det faktiska skapandet av zonfilen på den sekundära maskinen eftersom den här servern, som vi nämnde tidigare, kommer att ta emot zonfilerna från den primära servern. Så vi är redo att testa.

Nyligen bör vi kontrollera syntaxen i konfigurationsfilen. Eftersom vi inte har några zonfiler att kontrollera behöver vi bara använda verktyget named-checkconf:

sudo named-checkconf

Om detta returnerar utan några fel betyder det att filerna du ändrat inte har några syntaxfel.

Om detta är fallet kan du starta om Bind-tjänsten:

sudo service bind9 restart

Kontrollera loggarna på både den primära och den sekundära servern med hjälp av:

sudo tail -f /var/log/syslog

Du bör se några poster som indikerar att zonfilerna har överförts på rätt sätt.

Delegera auktoritet till dina namnservrar

Dina auktoritativa namnservrar bör nu vara helt konfigurerade. Du måste dock fortfarande delegera auktoritet för din domän till dina namnservrar.

För att göra detta måste du gå till den webbplats där du köpte ditt domännamn. Gränssnittet och kanske terminologin kommer att skilja sig åt beroende på vilken domännamnsregistrerare du använde.

I dina domäninställningar letar du efter ett alternativ där du kan ange de namnservrar du vill använda. Eftersom våra namnservrar finns inom vår domän är detta ett specialfall.

Istället för att registraren helt enkelt delegerar auktoritet för zonen genom att använda NS-poster måste den skapa en glue-post. En glue record är en A-post som anger IP-adresserna för namnservrarna efter att den anger de namnservrar som den delegerar auktoritet till.

I vanliga fall listar delegeringen bara de namnservrar som kommer att hantera domänens auktoritet, men när namnservrarna finns inom själva domänen behövs en A-post för namnservrarna i den överordnade zonen. Om detta inte skedde skulle DNS-resolverare fastna i en slinga eftersom den aldrig skulle kunna hitta IP-adressen till domänens namnservrar för att följa delegeringsstigen.

Så du måste hitta en sektion i din domänregistrerares kontrollpanel där du kan ange namnservrar och deras IP-adresser.

Som demonstration har registraren Namecheap två olika sektioner för namnservrar.

Det finns en sektion som heter ”Nameserver Registration” där du kan ange IP-adresser för namnservrar inom din domän:

Inom denna sektion kan du ange IP-adresserna för de namnservrar som finns inom domänen:

Detta kommer att skapa A-posten som som tjänar som glue-poster som du behöver i den överordnade zondatabasen.

När du har gjort detta bör du kunna ändra de aktiva namnservrarna till domänens servrar. I NameCheap görs detta med hjälp av menyalternativet ”Domain Name Server Setup”:

Här kan du säga åt den att använda de namnservrar du lagt till som auktoritativa servrar för din webbplats:

Förändringarna kan ta ett tag att sprida sig, men du bör se att data från dina namnservrar används inom de närmaste 24-48 timmar för de flesta registrarer.

Slutsats

Du bör nu ha två auktoritativa DNS-servrar konfigurerade för att servera dina domäner. Dessa kan användas för att lagra zoninformation för ytterligare domäner när du skaffar fler.

Om du konfigurerar och hanterar dina egna DNS-servrar får du mest kontroll över hur DNS-posterna hanteras. Du kan göra ändringar och vara säker på att alla relevanta delar av DNS-data är uppdaterade vid källan. Även om andra DNS-lösningar kan göra den här processen enklare är det viktigt att veta att du har alternativ och att förstå vad som händer i mer paketerade lösningar.