Inleiding

DNS, of het domeinnaam systeem, is vaak een moeilijk onderdeel om goed te krijgen wanneer je leert hoe je websites en servers moet configureren. Hoewel de meeste mensen er waarschijnlijk voor zullen kiezen om de DNS servers te gebruiken die door hun hostingbedrijf of hun domeinregistrar worden geleverd, zijn er enkele voordelen aan het maken van uw eigen DNS servers.

In deze gids zullen we bespreken hoe de Bind9 DNS server te installeren en te configureren als authoritative-only DNS servers op Ubuntu 14.04 machines. We zullen deze twee Bind servers opzetten voor ons domein in een primaire-secundaire configuratie.

Voorvereisten en doelen

Om deze gids te voltooien, moet u eerst bekend zijn met enkele algemene DNS-terminologie. Bekijk deze gids om meer te leren over de concepten die we in deze gids zullen implementeren.

U heeft ook minstens twee servers nodig. Een daarvan is de “primaire” DNS-server waar de zonebestanden voor ons domein vandaan komen en een andere de “secundaire” server die de zonegegevens ontvangt door middel van transfers en die beschikbaar is in het geval dat de andere server uitvalt. Dit vermijdt het gevaar van het hebben van een enkel punt van mislukking voor uw DNS-servers.

In tegenstelling tot caching of forwarding DNS-servers of een multi-purpose DNS-server, authoritative-only servers reageren alleen op iteratieve query’s voor de zones waarvoor ze authoritative zijn. Dit betekent dat als de server het antwoord niet weet, hij de client (meestal een soort resolving DNS-server) gewoon vertelt dat hij het antwoord niet weet en een verwijzing geeft naar een server die misschien meer weet.

Authoritative-only DNS-servers zijn vaak een goede configuratie voor hoge prestaties, omdat ze niet de overhead hebben van het oplossen van recursieve queries van clients. Ze geven alleen om de zones die ze moeten bedienen.

In deze gids hebben we het eigenlijk over drie servers. De twee naamservers die hierboven zijn genoemd, plus een webserver die we als host binnen onze zone willen configureren.

We zullen voor deze gids het dummy domein example.com gebruiken. U zou het moeten vervangen door het domein dat u configureert. Dit zijn de details van de machines die we gaan configureren:

Doel	DNS FQDN	IP-adres
Primary name server	ns1.example.com.	192.0.2.1
Secundaire naamserver	ns2.example.com.	192.0.2.2
Web Server	www.example.com.	192.0.2.3

Na het voltooien van deze gids, zou u twee gezaghebbende-only naamservers moeten hebben geconfigureerd voor uw domeinzones. De namen in de middelste kolom in de tabel hierboven zullen gebruikt kunnen worden om uw verschillende hosts te bereiken. Met deze configuratie zal een recursieve DNS server gegevens over het domein aan clients kunnen retourneren.

De hostnaam op de nameservers instellen

Voordat we beginnen met de configuratie van onze nameservers, moeten we ervoor zorgen dat onze hostnaam juist is geconfigureerd op zowel onze primaire als secundaire DNS server.

Begin met het onderzoeken van het /etc/hosts bestand. Open het bestand met sudo privileges in uw tekst editor:

sudo nano /etc/hosts

We moeten dit zo configureren dat het de hostnaam en FQDN van elke server correct identificeert. Voor de primaire naamserver zal het bestand er in eerste instantie zo uitzien:

127.0.0.1 localhost127.0.1.1 ns1 ns1. . .

We moeten de tweede regel aanpassen om te verwijzen naar onze specifieke host en domein combinatie en deze verwijzen naar ons publieke, statische IP adres. We kunnen dan de ongekwalificeerde naam toevoegen als een alias aan het eind. Voor de primaire server in dit voorbeeld, zou u de tweede regel als volgt wijzigen:

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

Bewaar en sluit het bestand als u klaar bent.

We moeten ook het /etc/hostname bestand wijzigen om onze ongekwalificeerde hostnaam te bevatten:

sudo nano /etc/hostname

ns1

We kunnen deze waarde dan in het huidige draaiende systeem inlezen door te typen:

sudo hostname -F /etc/hostname

We willen dezelfde procedure uitvoeren op onze secundaire server.

Begin met het /etc/hosts bestand:

sudo nano /etc/hosts

127.0.0.1 localhost192.0.2.2 ns2.example.com ns2

Bewaar en sluit het bestand als u klaar bent.

Dan, wijzigt u het /etc/hostname bestand. Vergeet niet om alleen de werkelijke host te gebruiken (gewoon ns2 in ons voorbeeld) voor dit bestand:

sudo nano /etc/hostname

ns2

Opnieuw, lees het bestand om het huidige systeem te wijzigen:

sudo hostname -F /etc/hostname

Uw servers zouden nu hun host definities correct moeten hebben ingesteld.

Installeer Bind op beide Name Servers

Op elk van uw nameservers kunt u nu Bind installeren, de DNS server die we gaan gebruiken.

De Bind software is beschikbaar in Ubuntu’s standaard repositories, dus we hoeven alleen maar onze lokale pakket index te updaten en de software te installeren met apt. We zullen ook de documentatie en enkele algemene hulpprogramma’s toevoegen:

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

Run dit installatie commando op uw primaire en secundaire DNS servers om de juiste bestanden te verkrijgen.

Configureer de primaire Bind Server

Nu we de software geïnstalleerd hebben, kunnen we beginnen met het configureren van onze DNS server op de primaire server.

Configureer het Opties Bestand

Het eerste dat we zullen configureren om te beginnen is het named.conf.options bestand.

De Bind DNS server is ook bekend als named. Het hoofd configuratie bestand staat op /etc/bind/named.conf. Dit bestand roept de andere bestanden aan die we zullen configureren.

Open het opties bestand met sudo privileges in uw editor:

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

Hieronder zijn de meeste van de becommentarieerde regels weggelaten om het kort te houden, maar in het algemeen zou het bestand er zo uit moeten zien na installatie:

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

Het belangrijkste dat we in dit bestand moeten configureren is recursie. Aangezien we proberen om een authoritative-only server op te zetten, willen we recursie niet inschakelen op deze server. We kunnen dit uitzetten in het options blok.

We gaan ook standaard geen transfers toestaan. We zullen dit later in individuele zone-specificaties opheffen:

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

Wanneer u klaar bent, slaat u het bestand op en sluit u het.

Het lokale bestand configureren

De volgende stap die we moeten nemen is het specificeren van de zones die we voor deze server willen beheren. Een zone is elk deel van het domein dat voor beheer is gedelegeerd aan een naamserver en niet is gesubdelegeerd aan andere servers.

We configureren het example.com domein en we gaan de verantwoordelijkheid voor geen enkel deel van het domein subdelegeren aan andere servers. Dus de zone zal ons hele domein omvatten.

Om onze zones te configureren, moeten we het /etc/bind/named.conf.local bestand openen met sudo privileges:

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

Dit bestand zal in eerste instantie leeg zijn, behalve commentaar. Er zijn andere zones die onze server kent voor algemeen beheer, maar deze worden gespecificeerd in het named.conf.default-zones bestand.

Om te beginnen, moeten we de forward zone configureren voor ons example.com domein. Forward zones zijn de conventionele naam-naar-IP resolutie waar de meesten van ons aan denken als we het over DNS hebben. We maken een configuratieblok dat de domeinzone definieert die we willen configureren:

zone "example.com" {};

Note: Veel DNS-tools, hun configuratiebestanden en documentatie gebruiken de termen “master” en “slave”, terwijl DigitalOcean over het algemeen de voorkeur geeft aan alternatieve descriptoren. Om verwarring te voorkomen, hebben we ervoor gekozen de termen “primair” en “secundair” te gebruiken om relaties tussen servers aan te duiden, en alleen “master” of “slave” te gebruiken wanneer een configuratierichtlijn dit vereist.

Binnen dit blok voegen we de beheerinformatie over deze zone toe. We specificeren de relatie van deze DNS-server tot de zone. Dit is type master; in de voorbeeldzone die volgt, omdat we deze machine configureren als de primaire naamserver voor al onze zones. We wijzen Bind ook naar het bestand met de eigenlijke resource records die de zone definiëren.

We gaan onze primaire zone bestanden bewaren in een subdirectory genaamd zones binnen de Bind configuratie directory. We zullen ons bestand db.example.com noemen om conventie te lenen van de andere zone bestanden in de Bind directory. Ons blok zal er nu als volgt uitzien:

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

We willen toestaan dat deze zone wordt overgedragen naar onze secundaire server, we moeten een regel als deze toevoegen:

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

Volgende, we gaan de reverse zone voor ons domein definiëren.

Een beetje over Reverse Zones

Als de organisatie die u uw IP-adressen heeft gegeven, u geen netwerkbereik heeft gegeven en de verantwoordelijkheid voor dat bereik aan u heeft gedelegeerd, dan zal uw reverse zone-bestand niet worden verwezen en zal het door de organisatie zelf worden afgehandeld.

Bij hostingproviders wordt de reverse mapping meestal door het bedrijf zelf verzorgd. Bijvoorbeeld, met DigitalOcean, zal reverse mappings voor uw servers automatisch worden gemaakt als u de machine FQDN als de servernaam in het configuratiescherm. De reverse mappings voor deze tutorial zouden bijvoorbeeld kunnen worden aangemaakt door de servers als volgt te benoemen:

In gevallen als deze, aangezien u geen brok adressen toegewezen hebt gekregen om te beheren, zou u deze strategie moeten gebruiken. De hieronder beschreven strategie wordt behandeld voor de volledigheid en om deze toepasbaar te maken als u het beheer over grotere groepen aaneengesloten adressen hebt gedelegeerd.

Reverse zones worden gebruikt om een IP-adres terug te koppelen naar een domeinnaam. Het domeinnaamsysteem is echter oorspronkelijk ontworpen voor de voorwaartse toewijzingen, dus er is enig denkwerk nodig om dit aan te passen om omgekeerde toewijzingen mogelijk te maken.

De stukjes informatie die u in gedachten moet houden om omgekeerde toewijzingen te begrijpen, zijn:

• In een domein staat het meest specifieke deel van het adres aan de linkerkant. Bij een IP-adres staat het meest specifieke deel aan de rechterkant.
• Het meest specifieke deel van een domeinspecificatie is ofwel een subdomein of een hostnaam. Dit wordt gedefinieerd in het zonebestand voor het domein.
• Elk subdomein kan op zijn beurt weer meer subdomeinen of hosts definiëren.

Alle reverse zone mappings worden gedefinieerd onder het speciale domein in-addr.arpa, dat wordt beheerd door de Internet Assigned Numbers Authority (IANA). Onder dit domein bestaat een boom die gebruik maakt van subdomeinen om elk van de octetten in een IP-adres in kaart te brengen. Om ervoor te zorgen dat de specificiteit van de IP-adressen die van normale domeinen weerspiegelt, worden de octetten van de IP-adressen in feite omgedraaid.

Dus onze primaire DNS-server, met een IP-adres van 192.0.2.1, zou worden omgedraaid zodat hij te lezen is als 1.2.0.192. Wanneer we deze hostspecificatie toevoegen als een hiërarchie die bestaat onder het in-addr.arpa domein, kan naar de specifieke host worden verwezen als 1.2.0.192.in-addr.arpa.

Omdat we individuele hosts definiëren (zoals de leidende “1” hier) binnen het zonebestand zelf wanneer we DNS gebruiken, zou de zone die we zouden configureren 2.0.192.in-addr.arpa zijn. Als onze netwerkprovider ons een /24 blok adressen heeft gegeven, zeg 192.0.2.0/24, dan zouden zij dit in-addr.arpa gedeelte aan ons hebben gedelegeerd.

Nu u weet hoe u de reverse zone naam moet specificeren, is de eigenlijke definitie precies hetzelfde als de forward zone. Maak onder de example.com zone definitie een reverse zone voor het netwerk dat u gegeven is. Nogmaals, dit is waarschijnlijk alleen nodig als u controle gedelegeerd werd over een blok adressen:

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

We hebben gekozen om het bestand db.192.0.2 te noemen. Dit is specifiek over wat de zone configureert en is leesbaarder dan de omgekeerde notatie.

Bewaar en sluit het bestand als u klaar bent.

Maak het Forward Zone Bestand

We hebben Bind nu verteld over onze forward en reverse zones, maar we hebben nog niet de bestanden gemaakt die deze zones zullen definiëren.

Als u zich herinnert, hebben we de bestandslocaties gespecificeerd als zijnde binnen een subdirectory genaamd zones. We moeten deze directory aanmaken:

sudo mkdir /etc/bind/zones

Nu kunnen we enkele van de reeds bestaande zone-bestanden in de Bind directory gebruiken als sjablonen voor de zone-bestanden die we willen aanmaken. Voor de forward zone zal het db.local bestand in de buurt komen van wat we nodig hebben. Kopieer dat bestand naar de zones subdirectory met de naam die gebruikt wordt in het named.conf.local bestand.

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

Terwijl we dit doen, kunnen we ook een sjabloon voor de reverse zone kopiëren. We zullen het db.127 bestand gebruiken, omdat het een goede match is voor wat we nodig hebben:

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

Nu, open het forward zone bestand met sudo privileges in uw tekst editor:

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

Het bestand zal er als volgt uitzien:

$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

Het eerste wat we moeten doen is het SOA (begin van autoriteit) record wijzigen dat begint met het eerste @ symbool en doorgaat tot het sluitende haakje.

We moeten de localhost. vervangen door de naam van het FQDN van deze machine. Dit gedeelte van het record wordt gebruikt om een naamserver te definiëren die authoritatief zal antwoorden voor de zone die gedefinieerd wordt. Dit zal de machine zijn die we nu configureren, ns1.example.com. in ons geval (let op de punt achteraan. Dit is belangrijk om onze invoer correct te laten registreren).

We willen ook het volgende stuk veranderen, wat eigenlijk een speciaal geformatteerd email adres is met de @ vervangen door een punt. We willen dat onze emails naar een beheerder van het domein gaan, dus de traditionele email is [email protected]. We zouden dit vertalen zodat het eruit ziet als admin.example.com.:

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

Het volgende stuk dat we moeten bewerken is het serienummer. De waarde van het serienummer is hoe Bind vertelt of het bijgewerkte informatie naar de secundaire server moet sturen.

Note: Het serienummer niet verhogen is een van de meest voorkomende fouten die leidt tot problemen met zone updates. Elke keer dat u een wijziging aanbrengt, moet u het serienummer ophogen.

Een gangbare praktijk is het gebruik van een conventie voor het ophogen van het nummer. Eén benadering is om de datum in YYYYMMDD formaat te gebruiken, samen met een revisienummer voor de dag toegevoegd aan het einde. Dus de eerste revisie gemaakt op 05 juni 2014 kan een serienummer hebben van 2014060501 en een update die later die dag gemaakt wordt kan een serienummer hebben van 2014060502. De waarde kan een getal van 10 cijfers zijn.

Het is de moeite waard om een conventie te gebruiken voor gebruiksgemak, maar om het eenvoudig te houden voor onze demonstratie, zullen we de onze voorlopig op 5 zetten:

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

Volgende, we kunnen ons ontdoen van de laatste drie regels in het bestand (degene onderaan die beginnen met @) omdat we onze eigen regels zullen maken.

Het eerste wat we willen vastleggen na het SOA record zijn de nameservers voor onze zone. We specificeren het domein en dan onze twee nameservers die gezaghebbend zijn voor de zone, bij naam. Aangezien deze nameservers hosts zullen zijn binnen het domein zelf, zal het er een beetje zelf-referentieel uitzien.

Voor onze gids, zal het er zo uitzien. Nogmaals, let op de eindpunten!:

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

Omdat het doel van een zonebestand vooral is om hostnamen en diensten aan specifieke adressen toe te wijzen, zijn we nog niet klaar. Software die dit zonebestand leest, zal willen weten waar de ns1 en ns2 servers zich bevinden om toegang te krijgen tot de gezaghebbende zones.

Dus nu moeten we de A records maken die deze nameserver namen zullen associëren met de werkelijke IP adressen van onze nameservers:

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

Nu we de A records hebben om onze nameservers met succes naar hun juiste IP adressen om te zetten, kunnen we eventuele extra records toevoegen. Vergeet niet dat we een webserver op een van onze hosts hebben die we willen gebruiken om onze site te serveren. We zullen verzoeken voor het algemene domein (example.com in ons geval) naar deze host wijzen, evenals verzoeken voor de www host. Het zal er als volgt uitzien:

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

U kunt extra hosts toevoegen die u nodig hebt om te definiëren door extra A records aan te maken. Raadpleeg onze DNS-basisgids om vertrouwd te raken met enkele van uw opties voor het maken van extra records.

Wanneer u klaar bent, zou uw bestand er ongeveer zo uit moeten zien:

$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

Bewaar en sluit het bestand wanneer u klaar bent.

Maak het omgekeerde zonebestand

Nu hebben we de voorwaartse zone geconfigureerd, maar we moeten het omgekeerde zonebestand instellen dat we in ons configuratiebestand hebben opgegeven. We hebben het bestand al gemaakt aan het begin van de laatste sectie.

Open het bestand in uw tekst editor met sudo privileges:

sudo nano db.192.0.2

Het bestand zou er zo uit moeten zien:

$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.

We zullen veel van dezelfde procedure doorlopen als we deden met de forward zone. Ten eerste, pas de domeinnaam, de admin email, en het serienummer aan zodat ze precies overeenkomen met wat u in het laatste bestand had (Het serienummer kan verschillend zijn, maar moet verhoogd worden):

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

Werk opnieuw door de regels onder de haakjes van het SOA record weg te vegen. We zullen het laatste octet van elk IP adres in ons netwerkbereik nemen en het terug toewijzen aan de FQDN van die host met een PTR record. Elk IP adres zou slechts één PTR record mogen hebben om problemen in sommige software te vermijden, dus moet u de hostnaam kiezen waarnaar u wenst te reverse mappen.

Bijvoorbeeld, als u een mailserver hebt ingesteld, wilt u waarschijnlijk de reverse mapping instellen op de mailnaam, aangezien veel systemen de reverse mapping gebruiken om adressen te valideren.

Eerst moeten we onze nameservers opnieuw instellen:

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

Volgende, u gebruikt het laatste octet van het IP adres waarnaar u verwijst en wijst dat terug naar de volledig gekwalificeerde domeinnaam waarmee u wilt terugkeren. Voor ons voorbeeld gebruiken we dit:

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

Wanneer u klaar bent, zou het bestand er ongeveer zo uit moeten zien:

$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.

Bewaar en sluit het bestand wanneer u klaar bent.

De bestanden testen en de service herstarten

De configuratie voor de primaire server is nu voltooid, maar we moeten onze wijzigingen nog doorvoeren.

Voordat we onze service herstarten, moeten we al onze configuratiebestanden testen om er zeker van te zijn dat ze correct zijn geconfigureerd. We hebben een aantal tools die de syntax van elk van onze bestanden kunnen controleren.

Eerst kunnen we de named.conf.local en named.conf.options bestanden controleren met behulp van het named-checkconf commando. Aangezien beide bestanden bron zijn door het skelet named.conf bestand, zal het de syntax van de bestanden die we gewijzigd hebben testen.

sudo named-checkconf

Als dit terugkomt zonder enige berichten, betekent dit dat de named.conf.local en named.conf.options bestanden syntactisch geldig zijn.

Volgende, kunt u uw individuele zone bestanden controleren door het domein dat de zone behandelt en de zone bestandslocatie door te geven aan het named-checkzone commando. Dus voor onze gids, zou u het forward zonebestand kunnen controleren door te typen:

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

Als uw bestand geen problemen heeft, zou het u moeten vertellen dat het het juiste serienummer heeft geladen en de “OK” boodschap geven;

zone example.com/IN: loaded serial 5OK

Als u andere boodschappen tegenkomt, betekent dit dat u een probleem heeft met uw zonebestand. Meestal is de boodschap vrij beschrijvend over welk deel ongeldig is.

U kunt de reverse zone controleren door het in-addr.arpa adres en de bestandsnaam door te geven. Voor onze demonstratie zouden we dit typen:

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

Ook dit zou u een soortgelijke boodschap moeten geven over het laden van het juiste serienummer:

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

Als al uw bestanden uitchecken, kunt u uw Bind service herstarten:

sudo service bind9 restart

U zou de logs moeten controleren door te typen:

sudo tail -f /var/log/syslog

Houd dit log in de gaten om er zeker van te zijn dat er geen fouten zijn.

Configureer de Secundaire Bind Server

Nu we de primaire server geconfigureerd hebben, kunnen we verder gaan en de secundaire server opzetten. Dit zal beduidend eenvoudiger zijn dan de primaire server.

Configuratie van het Opties bestand

Ook hier zullen we beginnen met het named.conf.options bestand. Open het met sudo rechten in uw tekstverwerker:

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

We maken exact dezelfde wijzigingen in dit bestand als in het bestand van onze primaire server.

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

Bewaar en sluit het bestand als u klaar bent.

Configureren van het lokale configuratiebestand

Volgende, we zullen het named.conf.local bestand configureren op de secundaire server. Open het met sudo privileges in uw tekst editor:

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

Hier zullen we elk van onze zone specificaties maken zoals we deden op onze primaire server. Echter, de waarden en sommige parameters zullen verschillend zijn.

Eerst zullen we werken aan de forward zone. Begin op dezelfde manier als in het primaire bestand:

zone "example.com" {};

Deze keer gaan we de type op slave zetten, omdat deze server als secundair voor deze zone fungeert. Dit betekent simpelweg dat hij zijn zonebestanden ontvangt via transfer in plaats van een bestand op het lokale systeem. Bovendien gaan we gewoon de relatieve bestandsnaam opgeven in plaats van het absolute pad naar het zonebestand.

De reden hiervoor is dat, voor secundaire zones, Bind de bestanden /var/cache/bind opslaat. Bind is al geconfigureerd om in deze directory locatie te zoeken, dus we hoeven het pad niet op te geven.

Voor onze forward zone zullen deze details er als volgt uitzien:

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

Ten slotte zullen we, in plaats van de allow-transfer directief, de primaire servers opgeven, per IP adres, waarvan deze server zonetransfers zal accepteren. Dit wordt gedaan in een directief genaamd masters:

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

Dit voltooit onze forward zone specificatie. We kunnen precies hetzelfde formaat gebruiken voor onze reverse zone specificatie:

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

Wanneer u klaar bent, kunt u het bestand opslaan en sluiten.

De bestanden testen en de service herstarten

We hoeven eigenlijk geen zonebestanden op de secundaire machine aan te maken, omdat, zoals we eerder zeiden, deze server de zonebestanden van de primaire server zal ontvangen. Dus we zijn klaar om te testen.

Wederom, we moeten de configuratie bestand syntax controleren. Omdat we geen zone bestanden hebben om te controleren, hoeven we alleen maar het named-checkconf gereedschap te gebruiken:

sudo named-checkconf

Als dit terug komt zonder fouten, betekent dit dat de bestanden die je hebt gewijzigd geen syntax fouten hebben.

Als dit het geval is, kunt u uw Bind service opnieuw starten:

sudo service bind9 restart

Controleer de logs op zowel de primaire als de secundaire servers met:

sudo tail -f /var/log/syslog

U zou enkele regels moeten zien die aangeven dat de zonebestanden correct zijn overgezet.

Delegeer Autoriteit aan uw Naamservers

Uw autoritatieve-only naamservers zouden nu volledig moeten zijn geconfigureerd. U moet echter nog steeds de bevoegdheid voor uw domein aan uw nameservers delegeren.

Om dit te doen, moet u naar de website gaan waar u uw domeinnaam hebt gekocht. De interface en misschien de terminologie zal verschillend zijn, afhankelijk van de domeinnaam registrar die u hebt gebruikt.

In uw domein instellingen, kijk voor een optie die u toelaat om de nameservers die u wenst te gebruiken specificeren. Aangezien onze nameservers zich binnen ons domein bevinden, is dit een speciaal geval.

In plaats van de registrar eenvoudig bevoegdheden voor de zone te delegeren via het gebruik van NS-records, moet deze een glue record aanmaken. Een glue record is een A-record waarin de IP-adressen voor de nameservers worden gespecificeerd nadat is aangegeven aan welke nameservers de autoriteit wordt gedelegeerd.

Normaal gesproken vermeldt de delegatie alleen de nameservers die de autoriteit van het domein zullen afhandelen, maar wanneer de nameservers zich binnen het domein zelf bevinden, is een A-record nodig voor de nameservers in de bovenliggende zone. Als dit niet zou gebeuren, zouden DNS-resolvers in een lus vast komen te zitten omdat ze nooit het IP-adres van de nameservers van het domein zouden kunnen vinden om het delegatiepad te volgen.

Dus moet u een sectie van het configuratiescherm van uw domeinregistrar vinden waarmee u naamservers en hun IP-adressen kunt opgeven.

Als voorbeeld: de registrar Namecheap heeft twee verschillende naamserversecties.

Er is een sectie genaamd “Nameserver Registration” waarmee u de IP-adressen voor nameservers binnen uw domein kunt opgeven:

Binnenin kunt u de IP-adressen invoeren van de nameservers die binnen het domein bestaan:

Dit creëert de A-record die dienen als de glue records die u nodig hebt in het bovenliggende zonebestand.

Als u dit hebt gedaan, zou u de actieve naamservers moeten kunnen wijzigen in de servers van uw domein. In NameCheap gebeurt dit via de menuoptie “Domain Name Server Setup”:

Hier kunt u aangeven dat de door u toegevoegde nameservers als gezaghebbende servers voor uw site moeten worden gebruikt:

Het kan even duren voordat de wijzigingen zijn doorgevoerd, maar bij de meeste registrars zou u binnen 24-48 uur moeten zien dat de gegevens van uw nameservers worden gebruikt.

Conclusie

U zou nu twee authoritative-only DNS servers geconfigureerd moeten hebben om uw domeinen te serveren. Deze kunnen worden gebruikt om zone-informatie op te slaan voor extra domeinen als u er meer verwerft.

Het configureren en beheren van uw eigen DNS-servers geeft u de meeste controle over hoe de DNS-records worden afgehandeld. U kunt wijzigingen aanbrengen en er zeker van zijn dat alle relevante DNS-gegevens bij de bron up-to-date zijn. Hoewel andere DNS-oplossingen dit proces eenvoudiger kunnen maken, is het belangrijk te weten dat u opties hebt en te begrijpen wat er gebeurt in meer verpakte oplossingen.