Introducere

Sistemul DNS, sau Sistemul de nume de domeniu, este adesea o componentă dificil de înțeles atunci când învățați cum să configurați site-uri web și servere. În timp ce majoritatea oamenilor vor alege probabil să folosească serverele DNS furnizate de compania de găzduire sau de registratorul de domenii, există unele avantaje în crearea propriilor servere DNS.

În acest ghid, vom discuta despre cum să instalăm și să configurăm serverul DNS Bind9 ca servere DNS autoritative-only pe mașinile Ubuntu 14.04. Vom configura aceste două servere Bind pentru domeniul nostru într-o configurație primară-secundară.

Precondiții și obiective

Pentru a finaliza acest ghid, va trebui mai întâi să fiți familiarizați cu o anumită terminologie DNS comună. Consultați acest ghid pentru a învăța despre conceptele pe care le vom implementa în acest ghid.

De asemenea, veți avea nevoie de cel puțin două servere. Unul va fi pentru serverul DNS „primar” de unde vor proveni fișierele de zonă pentru domeniul nostru și unul va fi serverul „secundar” care va primi datele de zonă prin transferuri și va fi disponibil în cazul în care celălalt server cade. În acest fel se evită pericolul de a avea un singur punct de defecțiune pentru serverele DNS.

Spre deosebire de serverele DNS de tip caching sau de redirecționare sau de un server DNS multifuncțional, serverele „authoritative-only” răspund numai la interogări iterative pentru zonele pentru care sunt autoritare. Acest lucru înseamnă că, dacă serverul nu știe răspunsul, va spune pur și simplu clientului (de obicei, un anumit tip de server DNS de rezolvare) că nu știe răspunsul și va da o referință la un server care ar putea ști mai multe.

Serverele DNS numai cu autoritate sunt adesea o configurație bună pentru performanțe ridicate, deoarece nu au sarcina de a rezolva interogări recursive din partea clienților. Ele se preocupă doar de zonele pe care sunt proiectate să le deservească.

În scopul acestui ghid, vom face de fapt referire la trei servere. Cele două servere de nume menționate mai sus, plus un server web pe care dorim să îl configurăm ca gazdă în cadrul zonei noastre.

Pentru acest ghid vom folosi domeniul fictiv example.com. Ar trebui să îl înlocuiți cu domeniul pe care îl configurați. Acestea sunt detaliile mașinilor pe care le vom configura:

Scop	DNS FQDN	Adresa IP
Server de nume primar	ns1.exemplu.com.	192.0.2.1
Server de nume secundar	ns2.example.com.	192.0.2.2
Server web	www.example.com.	192.0.2.3

După ce ați finalizat acest ghid, ar trebui să aveți configurate două servere de nume cu autoritate exclusivă pentru zonele domeniului dumneavoastră. Numele din coloana centrală a tabelului de mai sus vor putea fi utilizate pentru a ajunge la diversele dvs. gazde. Folosind această configurație, un server DNS recursiv va fi capabil să returneze clienților date despre domeniu.

Stabilirea numelui de gazdă pe serverele de nume

Înainte de a intra în configurarea serverelor noastre de nume, trebuie să ne asigurăm că numele de gazdă este configurat corect atât pe serverul nostru DNS principal, cât și pe cel secundar.

Începeți prin investigarea fișierului /etc/hosts. Deschideți fișierul cu privilegii sudo în editorul dvs. de text:

sudo nano /etc/hosts

Trebuie să configurăm acest fișier astfel încât să identifice corect numele de gazdă și FQDN-ul fiecărui server. Pentru serverul de nume primar, fișierul va arăta inițial cam așa:

127.0.0.1 localhost127.0.1.1 ns1 ns1. . .

Ar trebui să modificăm a doua linie pentru a face referire la combinația noastră specifică de gazdă și domeniu și să o direcționăm către adresa noastră IP publică, statică. Putem adăuga apoi numele necalificat ca alias la sfârșit. Pentru serverul principal din acest exemplu, ar trebui să modificați a doua linie astfel:

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

Salvați și închideți fișierul când ați terminat.

De asemenea, ar trebui să modificăm fișierul /etc/hostname pentru a conține numele nostru de gazdă necalificat:

sudo nano /etc/hostname

ns1

Puteți citi această valoare în sistemul care rulează în prezent, tastând apoi:

sudo hostname -F /etc/hostname

Vrem să completăm aceeași procedură pe serverul nostru secundar.

Începeți cu fișierul /etc/hosts:

sudo nano /etc/hosts

127.0.0.1 localhost192.0.2.2 ns2.example.com ns2

Salvați și închideți fișierul când ați terminat.

Apoi, modificați fișierul /etc/hostname. Nu uitați să folosiți doar gazda reală (doar ns2 în exemplul nostru) pentru acest fișier:

sudo nano /etc/hostname

ns2

Citește din nou fișierul pentru a modifica sistemul actual:

sudo hostname -F /etc/hostname

Serverele tale ar trebui să aibă acum definițiile de gazdă setate corect.

Instalați Bind pe ambele servere de nume

Pe fiecare dintre serverele dvs. de nume, puteți instala acum Bind, serverul DNS pe care îl vom folosi.

Software-ul Bind este disponibil în cadrul depozitelor implicite ale Ubuntu, așa că trebuie doar să actualizăm indexul nostru local de pachete și să instalăm software-ul folosind apt. Vom include, de asemenea, documentația și câteva utilități comune:

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

Executați această comandă de instalare pe serverele DNS primare și secundare pentru a achiziționa fișierele corespunzătoare.

Configurarea serverului Bind primar

Acum că avem software-ul instalat, putem începe prin configurarea serverului nostru DNS pe serverul primar.

Configurarea fișierului de opțiuni

Primul lucru pe care îl vom configura pentru a începe este fișierul named.conf.options.

Serverul DNS Bind este cunoscut și sub numele de named. Fișierul principal de configurare se află la /etc/bind/named.conf. Acest fișier apelează la celelalte fișiere pe care le vom configura de fapt.

Deschideți fișierul de opțiuni cu privilegii sudo în editorul dumneavoastră:

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

Mai jos, majoritatea liniilor comentate au fost eliminate pentru concizie, dar în general fișierul ar trebui să arate așa după instalare:

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

Principalul lucru pe care trebuie să-l configurăm în acest fișier este recursivitatea. Având în vedere că încercăm să configurăm un server exclusiv autoritar, nu dorim să activăm recursivitatea pe acest server. Putem dezactiva acest lucru în cadrul blocului options.

De asemenea, vom opta pentru a nu permite transferurile. Vom suprascrie acest lucru în specificațiile zonelor individuale mai târziu:

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

Când ați terminat, salvați și închideți fișierul.

Configurarea fișierului local

Postul următor pe care trebuie să îl facem este să specificăm zonele pe care dorim să le controlăm pe acest server. O zonă este orice porțiune a domeniului care este delegată pentru administrare unui server de nume și care nu a fost subdelegată altor servere.

Configurăm domeniul example.com și nu vom subdetașa responsabilitatea pentru nici o porțiune a domeniului altor servere. Astfel, zona va acoperi întregul nostru domeniu.

Pentru a configura zonele noastre, trebuie să deschidem fișierul /etc/bind/named.conf.local cu privilegii sudo:

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

Acest fișier va fi inițial gol în afară de comentarii. Există și alte zone pe care serverul nostru le cunoaște pentru gestionarea generală, dar acestea sunt specificate în fișierul named.conf.default-zones.

Pentru început, trebuie să configurăm zona de redirecționare pentru domeniul nostru example.com. Forward zone reprezintă rezoluția convențională de la nume la IP la care cei mai mulți dintre noi se gândesc atunci când discutăm despre DNS. Creăm un bloc de configurare care definește zona de domeniu pe care dorim să o configurăm:

zone "example.com" {};

Nota: Multe instrumente DNS, fișierele lor de configurare și documentația utilizează termenii „master” și „slave”, în timp ce DigitalOcean preferă, în general, descriptori alternativi. Pentru a evita confuzia, am ales să folosim termenii „primar” și „secundar” pentru a denota relațiile dintre servere și să folosim „master” sau „slave” doar atunci când o directivă de configurare o cere.

În interiorul acestui bloc, adăugăm informațiile de management despre această zonă. Specificăm relația acestui server DNS cu zona. Aceasta este type master; în zona de exemplu care urmează, deoarece configurăm această mașină ca server de nume primar pentru toate zonele noastre. De asemenea, direcționăm Bind către fișierul care conține înregistrările de resurse reale care definesc zona.

Vom păstra fișierele noastre de zonă primară într-un subdirectoriu numit zones în cadrul directorului de configurare Bind. Vom numi fișierul nostru db.example.com pentru a împrumuta convenția de la celelalte fișiere de zonă din directorul Bind. Blocul nostru va arăta astfel acum:

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

Vrem să permitem ca această zonă să fie transferată către serverul nostru secundar, trebuie să adăugăm o linie ca aceasta:

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

În continuare, vom defini zona inversă pentru domeniul nostru.

Un pic despre zonele inverse

Dacă organizația care v-a dat adresele IP nu v-a dat un interval de rețea și nu v-a delegat responsabilitatea pentru acel interval, atunci fișierul dvs. de zonă inversă nu va fi menționat și va fi gestionat chiar de organizație.

În cazul furnizorilor de găzduire, cartografierea inversă este, de obicei, gestionată chiar de companie. De exemplu, cu DigitalOcean, maparele inverse pentru serverele dvs. vor fi create automat dacă folosiți FQDN-ul mașinii ca nume de server în panoul de control. De exemplu, corespondențele inverse pentru acest tutorial ar putea fi create prin numirea serverelor astfel:

În astfel de cazuri, deoarece nu vi s-a alocat o bucată de adrese de administrat, ar trebui să folosiți această strategie. Strategia prezentată mai jos este acoperită pentru a fi completă și pentru a o face aplicabilă în cazul în care vi s-a delegat controlul asupra unor grupuri mai mari de adrese contigue.

Zonele inverse sunt utilizate pentru a conecta o adresă IP înapoi la un nume de domeniu. Cu toate acestea, sistemul de nume de domenii a fost proiectat inițial pentru corespondențele directe, așa că este nevoie de o anumită gândire pentru a adapta acest lucru pentru a permite corespondențele inverse.

Piețele de informații pe care trebuie să le aveți în vedere pentru a înțelege corespondențele inverse sunt:

• Într-un domeniu, cea mai specifică porțiune este a adresei este în stânga. Pentru o adresă IP, porțiunea cea mai specifică este în dreapta.
• Partea cea mai specifică a unei specificații de domeniu este fie un subdomeniu, fie un nume de gazdă. Aceasta este definită în fișierul de zonă pentru domeniu.
• Care subdomeniu poate, la rândul său, să definească mai multe subdomenii sau gazde.

Toate corespondențele de zonă inversă sunt definite sub domeniul special in-addr.arpa, care este controlat de Internet Assigned Numbers Authority (IANA). În cadrul acestui domeniu, există un arbore care utilizează subdomenii pentru a cartografia fiecare octet dintr-o adresă IP. Pentru a se asigura că specificitatea adreselor IP o oglindește pe cea a domeniilor normale, octeții adreselor IP sunt de fapt inversați.

Așa că serverul nostru DNS principal, cu o adresă IP de 192.0.2.1, ar fi inversat pentru a fi citit ca 1.2.0.192. Când adăugăm această specificație a gazdei ca o ierarhie existentă sub domeniul in-addr.arpa, gazda specifică poate fi menționată ca 1.2.0.192.in-addr.arpa.

Din moment ce definim gazdele individuale (cum ar fi „1” din față aici) în cadrul fișierului de zonă în sine atunci când folosim DNS, zona pe care am configura-o ar fi 2.0.192.in-addr.arpa. Dacă furnizorul nostru de rețea ne-a dat un bloc de adrese /24, să zicem 192.0.2.0/24, acesta ne-ar fi delegat această porțiune in-addr.arpa.

Acum că știți cum să specificați numele zonei inverse, definiția efectivă este exact aceeași ca și în cazul zonei directe. Sub definiția zonei example.com, faceți o zonă inversă pentru rețeaua care v-a fost dată. Din nou, acest lucru este probabil necesar doar dacă vi s-a delegat controlul asupra unui bloc de adrese:

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

Am ales să numim fișierul db.192.0.2. Acest lucru este specific cu privire la ceea ce configurează zona și este mai ușor de citit decât notația inversă.

Salvați și închideți fișierul atunci când ați terminat.

Crearea fișierului zonei de înaintare

Am spus acum lui Bind despre zonele noastre de înaintare și de întoarcere, dar nu am creat încă fișierele care vor defini aceste zone.

Dacă vă amintiți, am specificat locațiile fișierelor ca fiind în cadrul unui subdirectoriu numit zones. Trebuie să creăm acest director:

sudo mkdir /etc/bind/zones

Acum, putem folosi unele dintre fișierele de zonă preexistente din directorul Bind ca șabloane pentru fișierele de zonă pe care dorim să le creăm. Pentru zona forward, fișierul db.local va fi aproape de ceea ce avem nevoie. Copiați acest fișier în subdirectorul zones cu numele folosit în fișierul named.conf.local.

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

În timp ce facem acest lucru, putem copia un șablon și pentru zona inversă. Vom folosi fișierul db.127, deoarece este o potrivire apropiată pentru ceea ce avem nevoie:

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

Acum, deschideți fișierul zonei forward cu privilegii sudo în editorul de text:

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

Fileul va arăta astfel:

$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

Primul lucru pe care dorim să-l facem este să modificăm înregistrarea SOA (start of authority) care începe cu primul simbol @ și continuă până la paranteza de închidere.

Trebuie să înlocuim localhost. cu numele FQDN al acestei mașini. Această porțiune a înregistrării este utilizată pentru a defini orice server de nume care va răspunde cu autoritate pentru zona care se definește. Aceasta va fi mașina pe care o configurăm acum, ns1.example.com. în cazul nostru (observați punctul final. Acesta este important pentru ca intrarea noastră să se înregistreze corect!).

Vrem, de asemenea, să modificăm următoarea piesă, care este de fapt o adresă de e-mail formatată special, cu @ înlocuit cu un punct. Vrem ca emailurile noastre să ajungă la un administrator al domeniului, așa că emailul tradițional este [email protected]. Am traduce acest lucru astfel încât să arate ca admin.example.com.:

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

Următoarea piesă pe care trebuie să o modificăm este numărul de serie. Valoarea numărului de serie este modul în care Bind spune dacă trebuie să trimită informații actualizate către serverul secundar.

Nota: Faptul că nu reușește să incrementeze numărul de serie este una dintre cele mai frecvente greșeli care duce la probleme cu actualizările de zonă. De fiecare dată când faceți o editare, trebuie să incrementați numărul de serie.

O practică obișnuită este de a folosi o convenție pentru incrementarea numărului. O abordare este să folosiți data în formatul AAAALLORMDD împreună cu un număr de revizuire pentru ziua adăugată la sfârșit. Astfel, prima revizuire efectuată la 05 iunie 2014 ar putea avea numărul de serie 2014060501, iar o actualizare efectuată mai târziu în aceeași zi ar putea avea numărul de serie 2014060502. Valoarea poate fi un număr de 10 cifre.

Merită să adoptăm o convenție pentru ușurința utilizării, dar pentru a păstra lucrurile simple pentru demonstrația noastră, deocamdată o vom seta pe a noastră la 5:

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

În continuare, putem să scăpăm de ultimele trei linii din fișier (cele din partea de jos care încep cu @), deoarece ne vom face propriile linii.

Primul lucru pe care dorim să îl stabilim după înregistrarea SOA sunt serverele de nume pentru zona noastră. Specificăm domeniul și apoi cele două servere de nume care sunt autoritare pentru zonă, după nume. Deoarece aceste servere de nume vor fi gazde în cadrul domeniului însuși, va părea un pic autoreferențial.

Pentru ghidul nostru, va arăta în felul următor. Din nou, fiți atenți la punctele finale!:

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

Din moment ce scopul unui fișier de zonă este în principal acela de a cartografia numele de gazdă și serviciile la adrese specifice, nu am terminat încă. Orice software care citește acest fișier de zonă va dori să știe unde se află serverele ns1 și ns2 pentru a accesa zonele autoritare.

Deci, în continuare, trebuie să creăm înregistrările A care vor asocia aceste nume de servere de nume cu adresele IP reale ale serverelor noastre de nume:

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

Acum că avem înregistrările A pentru a rezolva cu succes serverele noastre de nume la adresele lor IP corecte, putem adăuga înregistrări suplimentare. Nu uitați că avem un server web pe una dintre gazdele noastre pe care dorim să îl folosim pentru a ne servi site-ul. Vom direcționa cererile pentru domeniul general (example.com în cazul nostru) către această gazdă, precum și cererile pentru gazda www. Va arăta astfel:

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

Puteți adăuga orice gazde suplimentare pe care trebuie să le definiți prin crearea de înregistrări A suplimentare. Consultați ghidul nostru de bază DNS pentru a vă familiariza cu unele dintre opțiunile dvs. de creare a înregistrărilor suplimentare.

Când ați terminat, fișierul dvs. ar trebui să arate cam așa:

$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

Salvați și închideți fișierul când ați terminat.

Crearea fișierului de zonă inversă

Acum, avem zona directă configurată, dar trebuie să configurăm fișierul de zonă inversă pe care l-am specificat în fișierul nostru de configurare. Am creat deja fișierul la începutul ultimei secțiuni.

Deschideți fișierul în editorul de text cu privilegii sudo:

sudo nano db.192.0.2

Fileul ar trebui să arate astfel:

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

Vom parcurge o mare parte din aceeași procedură ca și în cazul zonei înainte. În primul rând, ajustați numele domeniului, adresa de e-mail a administratorului și numărul de serie pentru a se potrivi exact cu ceea ce ați avut în ultimul fișier (Numărul de serie poate fi diferit, dar trebuie să fie incrementat):

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

Încă o dată, ștergeți liniile de sub paranteza de închidere a înregistrării SOA. Vom lua ultimul octet al fiecărei adrese IP din intervalul nostru de rețea și îl vom majora înapoi la FQDN-ul acelei gazde folosind o înregistrare PTR. Fiecare adresă IP ar trebui să aibă doar o singură înregistrare PTR pentru a evita probleme în unele programe, așa că trebuie să alegeți numele gazdei la care doriți să faceți mapare inversă.

De exemplu, dacă aveți configurat un server de poștă electronică, probabil că doriți să configurați mapare inversă la numele de poștă electronică, deoarece multe sisteme folosesc mapare inversă pentru a valida adresele.

În primul rând, trebuie să ne setăm din nou serverele de nume:

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

În continuare, veți folosi ultimul octet al adresei IP la care vă referiți și îl veți îndrepta înapoi către numele de domeniu complet calificat cu care doriți să vă întoarceți. Pentru exemplul nostru, vom folosi acest lucru:

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

Când ați terminat, fișierul ar trebui să arate cam așa:

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

Salvați și închideți fișierul când ați terminat.

Testarea fișierelor și repornirea serviciului

Configurarea pentru serverul primar este acum completă, dar mai trebuie să implementăm modificările noastre.

Înainte de a reporni serviciul nostru, ar trebui să testăm toate fișierele de configurare pentru a ne asigura că sunt configurate corect. Avem câteva instrumente care pot verifica sintaxa fiecăruia dintre fișierele noastre.

În primul rând, putem verifica fișierele named.conf.local și named.conf.options folosind comanda named-checkconf. Deoarece aceste două fișiere au ca sursă fișierul schelet named.conf, aceasta va testa sintaxa fișierelor pe care le-am modificat.

sudo named-checkconf

Dacă aceasta returnează fără niciun mesaj, înseamnă că fișierele named.conf.local și named.conf.options sunt valide din punct de vedere sintactic.

În continuare, puteți verifica fișierele de zonă individuale, trecând la comanda named-checkzone domeniul pe care îl gestionează zona și locația fișierului de zonă. Așadar, pentru ghidul nostru, ați putea verifica fișierul de zonă forward tastând:

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

Dacă fișierul dvs. nu are probleme, ar trebui să vă spună că a încărcat numărul de serie corect și să dea mesajul „OK”;

zone example.com/IN: loaded serial 5OK

Dacă dați peste orice alt mesaj, înseamnă că aveți o problemă cu fișierul dvs. de zonă. De obicei, mesajul este destul de descriptiv cu privire la ce porțiune este invalidă.

Puteți verifica zona inversă trecând adresa in-addr.arpa și numele fișierului. Pentru demonstrația noastră, vom tasta acest lucru:

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

Încă o dată, acest lucru ar trebui să vă dea un mesaj similar despre încărcarea numărului de serie corect:

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

Dacă toate fișierele sunt verificate, puteți reporni serviciul Bind:

sudo service bind9 restart

Ar trebui să verificați jurnalele tastând:

sudo tail -f /var/log/syslog

Să fiți atenți la acest jurnal pentru a vă asigura că nu există erori.

Configurați serverul secundar Bind

Acum că avem configurat serverul primar, putem merge mai departe și configura serverul secundar. Acesta va fi semnificativ mai ușor decât serverul primar.

Configurarea fișierului de opțiuni

Din nou, vom începe cu fișierul named.conf.options. Deschideți-l cu privilegii sudo în editorul de text:

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

Vom face exact aceleași modificări la acest fișier pe care le-am făcut la fișierul serverului nostru primar.

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

Salvați și închideți fișierul când ați terminat.

Configurarea fișierului de configurare locală

În continuare, vom configura fișierul named.conf.local de pe serverul secundar. Deschideți-l cu privilegii sudo în editorul dvs. de text:

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

Aici, vom crea fiecare dintre specificațiile zonei noastre, așa cum am făcut pe serverul primar. Cu toate acestea, valorile și unii dintre parametri vor fi diferite.

Primul, vom lucra la zona forward. Începeți-o în același mod în care ați făcut-o în fișierul primar:

zone "example.com" {};

De data aceasta, vom seta type la slave, deoarece acest server acționează ca secundar pentru această zonă. Acest lucru înseamnă pur și simplu că primește fișierele de zonă prin transfer, mai degrabă decât un fișier pe sistemul local. În plus, vom specifica doar numele de fișier relativ în loc de calea absolută către fișierul de zonă.

Motivul pentru aceasta este că, pentru zonele secundare, Bind stochează fișierele /var/cache/bind. Bind este deja configurat să caute în această locație a directorului, așa că nu este nevoie să specificăm calea.

Pentru zona noastră forward, aceste detalii vor arăta astfel:

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

În cele din urmă, în loc de directiva allow-transfer, vom specifica serverele primare, prin adresa IP, de la care acest server va accepta transferuri de zonă. Acest lucru se face printr-o directivă numită masters:

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

Aceasta completează specificația noastră de zonă de redirecționare. Putem folosi exact același format pentru a ne ocupa de specificația noastră de zonă inversă:

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

Când ați terminat, puteți salva și închide fișierul.

Testarea fișierelor și repornirea serviciului

Nu trebuie, de fapt, să facem nimic din crearea efectivă a fișierelor de zonă pe calculatorul secundar deoarece, așa cum am menționat mai devreme, acest server va primi fișierele de zonă de la serverul primar. Deci suntem gata să testăm.

Din nou, ar trebui să verificăm sintaxa fișierului de configurare. Deoarece nu avem niciun fișier de zonă de verificat, trebuie doar să folosim instrumentul named-checkconf:

sudo named-checkconf

Dacă acesta returnează fără erori, înseamnă că fișierele pe care le-ați modificat nu au erori de sintaxă.

Dacă acesta este cazul, puteți reporni serviciul Bind:

sudo service bind9 restart

Verificați jurnalele atât pe serverul primar cât și pe cel secundar folosind:

sudo tail -f /var/log/syslog

Ar trebui să vedeți câteva intrări care indică faptul că fișierele de zonă au fost transferate corect.

Delegați autoritatea către serverele de nume

Serverele dvs. de nume cu autoritate exclusivă ar trebui să fie acum complet configurate. Cu toate acestea, trebuie totuși să delegați autoritatea pentru domeniul dvs. către serverele de nume.

Pentru a face acest lucru, va trebui să mergeți pe site-ul web de unde ați cumpărat numele de domeniu. Interfața și, probabil, terminologia vor fi diferite în funcție de registratorul de nume de domeniu pe care l-ați folosit.

În setările domeniului dumneavoastră, căutați o opțiune care vă va permite să specificați serverele de nume pe care doriți să le utilizați. Deoarece serverele noastre de nume se află în cadrul domeniului nostru, acesta este un caz special.

În loc ca registratorul să delege pur și simplu autoritatea pentru zonă prin utilizarea înregistrărilor NS, acesta va trebui să creeze o înregistrare glue. Un glue record este o înregistrare A care specifică adresele IP pentru serverele de nume după ce specifică serverele de nume cărora le deleagă autoritatea.

În mod normal, delegarea enumeră doar serverele de nume care vor gestiona autoritatea domeniului, dar atunci când serverele de nume se află în cadrul domeniului însuși, este necesară o înregistrare A pentru serverele de nume din zona părinte. Dacă acest lucru nu s-ar întâmpla, rezolvatorii DNS ar rămâne blocați într-o buclă deoarece nu ar putea niciodată să găsească adresa IP a serverelor de nume ale domeniului pentru a urma calea de delegare.

Deci trebuie să găsiți o secțiune a panoului de control al registratorului de domenii care vă permite să specificați serverele de nume și adresele lor IP.

Ca demonstrație, registratorul Namecheap are două secțiuni diferite pentru serverele de nume.

Există o secțiune numită „Nameserver Registration” care vă permite să specificați adresele IP pentru serverele de nume din cadrul domeniului dumneavoastră:

În interior, veți putea introduce adresele IP ale serverelor de nume care există în cadrul domeniului:

Aceasta va crea înregistrările A care care servesc ca înregistrări de lipire de care aveți nevoie în fișierul de zonă părinte.

După ce ați făcut acest lucru, ar trebui să puteți schimba serverele de nume active în serverele domeniului dumneavoastră. În NameCheap, acest lucru se face folosind opțiunea de meniu „Domain Name Server Setup”:

Aici, îi puteți spune să folosească serverele de nume pe care le-ați adăugat ca servere autoritare pentru site-ul dumneavoastră:

Modificările ar putea dura ceva timp pentru a se propaga, dar ar trebui să vedeți că datele de la serverele de nume sunt folosite în următoarele 24-48 de ore pentru majoritatea registratorilor.

Concluzie

Ar trebui să aveți acum două servere DNS exclusiv autoritare configurate pentru a vă servi domeniile. Acestea pot fi folosite pentru a stoca informații de zonă pentru domenii suplimentare pe măsură ce achiziționați mai multe domenii.

Configurarea și gestionarea propriilor servere DNS vă oferă cel mai mare control asupra modului în care sunt gestionate înregistrările DNS. Puteți face modificări și să vă asigurați că toate datele DNS relevante sunt actualizate la sursă. Deși alte soluții DNS pot face acest proces mai ușor, este important să știți că aveți opțiuni și să înțelegeți ce se întâmplă în soluțiile mai bine împachetate.

.