Indledning

DNS, eller domænenavnsystemet, er ofte en vanskelig komponent at få styr på, når man skal lære at konfigurere websteder og servere. Mens de fleste mennesker sandsynligvis vil vælge at bruge de DNS-servere, der leveres af deres hostingfirma eller deres domæneregistrator, er der nogle fordele ved at oprette dine egne DNS-servere.

I denne vejledning vil vi diskutere, hvordan man installerer og konfigurerer Bind9 DNS-serveren som autoritative DNS-servere (authoritative-only DNS-servere) på Ubuntu 14.04-maskiner. Vi vil opsætte disse to Bind-servere til vores domæne i en primær-sekundær konfiguration.

Forudsætninger og mål

For at gennemføre denne vejledning skal du først være bekendt med nogle almindelige DNS-terminologier. Tjek denne vejledning for at lære om de koncepter, som vi vil implementere i denne vejledning.

Du skal også bruge mindst to servere. Den ene vil være til den “primære” DNS-server, hvor zonefilerne for vores domæne vil stamme fra, og den anden vil være den “sekundære” server, som vil modtage zonedataene via overførsler og være tilgængelig i tilfælde af, at den anden server går ned. På denne måde undgår du faren ved at have et enkelt fejlpunkt for dine DNS-servere.

I modsætning til caching- eller forwarding DNS-servere eller en DNS-server med flere formål svarer kun autoritative servere kun på iterative forespørgsler for de zoner, som de er autoritative for. Det betyder, at hvis serveren ikke kender svaret, vil den blot fortælle klienten (normalt en slags opløsende DNS-server), at den ikke kender svaret, og give en henvisning til en server, der måske ved mere.

Authoritative-only DNS-servere er ofte en god konfiguration for høj ydeevne, fordi de ikke har det overhead, der er forbundet med at løse rekursive forespørgsler fra klienter. De bekymrer sig kun om de zoner, som de er designet til at betjene.

I denne vejledning vil vi faktisk henvise til tre servere. De to navneservere, der er nævnt ovenfor, plus en webserver, som vi vil konfigurere som vært i vores zone.

Vi vil bruge dummy-domænet example.com i denne vejledning. Du bør erstatte det med det domæne, som du konfigurerer. Dette er detaljerne for de maskiner, vi vil konfigurere:

Formål	DNS FQDN	IP-adresse
Primær navneserver	ns1.example.com.	192.0.2.1
Sekundær navneserver	ns2.example.com.	192.0.2.2.2
Webserver	www.example.com.	192.0.2.3

Når du har gennemført denne vejledning, skal du have konfigureret to autoritative navneservere, der kun er autoritative, til dine domænezoner. Navnene i den midterste kolonne i tabellen ovenfor vil kunne bruges til at nå dine forskellige værter. Ved hjælp af denne konfiguration vil en rekursiv DNS-server kunne returnere data om domænet til klienterne.

Indstilling af værtsnavnet på navneserverne

Hvor vi går i gang med konfigurationen af vores navneservere, skal vi sikre, at vores værtsnavn er konfigureret korrekt på både vores primære og sekundære DNS-server.

Begynd med at undersøge /etc/hosts-filen. Åbn filen med sudo privilegier i din teksteditor:

sudo nano /etc/hosts

Vi skal konfigurere den, så den identificerer hver servers hostnavn og FQDN korrekt. For den primære navneserver vil filen i første omgang se nogenlunde sådan ud:

127.0.0.1 localhost127.0.1.1 ns1 ns1. . .

Vi skal ændre den anden linje til at henvise til vores specifikke værts- og domænekombination og pege denne til vores offentlige, statiske IP-adresse. Vi kan derefter tilføje det ukvalificerede navn som et alias til sidst. For den primære server i dette eksempel skal du ændre den anden linje til dette:

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

Spar og luk filen, når du er færdig.

Vi skal også ændre filen /etc/hostname, så den indeholder vores ukvalificerede værtsnavn:

sudo nano /etc/hostname

ns1

Vi kan læse denne værdi ind i det system, der kører i øjeblikket, ved at skrive:

sudo hostname -F /etc/hostname

Vi vil gennemføre den samme procedure på vores sekundære server.

Start med filen /etc/hosts:

sudo nano /etc/hosts

127.0.0.1 localhost192.0.2.2 ns2.example.com ns2

Spar og luk filen, når du er færdig.

Dernæst skal du ændre filen /etc/hostname. Husk kun at bruge den faktiske vært (bare ns2 i vores eksempel) til denne fil:

sudo nano /etc/hostname

ns2

Læs igen filen for at ændre det aktuelle system:

sudo hostname -F /etc/hostname

Dine servere skulle nu have deres værtsdefinitioner indstillet korrekt.

Installer Bind på begge navneservere

På hver af dine navneservere kan du nu installere Bind, den DNS-server, som vi skal bruge.

Bind-softwaren er tilgængelig i Ubuntus standardrepositorier, så vi skal bare opdatere vores lokale pakkeindeks og installere softwaren ved hjælp af apt. Vi vil også inkludere dokumentationen og nogle almindelige hjælpeprogrammer:

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

Kør denne installationskommando på din primære og sekundære DNS-server for at erhverve de relevante filer.

Konfigurer den primære Bind-server

Nu, hvor vi har installeret softwaren, kan vi begynde med at konfigurere vores DNS-server på den primære server.

Konfigurering af optionsfilen

Den første ting, vi skal konfigurere for at komme i gang, er named.conf.options-filen.

Bind DNS-serveren er også kendt som named. Hovedkonfigurationsfilen er placeret på /etc/bind/named.conf. Denne fil kalder på de andre filer, som vi rent faktisk skal konfigurere.

Åbn optionsfilen med sudo privilegier i din editor:

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

Nedenfor er de fleste kommenterede linjer blevet fjernet for at gøre det kortfattet, men generelt bør filen se sådan ud efter installationen:

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

Den vigtigste ting, som vi skal konfigurere i denne fil, er rekursion. Da vi forsøger at opsætte en server, der kun er autoritativ, ønsker vi ikke at aktivere rekursion på denne server. Vi kan slå dette fra i options-blokken.

Vi vil også som standard ikke tillade overførsler. Vi vil tilsidesætte dette i individuelle zonespecifikationer senere:

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 er færdig, skal du gemme og lukke filen.

Konfigurering af den lokale fil

Det næste skridt, vi skal tage, er at angive de zoner, som vi ønsker at kontrollere denne server. En zone er enhver del af domænet, der er uddelegeret til administration til en navneserver, som ikke er blevet subdelegeret til andre servere.

Vi konfigurerer example.com-domænet, og vi vil ikke subdelegere ansvaret for nogen del af domænet til andre servere. Så zonen vil dække hele vores domæne.

For at konfigurere vores zoner skal vi åbne filen /etc/bind/named.conf.local med sudo privilegier:

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

Denne fil vil i første omgang være tom udover kommentarer. Der er andre zoner, som vores server kender til generel administration, men disse er specificeret i named.conf.default-zones-filen.

For at starte skal vi konfigurere forward-zonen for vores example.com-domæne. Forward zone er den konventionelle navn-til-IP-opløsning, som de fleste af os tænker på, når vi taler om DNS. Vi opretter en konfigurationsblok, der definerer den domænezone, vi ønsker at konfigurere:

zone "example.com" {};

Note: Mange DNS-værktøjer, deres konfigurationsfiler og dokumentation bruger udtrykkene “master” og “slave”, mens DigitalOcean generelt foretrækker alternative deskriptorer. For at undgå forvirring har vi valgt at bruge udtrykkene “primær” og “sekundær” til at betegne relationer mellem servere og kun bruge “master” eller “slave”, når et konfigurationsdirektiv kræver det.

Inden for denne blok tilføjer vi forvaltningsoplysningerne om denne zone. Vi angiver denne DNS-serverens forhold til zonen. Dette er type master; i den følgende eksempelzone, da vi konfigurerer denne maskine som den primære navneserver for alle vores zoner. Vi peger også Bind til den fil, der indeholder de faktiske ressourceposter, som definerer zonen.

Vi vil opbevare vores primære zonefiler i en undermappe kaldet zones i Bind-konfigurationsmappen. Vi kalder vores fil db.example.com for at låne konventionen fra de andre zonefiler i Bind-mappen. Vores blok vil se således ud nu:

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

Vi ønsker at tillade, at denne zone overføres til vores sekundære server, vi skal tilføje en linje som denne:

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

Næst skal vi definere den omvendte zone for vores domæne.

En smule om omvendte zoner

Hvis den organisation, der gav dig dine IP-adresser, ikke gav dig et netværksområde og uddelegerede ansvaret for dette område til dig, vil der ikke blive henvist til din omvendte zonefil, og den vil blive håndteret af organisationen selv.

Med hostingudbydere bliver den omvendte kortlægning normalt varetaget af virksomheden selv. Med DigitalOcean vil reverse mappings for dine servere f.eks. automatisk blive oprettet, hvis du bruger maskinens FQDN som servernavn i kontrolpanelet. For eksempel kunne reverse mappings for denne vejledning oprettes ved at navngive serverne på denne måde:

I tilfælde som disse, da du ikke har fået tildelt en klump af adresser at administrere, bør du bruge denne strategi. Den strategi, der er skitseret nedenfor, er dækket for fuldstændighedens skyld og for at gøre den anvendelig, hvis du har fået uddelegeret kontrol over større grupper af sammenhængende adresser.

Reversezoner bruges til at forbinde en IP-adresse tilbage til et domænenavn. Domænenavnesystemet blev dog oprindeligt designet til fremadrettede mappinger, så der skal tænkes lidt over at tilpasse det, så det også kan bruges til omvendte mappinger.

De oplysninger, som du skal huske på for at forstå omvendte mappinger, er:

• I et domæne er den mest specifikke del af adressen til venstre. For en IP-adresse er den mest specifikke del til højre.
• Den mest specifikke del af en domænespecifikation er enten et subdomæne eller et værtsnavn. Dette defineres i zonefilen for domænet.
• Hvert underdomæne kan igen definere flere underdomæner eller værtsnavne.

Alle omvendte zonetilknytninger defineres under det særlige domæne in-addr.arpa, som kontrolleres af Internet Assigned Numbers Authority (IANA). Under dette domæne findes der et træ, der bruger underdomæner til at kortlægge hvert af okteterne i en IP-adresse. For at sikre, at IP-adressernes specificitet afspejler IP-adressernes specificitet i forhold til normale domæner, er oktetterne i IP-adresserne faktisk omvendt.

Så vores primære DNS-server med en IP-adresse på 192.0.2.1 ville blive omvendt, så den ville blive læst som 1.2.0.192. Når vi tilføjer denne værtsspecifikation som et hierarki, der findes under in-addr.arpa-domænet, kan der henvises til den specifikke vært som 1.2.0.192.in-addr.arpa.

Da vi definerer individuelle værter (som det ledende “1” her) i selve zonefilen, når vi bruger DNS, ville den zone, vi ville konfigurere, være 2.0.192.in-addr.arpa. Hvis vores netværksudbyder har givet os en /24-blok af adresser, f.eks. 192.0.2.0/24, ville de have delegeret denne in-addr.arpa-del til os.

Nu hvor du ved, hvordan du angiver det omvendte zonenavn, er den faktiske definition nøjagtig den samme som forwardszonen. Under example.com-zonedefinitionen skal du lave en omvendt zone for det netværk, du har fået tildelt. Igen er dette sandsynligvis kun nødvendigt, hvis du har fået uddelegeret kontrol over en blok af adresser:

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

Vi har valgt at navngive filen db.192.0.2. Det er specifikt om, hvad zonen konfigurerer, og det er mere læsbart end den omvendte notation.

Spar og luk filen, når du er færdig.

Skab filen for den fremadrettede zone

Vi har nu fortalt Bind om vores fremadrettede og omvendte zoner, men vi har endnu ikke oprettet de filer, der skal definere disse zoner.

Hvis du husker det, angav vi filplaceringerne som værende inden for en undermappe kaldet zones. Vi skal oprette denne mappe:

sudo mkdir /etc/bind/zones

Nu kan vi bruge nogle af de allerede eksisterende zonefiler i mappen Bind som skabeloner for de zonefiler, vi ønsker at oprette. For den fremadrettede zone vil filen db.local være tæt på det, vi har brug for. Kopier den fil til undermappen zones med det navn, der bruges i filen named.conf.local.

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

Mens vi gør dette, kan vi også kopiere en skabelon for den omvendte zone. Vi vil bruge filen db.127, da den passer tæt på det, vi har brug for:

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

Åbn nu filen for den fremadrettede zone med sudo privilegier i din teksteditor:

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

Filen vil se således ud:

$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ørste ting, vi skal have lyst til at gøre, er at ændre SOA (start of authority) posten, der starter med det første @ symbol og fortsætter indtil den afsluttende parentes.

Vi skal erstatte localhost. med navnet på FQDN’et for denne maskine. Denne del af posten bruges til at definere enhver navneserver, der vil svare autoritativt for den zone, der defineres. Dette vil være den maskine, vi konfigurerer nu, ns1.example.com. i vores tilfælde (bemærk det afsluttende punktum. Dette er vigtigt for, at vores post kan registreres korrekt!).

Vi ønsker også at ændre den næste del, som faktisk er en specielt formateret e-mail-adresse med @ erstattet af et punktum. Vi ønsker, at vores e-mails skal gå til en administrator af domænet, så den traditionelle e-mail er [email protected]. Vi ville oversætte dette, så det ser ud som admin.example.com.:

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

Den næste del, som vi skal redigere, er serienummeret. Værdien af serienummeret er den måde, hvorpå Bind fortæller, om den skal sende opdaterede oplysninger til den sekundære server.

Bemærk: At undlade at øge serienummeret er en af de mest almindelige fejl, der fører til problemer med zoneopdateringer. Hver gang du foretager en redigering, skal du forhøje serienummeret.

En almindelig praksis er at bruge en konvention til at forhøje nummeret. En fremgangsmåde er at bruge datoen i formatet ÅÅÅÅÅMMDD sammen med et revisionsnummer for den dag, der er tilføjet til sidst. Så den første revision foretaget den 05. juni 2014 kunne have et løbenummer 2014060501, og en opdatering foretaget senere samme dag kunne have et løbenummer 2014060502. Værdien kan være et 10-cifret tal.

Det er værd at vedtage en konvention for at lette brugen, men for at holde tingene enkle i vores demonstration, sætter vi bare vores til 5 for nu:

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

Næst kan vi slippe af med de sidste tre linjer i filen (dem nederst, der starter med @), da vi vil lave vores egne.

Den første ting, vi ønsker at oprette efter SOA-rekordet, er navneserverne for vores zone. Vi angiver domænet og derefter vores to navneservere, der er autoritative for zonen, ved navn. Da disse navneservere vil være værter inden for selve domænet, vil det se en smule selvrefererende ud.

For vores guide vil det se således ud. Igen skal du være opmærksom på de afsluttende prikker!:

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

Da formålet med en zonefil primært er at mappe værtsnavne og tjenester til specifikke adresser, er vi ikke færdige endnu. Enhver software, der læser denne zonefil, vil gerne vide, hvor ns1– og ns2-serverne befinder sig for at få adgang til de autoritative zoner.

Så det næste er, at vi skal oprette A-posterne, der vil knytte disse navneservernavne til de faktiske IP-adresser på vores navneservere:

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

Nu har vi A-posterne til at opløse vores navneservere til deres korrekte IP-adresser, og vi kan tilføje yderligere poster. Husk, at vi har en webserver på en af vores hosts, som vi ønsker at bruge til at betjene vores websted. Vi vil pege anmodninger for det generelle domæne (example.com i vores tilfælde) til denne vært samt anmodninger for www-værten. Det vil se således ud:

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

Du kan tilføje yderligere værter, som du har brug for at definere, ved at oprette yderligere A-poster. Henvis til vores vejledning om grundlæggende DNS for at blive fortrolig med nogle af dine muligheder med at oprette yderligere poster.

Når du er færdig, skal din fil se nogenlunde sådan ud:

$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

Spar og luk filen, når du er færdig.

Opret filen med den omvendte zone

Nu har vi konfigureret den fremadrettede zone, men vi skal konfigurere filen med den omvendte zone, som vi har angivet i vores konfigurationsfil. Vi oprettede allerede filen i begyndelsen af sidste afsnit.

Åbn filen i din teksteditor med sudo privilegier:

sudo nano db.192.0.2

Filen skal se således ud:

$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 vil gennemgå meget af den samme procedure som for den fremadrettede zone. Først skal du justere domænenavnet, admin-e-mailen og serienummeret, så det passer nøjagtigt til det, du havde i den sidste fil (serienummeret kan være forskelligt, men det skal være inkrementeret):

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

Tilbage skal du slette linjerne under den lukkende parentes i SOA-rekordet. Vi vil tage den sidste oktet af hver IP-adresse i vores netværksområde og mappe den tilbage til den pågældende værts FQDN ved hjælp af en PTR-record. Hver IP-adresse bør kun have en enkelt PTR-record for at undgå problemer i visse programmer, så du skal vælge det værtsnavn, du ønsker at reverse mappe til.

Hvis du f.eks. har oprettet en mailserver, vil du sandsynligvis oprette reverse mapping til mail-navnet, da mange systemer bruger reverse mapping til at validere adresser.

Først skal vi indstille vores navneservere igen:

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

Næst skal du bruge den sidste oktet i den IP-adresse, du henviser til, og pege den tilbage til det fuldt kvalificerede domænenavn, som du vil vende tilbage med. I vores eksempel vil vi bruge dette:

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

Når du er færdig, skal filen se nogenlunde sådan ud:

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

Spar og luk filen, når du er færdig.

Test af filerne og genstart af tjenesten

Konfigurationen af den primære server er nu færdig, men vi skal stadig implementere vores ændringer.

Hvor vi genstarter vores tjeneste, skal vi teste alle vores konfigurationsfiler for at sikre, at de er konfigureret korrekt. Vi har nogle værktøjer, der kan kontrollere syntaksen i hver af vores filer.

Først kan vi kontrollere named.conf.local– og named.conf.options-filerne ved hjælp af named-checkconf-kommandoen. Da begge disse filer er source af skeletfilen named.conf, vil den teste syntaksen for de filer, vi har ændret.

sudo named-checkconf

Hvis denne returnerer uden nogen meddelelser, betyder det, at named.conf.local– og named.conf.options-filerne er syntaktisk gyldige.

Næst kan du kontrollere dine individuelle zonefiler ved at sende det domæne, som zonen håndterer, og zonefilens placering til kommandoen named-checkzone. Så i vores guide kan du kontrollere den fremadrettede zonefil ved at skrive:

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

Hvis din fil ikke har nogen problemer, bør den fortælle dig, at den har indlæst det korrekte serienummer og give meddelelsen “OK”;

zone example.com/IN: loaded serial 5OK

Hvis du løber ind i andre meddelelser, betyder det, at du har et problem med din zonefil. Normalt er meddelelsen ret beskrivende om, hvilken del der er ugyldig.

Du kan tjekke den omvendte zone ved at overgive in-addr.arpa-adressen og filnavnet. I vores demonstration ville vi skrive dette:

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

Dette skulle give dig en lignende meddelelse om indlæsning af det korrekte serienummer:

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

Hvis alle dine filer tjekker ud, kan du genstarte din Bind-tjeneste:

sudo service bind9 restart

Du bør tjekke logfilerne ved at skrive:

sudo tail -f /var/log/syslog

Hold øje med denne log for at sikre dig, at der ikke er nogen fejl.

Konfigurer den sekundære bindingsserver

Nu da vi har konfigureret den primære server, kan vi gå videre og få konfigureret den sekundære server. Dette vil være betydeligt nemmere end den primære server.

Konfigurering af optionsfilen

Også her starter vi med filen named.conf.options. Åbn den med sudo privilegier i din teksteditor:

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

Vi vil foretage nøjagtig de samme ændringer i denne fil, som vi foretog i vores primære servers fil.

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

Spar og luk filen, når du er færdig.

Konfigurering af den lokale konfigurationsfil

Næst vil vi konfigurere named.conf.local filen på den sekundære server. Åbn den med sudo-privilegier i din teksteditor:

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

Her opretter vi hver af vores zonespecifikationer, ligesom vi gjorde på vores primære server. Værdierne og nogle af parametrene vil dog være forskellige.

Først vil vi arbejde på forward-zonen. Start den på samme måde, som du gjorde i den primære fil:

zone "example.com" {};

Denne gang sætter vi type til slave, da denne server fungerer som sekundær for denne zone. Det betyder blot, at den modtager sine zonefiler via overførsel i stedet for en fil på det lokale system. Derudover vil vi blot angive det relative filnavn i stedet for den absolutte sti til zonefilen.

Grunden til dette er, at Bind for sekundære zoner gemmer filerne /var/cache/bind. Bind er allerede konfigureret til at søge i denne mappeplacering, så vi behøver ikke at angive stien.

For vores forward-zone vil disse detaljer se således ud:

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

Sluttelig vil vi i stedet for allow-transfer-direktivet angive de primære servere, ved IP-adresse, som denne server vil acceptere zoneoverførsler fra. Dette gøres i et direktiv kaldet masters:

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

Dette afslutter vores forward-zonespecifikation. Vi kan bruge nøjagtig det samme format til at tage os af vores specifikation af den omvendte zone:

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

Når du er færdig, kan du gemme og lukke filen.

Test af filerne og genstart af tjenesten

Vi behøver faktisk ikke at foretage nogen af de faktiske oprettelser af zonefilerne på den sekundære maskine, fordi denne server, som vi nævnte før, vil modtage zonefilerne fra den primære server. Så vi er klar til at teste.

Vi bør igen kontrollere syntaksen i konfigurationsfilen. Da vi ikke har nogen zonefiler at kontrollere, behøver vi kun at bruge værktøjet named-checkconf:

sudo named-checkconf

Hvis dette returnerer uden fejl, betyder det, at de filer, du har ændret, ikke har syntaksfejl.

Hvis dette er tilfældet, kan du genstarte din Bind-tjeneste:

sudo service bind9 restart

Kontroller logfilerne på både den primære og den sekundære server ved hjælp af:

sudo tail -f /var/log/syslog

Du bør se nogle poster, der indikerer, at zonefilerne er blevet overført korrekt.

Delegér autoritet til dine navneservere

Dine autoritative navneservere bør nu være fuldstændig konfigureret. Du skal dog stadig uddelegere autoritet for dit domæne til dine navneservere.

For at gøre dette skal du gå til det websted, hvor du har købt dit domænenavn. Grænsefladen og måske terminologien vil være forskellig afhængigt af den domænenavnsregistrant, du har brugt.

I dine domæneindstillinger skal du lede efter en indstilling, der giver dig mulighed for at angive de navneservere, du ønsker at bruge. Da vores navneservere befinder sig inden for vores domæne, er dette et særligt tilfælde.

I stedet for at registratoren blot uddelegerer autoritet for zonen ved hjælp af NS-poster, skal den oprette en glue-post. En glue record er en A-post, der angiver IP-adresserne for navneserverne, efter at den har angivet de navneservere, som den delegerer autoritet til.

Sædvanligvis angiver delegationen kun de navneservere, der skal håndtere autoriteten for domænet, men når navneserverne befinder sig inden for selve domænet, er der behov for en A-post for navneserverne i den overordnede zone. Hvis dette ikke skete, ville DNS-resolvere sidde fast i en løkke, fordi den aldrig ville kunne finde IP-adressen på domænets navneservere for at følge delegeringsstien.

Så du skal finde et afsnit i din domæneregistrators kontrolpanel, hvor du kan angive navneservere og deres IP-adresser.

Som demonstration har registratoren Namecheap to forskellige navneserverafsnit.

Der er en sektion kaldet “Nameserver Registration”, der giver dig mulighed for at angive IP-adresserne for navneservere inden for dit domæne:

Indvendigt vil du kunne indtaste IP-adresserne for de navneservere, der findes inden for domænet:

Dette vil oprette A-posten, der der fungerer som de limeposter, som du har brug for i den overordnede zonefil.

Når du har gjort dette, bør du være i stand til at ændre de aktive navneservere til dit domænes servere. I NameCheap gøres dette ved hjælp af menupunktet “Domain Name Server Setup”:

Her kan du fortælle den, at den skal bruge de navneservere, du har tilføjet, som de autoritative servere for dit websted:

Den kan tage et stykke tid at sprede ændringerne, men du bør se dataene fra dine navneservere blive brugt inden for de næste 24-48 timer for de fleste registratorer.

Konklusion

Du bør nu have to autoritative DNS-servere, der kun er konfigureret til at servere dine domæner. Disse kan bruges til at gemme zoneoplysninger for yderligere domæner, efterhånden som du erhverver flere.

Konfigurering og administration af dine egne DNS-servere giver dig den største kontrol over, hvordan DNS-posterne håndteres. Du kan foretage ændringer og være sikker på, at alle relevante dele af DNS-dataene er opdaterede ved kilden. Selv om andre DNS-løsninger kan gøre denne proces lettere, er det vigtigt at vide, at du har muligheder, og at du forstår, hvad der sker i de mere pakkede løsninger.