Introduction

DNS, lub Domain Name System, jest często trudnym elementem do uzyskania w prawo podczas nauki, jak skonfigurować strony internetowe i serwery. Podczas gdy większość ludzi prawdopodobnie zdecyduje się na korzystanie z serwerów DNS dostarczanych przez ich firmę hostingową lub rejestratora domen, istnieją pewne zalety tworzenia własnych serwerów DNS.

W tym przewodniku, omówimy jak zainstalować i skonfigurować serwer DNS Bind9 jako autorytatywne tylko serwery DNS na maszynach Ubuntu 14.04. Ustawimy te dwa serwery Bind dla naszej domeny w konfiguracji primary-secondary.

Wymagania wstępne i cele

Aby ukończyć ten przewodnik, będziesz musiał najpierw zapoznać się z pewną powszechną terminologią DNS. Sprawdź ten przewodnik, aby dowiedzieć się o koncepcjach, które będziemy implementować w tym przewodniku.

Będziesz również potrzebował co najmniej dwóch serwerów. Jeden będzie dla „głównego” serwera DNS, gdzie pliki stref dla naszej domeny będą pochodzić i jeden będzie „wtórny” serwer, który będzie otrzymywać dane strefy poprzez transfery i być dostępne w przypadku, gdy drugi serwer idzie w dół. Pozwala to uniknąć niebezpieczeństwa posiadania pojedynczego punktu awarii dla serwerów DNS.

W przeciwieństwie do buforowania lub przekazywania serwerów DNS lub wielofunkcyjnego serwera DNS, serwery autorytatywne odpowiadają tylko na iteracyjne zapytania dla stref, dla których są autorytatywne. Oznacza to, że jeśli serwer nie zna odpowiedzi, po prostu powie klientowi (zwykle jakiemuś serwerowi DNS rozwiązującemu), że nie zna odpowiedzi i poda odniesienie do serwera, który może wiedzieć więcej.

Autorytatywne serwery DNS są często dobrą konfiguracją dla wysokiej wydajności, ponieważ nie mają narzutu rozwiązywania rekursywnych zapytań od klientów. Troszczą się tylko o strefy, które są przeznaczone do obsługi.

Dla celów tego przewodnika, będziemy faktycznie odnosić się do trzech serwerów. Dwa serwery nazw wspomniane powyżej, plus serwer WWW, który chcemy skonfigurować jako host w naszej strefie.

Dla tego przewodnika użyjemy domeny fikcyjnej example.com. Powinieneś zastąpić ją domeną, którą konfigurujesz. Oto szczegóły maszyn, które będziemy konfigurować:

Cel	DNS FQDN	Adres IP
Primary name server	ns1.example.com.	192.0.2.1
Secondary name server	ns2.example.com.	192.0.2.2
Serwer WWW	www.example.com.	192.0.2.3

Po wykonaniu tego przewodnika powinieneś mieć skonfigurowane dwa autorytatywne serwery nazw dla stref domeny. Nazwy w środkowej kolumnie w tabeli powyżej będą mogły być używane do osiągnięcia różnych hostów. Używając tej konfiguracji, rekursywny serwer DNS będzie w stanie zwrócić dane o domenie do klientów.

Ustawianie nazwy hosta na serwerach nazw

Zanim przejdziemy do konfiguracji naszych serwerów nazw, musimy upewnić się, że nasza nazwa hosta jest skonfigurowana poprawnie zarówno na naszym podstawowym jak i pomocniczym serwerze DNS.

Zacznij od zbadania pliku /etc/hosts. Otwórz plik z uprawnieniami sudo w edytorze tekstu:

sudo nano /etc/hosts

Musimy go skonfigurować tak, aby poprawnie identyfikował nazwę hosta i FQDN każdego serwera. Dla głównego serwera nazw, plik będzie wyglądał początkowo tak:

127.0.0.1 localhost127.0.1.1 ns1 ns1. . .

Powinniśmy zmodyfikować drugą linię, aby odnieść się do naszej specyficznej kombinacji hosta i domeny i skierować ją na nasz publiczny, statyczny adres IP. Następnie możemy dodać niewykwalifikowaną nazwę jako alias na końcu. Dla serwera głównego w tym przykładzie, zmieniłbyś drugą linię na następującą:

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

Zapisz i zamknij plik, gdy skończysz.

Powinniśmy również zmodyfikować plik /etc/hostname, aby zawierał naszą niekwalifikowaną nazwę hosta:

sudo nano /etc/hostname

ns1

Możemy wczytać tę wartość do aktualnie działającego systemu, wpisując:

sudo hostname -F /etc/hostname

Chcemy wykonać tę samą procedurę na naszym serwerze drugorzędnym.

Zacznij od pliku /etc/hosts:

sudo nano /etc/hosts

127.0.0.1 localhost192.0.2.2 ns2.example.com ns2

Zapisz i zamknij plik, gdy skończysz.

Następnie zmodyfikuj plik /etc/hostname. Pamiętaj, aby używać tylko rzeczywistego hosta (w naszym przykładzie ns2) dla tego pliku:

sudo nano /etc/hostname

ns2

Ponownie przeczytaj plik, aby zmodyfikować bieżący system:

sudo hostname -F /etc/hostname

Twoje serwery powinny mieć teraz poprawnie ustawione definicje hostów.

Instalacja Bind na obu serwerach nazw

Na każdym z serwerów nazw można teraz zainstalować Bind, serwer DNS, którego będziemy używać.

Oprogramowanie Bind jest dostępne w domyślnych repozytoriach Ubuntu, więc musimy tylko zaktualizować nasz lokalny indeks pakietów i zainstalować oprogramowanie, używając apt. Dołączymy również dokumentację i kilka popularnych narzędzi:

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

Uruchom to polecenie instalacyjne na podstawowym i pomocniczym serwerze DNS, aby uzyskać odpowiednie pliki.

Konfigurowanie podstawowego serwera Bind

Teraz, gdy mamy zainstalowane oprogramowanie, możemy zacząć od skonfigurowania naszego serwera DNS na podstawowym serwerze.

Konfigurowanie pliku opcji

Pierwszą rzeczą, którą skonfigurujemy, aby rozpocząć, jest plik named.conf.options.

Serwer Bind DNS jest również znany jako named. Główny plik konfiguracyjny znajduje się pod adresem /etc/bind/named.conf. Ten plik odwołuje się do innych plików, które będziemy faktycznie konfigurować.

Otwórz plik opcji z uprawnieniami sudo w swoim edytorze:

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

Poniżej większość komentowanych linii została usunięta dla zwięzłości, ale ogólnie plik powinien wyglądać tak po instalacji:

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

Główną rzeczą, którą musimy skonfigurować w tym pliku, jest rekurencja. Ponieważ próbujemy skonfigurować serwer tylko autorytatywny, nie chcemy włączać rekurencji na tym serwerze. Możemy to wyłączyć w bloku options.

Zamierzamy również domyślnie nie zezwalać na transfery. Zastąpimy to w indywidualnych specyfikacjach stref później:

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

Kiedy skończysz, zapisz i zamknij plik.

Konfigurowanie pliku lokalnego

Kolejnym krokiem, który musimy wykonać, jest określenie stref, które chcemy kontrolować na tym serwerze. Strefa to dowolna część domeny, która jest delegowana do zarządzania do serwera nazw, która nie została subdelegowana do innych serwerów.

Konfigurujemy domenę example.com i nie zamierzamy subdelegować odpowiedzialności za żadną część domeny do innych serwerów. Tak więc strefa będzie obejmować całą naszą domenę.

Aby skonfigurować nasze strefy, musimy otworzyć plik /etc/bind/named.conf.local z uprawnieniami sudo:

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

Plik ten będzie początkowo pusty oprócz komentarzy. Istnieją inne strefy, o których nasz serwer wie dla ogólnego zarządzania, ale są one określone w pliku named.conf.default-zones.

Na początek, musimy skonfigurować strefę forward dla naszej domeny example.com. Strefa forward to konwencjonalna rozdzielczość między nazwami a adresami IP, o której większość z nas myśli, gdy mówi o DNS. Tworzymy blok konfiguracyjny, który określa strefę domeny, którą chcemy skonfigurować:

zone "example.com" {};

Uwaga: Wiele narzędzi DNS, ich plików konfiguracyjnych i dokumentacji używać terminów „master” i „slave”, podczas gdy DigitalOcean ogólnie preferuje alternatywne deskryptory. Aby uniknąć zamieszania, zdecydowaliśmy się używać terminów „primary” i „secondary” do określenia relacji między serwerami, a „master” lub „slave” używamy tylko wtedy, gdy wymaga tego dyrektywa konfiguracyjna.

Wewnątrz tego bloku dodajemy informacje o zarządzaniu tą strefą. Określamy związek tego serwera DNS z daną strefą. W przykładowej strefie jest to type master;, ponieważ konfigurujemy tę maszynę jako podstawowy serwer nazw dla wszystkich naszych stref. Wskazujemy również Bind do pliku, który przechowuje rzeczywiste rekordy zasobów, które definiują strefę.

Będziemy trzymać nasze podstawowe pliki strefy w podkatalogu o nazwie zones w katalogu konfiguracyjnym Bind. Nazwiemy nasz plik db.example.com, aby zapożyczyć konwencję od innych plików strefy w katalogu Bind. Nasz blok będzie wyglądał teraz tak:

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

Chcemy zezwolić na transfer tej strefy na nasz serwer wtórny, musimy dodać linię jak poniżej:

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

Następnie zdefiniujemy strefę odwrotną dla naszej domeny.

A Bit About Reverse Zones

Jeśli organizacja, która dała ci twoje adresy IP nie dała ci zakresu sieci i nie przekazała odpowiedzialności za ten zakres do ciebie, wtedy twój plik strefy odwrotnej nie będzie się do niego odwoływał i będzie obsługiwany przez samą organizację.

Z dostawcami usług hostingowych, odwrotne mapowanie jest zazwyczaj załatwiane przez samą firmę. Na przykład, z DigitalOcean, odwrotne mapowania dla serwerów zostaną automatycznie utworzone, jeśli użyć maszyny FQDN jako nazwa serwera w panelu sterowania. Na przykład, odwrotne mapowania dla tego samouczka mogą być tworzone przez nazwanie serwerów, jak to:

W przypadkach takich jak te, ponieważ nie zostały przydzielone chunk adresów do administrowania, należy użyć tej strategii. Strategia przedstawiona poniżej jest ujęta dla kompletności i aby można ją było zastosować, jeśli została przekazana kontrola nad większymi grupami sąsiadujących adresów.

Odwrócone strefy są używane do połączenia adresu IP z powrotem do nazwy domeny. Jednak system nazw domen został zaprojektowany dla odwzorowań w przód, więc trzeba się zastanowić nad przystosowaniem go do odwzorowań wstecznych.

Informacje, o których należy pamiętać, aby zrozumieć odwzorowania wsteczne są następujące:

• W domenie, najbardziej specyficzna część adresu znajduje się po lewej stronie. Dla adresu IP, najbardziej specyficzna część jest po prawej stronie.
• Najbardziej specyficzna część specyfikacji domeny jest albo subdomena lub nazwa hosta. Jest to zdefiniowane w pliku strefy dla domeny.
• Każda subdomena może z kolei definiować więcej subdomen lub hostów.

Wszystkie odwrotne mapowania strefy są zdefiniowane w domenie specjalnej in-addr.arpa, która jest kontrolowana przez Internet Assigned Numbers Authority (IANA). W ramach tej domeny istnieje drzewo, które wykorzystuje subdomeny do mapowania każdego z oktetów w adresie IP. Aby upewnić się, że specyfika adresów IP odzwierciedla specyfikę normalnych domen, oktety adresów IP są w rzeczywistości odwrócone.

Więc nasz podstawowy serwer DNS, z adresem IP 192.0.2.1, zostałby odwrócony, aby odczytać go jako 1.2.0.192. Kiedy dodamy tę specyfikację hosta jako hierarchię istniejącą w domenie in-addr.arpa, konkretny host może być określony jako 1.2.0.192.in-addr.arpa.

Ponieważ definiujemy indywidualne hosty (jak wiodące „1” tutaj) wewnątrz samego pliku strefy podczas używania DNS, strefa którą konfigurujemy to 2.0.192.in-addr.arpa. Jeśli nasz dostawca sieci dał nam blok adresów /24, powiedzmy 192.0.2.0/24, oddelegowałby tę część in-addr.arpa do nas.

Teraz, gdy wiesz, jak określić nazwę strefy odwrotnej, rzeczywista definicja jest dokładnie taka sama jak strefy forward. Poniżej definicji strefy example.com utwórz strefę odwrotną dla sieci, którą otrzymałeś. Ponownie, jest to prawdopodobnie konieczne tylko wtedy, gdy przekazano Ci kontrolę nad blokiem adresów:

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

Wybraliśmy nazwę pliku db.192.0.2. Określa to, co strefa konfiguruje i jest bardziej czytelne niż notacja odwrotna.

Zapisz i zamknij plik, gdy skończysz.

Twórz plik strefy forward

Powiedzieliśmy teraz Bindowi o naszych strefach forward i reverse, ale nie utworzyliśmy jeszcze plików, które zdefiniują te strefy.

Jeśli pamiętasz, określiliśmy lokalizacje plików jako znajdujące się w podkatalogu o nazwie zones. Musimy utworzyć ten katalog:

sudo mkdir /etc/bind/zones

Teraz możemy wykorzystać niektóre z istniejących wcześniej plików stref w katalogu Bind jako szablony dla plików stref, które chcemy utworzyć. Dla strefy forward, plik db.local będzie zbliżony do tego, czego potrzebujemy. Skopiuj ten plik do podkatalogu zones o nazwie użytej w pliku named.conf.local.

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

Podczas wykonywania tej czynności możemy skopiować również szablon dla strefy odwrotnej. Użyjemy pliku db.127, ponieważ jest on bliski temu, czego potrzebujemy:

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

Teraz otwórz plik strefy forward z uprawnieniami sudo w edytorze tekstu:

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

Plik będzie wyglądał tak:

$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

Pierwszą rzeczą, którą musimy zrobić jest modyfikacja rekordu SOA (początek uprawnień), który zaczyna się od pierwszego symbolu @ i trwa aż do nawiasu zamykającego.

Musimy zastąpić localhost. nazwą FQDN tego urządzenia. Ta część rekordu jest używana do zdefiniowania serwera nazw, który będzie odpowiadał autorytatywnie dla definiowanej strefy. Będzie to maszyna, którą teraz konfigurujemy, ns1.example.com. w naszym przypadku (zwróć uwagę na kropkę. Jest to ważne, aby nasz wpis zarejestrował się poprawnie!).

Chcemy również zmienić kolejny element, który jest tak naprawdę specjalnie sformatowanym adresem e-mail z @ zastąpionym kropką. Chcemy, aby nasze maile trafiały do administratora domeny, więc tradycyjny mail to [email protected]. Przetłumaczylibyśmy to tak, aby wyglądało to jak admin.example.com.:

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

Kolejnym elementem, który musimy edytować jest numer seryjny. Wartość numeru seryjnego jest jak Bind mówi, czy musi wysłać zaktualizowane informacje do serwera wtórnego.

Uwaga: Nieudana inkrementacja numeru seryjnego jest jednym z najczęstszych błędów, który prowadzi do problemów z aktualizacjami strefy. Za każdym razem, gdy dokonujesz edycji, musisz podbić numer seryjny.

Jedną z powszechnych praktyk jest użycie konwencji do inkrementacji numeru. One approach is to use the date in YYYYMMDD format along with a revision number for the day added on the end. W ten sposób pierwsza aktualizacja dokonana 05 czerwca 2014 mogłaby mieć numer seryjny 2014060501, a aktualizacja dokonana później tego samego dnia mogłaby mieć numer seryjny 2014060502. Wartość może być liczbą dziesięciocyfrową.

Warto przyjąć jakąś konwencję dla łatwości użycia, ale aby zachować prostotę dla naszej demonstracji, na razie ustawimy nasz na 5:

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

Następnie możemy pozbyć się trzech ostatnich linii w pliku (tych na dole, które zaczynają się od @), ponieważ będziemy tworzyć własne.

Pierwszą rzeczą, którą chcemy ustalić po rekordzie SOA są serwery nazw dla naszej strefy. Określamy domenę, a następnie nasze dwa serwery nazw, które są autorytatywne dla strefy, po nazwie. Ponieważ te serwery nazw będą hostami w samej domenie, będzie to wyglądać nieco autoreferencyjnie.

Dla naszego przewodnika, będzie to wyglądało tak. Ponownie, zwróć uwagę na kończące kropki!:

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

Ponieważ celem pliku strefy jest głównie mapowanie nazw hostów i usług do konkretnych adresów, jeszcze nie skończyliśmy. Każde oprogramowanie czytające ten plik strefy będzie chciało wiedzieć, gdzie znajdują się serwery ns1 i ns2, aby uzyskać dostęp do stref autorytatywnych.

Następnie musimy utworzyć rekordy A, które powiążą te nazwy serwerów nazw z rzeczywistymi adresami IP naszych serwerów nazw:

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

Teraz, gdy mamy rekordy A, aby pomyślnie rozwiązać nasze serwery nazw do ich prawidłowych adresów IP, możemy dodać dodatkowe rekordy. Pamiętajmy, że mamy serwer WWW na jednym z naszych hostów, który chcemy wykorzystać do obsługi naszej witryny. Będziemy kierować żądania dla domeny ogólnej (example.com w naszym przypadku) do tego hosta, jak również żądania dla hosta www. Będzie to wyglądało tak:

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

Możesz dodać dodatkowe hosty, które potrzebujesz zdefiniować poprzez utworzenie dodatkowych rekordów A. Odwołaj się do naszego przewodnika po podstawach DNS, aby zapoznać się z niektórymi opcjami tworzenia dodatkowych rekordów.

Gdy skończysz, twój plik powinien wyglądać tak:

$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

Zapisz i zamknij plik, gdy skończysz.

Twórz plik strefy odwrotnej

Teraz mamy skonfigurowaną strefę forward, ale musimy skonfigurować plik strefy odwrotnej, który określiliśmy w naszym pliku konfiguracyjnym. Już utworzyliśmy ten plik na początku ostatniej sekcji.

Otwórz plik w edytorze tekstu z uprawnieniami sudo:

sudo nano db.192.0.2

Plik powinien wyglądać tak:

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

Przejdziemy przez wiele z tej samej procedury, jak zrobiliśmy to ze strefą forward. Po pierwsze, dostosuj nazwę domeny, e-mail administratora i numer seryjny, aby dopasować dokładnie to, co miałeś w ostatnim pliku (numer seryjny może być inny, ale powinien być inkrementowany):

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

Ponownie, wymazać linie pod nawiasem zamykającym SOA rekord. Będziemy brać ostatni oktet każdego adresu IP w naszym zakresie sieci i mapować go z powrotem do FQDN tego hosta za pomocą rekordu PTR. Każdy adres IP powinien mieć tylko jeden rekord PTR, aby uniknąć problemów w niektórych programach, więc musisz wybrać nazwę hosta, na którą chcesz odwzorować.

Na przykład, jeśli masz skonfigurowany serwer pocztowy, prawdopodobnie chcesz skonfigurować odwrotne mapowanie na nazwę poczty, ponieważ wiele systemów używa odwrotnego mapowania do sprawdzania poprawności adresów.

Po pierwsze, musimy ustawić nasze serwery nazw ponownie:

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

Następnie, użyjesz ostatniego oktetu adresu IP, do którego się odnosisz i wskażesz go z powrotem na w pełni kwalifikowaną nazwę domeny, z którą chcesz wrócić. Dla naszego przykładu, użyjemy tego:

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

Gdy skończysz, plik powinien wyglądać tak:

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

Zapisz i zamknij plik, gdy skończysz.

Testowanie plików i ponowne uruchamianie usługi

Konfiguracja serwera głównego jest teraz zakończona, ale nadal musimy wdrożyć nasze zmiany.

Przed ponownym uruchomieniem naszej usługi powinniśmy przetestować wszystkie nasze pliki konfiguracyjne, aby upewnić się, że są skonfigurowane poprawnie. Mamy kilka narzędzi, które mogą sprawdzić składnię każdego z naszych plików.

Po pierwsze, możemy sprawdzić pliki named.conf.local i named.conf.options za pomocą polecenia named-checkconf. Ponieważ oba te pliki są źródłowe przez plik szkieletowy named.conf, przetestuje on składnię plików, które zmodyfikowaliśmy.

sudo named-checkconf

Jeśli zwróci to bez żadnych komunikatów, oznacza to, że pliki named.conf.local i named.conf.options są poprawne składniowo.

Następnie, możesz sprawdzić swoje indywidualne pliki strefy, przekazując domenę, którą strefa obsługuje i lokalizację pliku strefy do polecenia named-checkzone. Więc dla naszego przewodnika, mógłbyś sprawdzić plik strefy forward wpisując:

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

Jeśli twój plik nie ma problemów, powinien powiedzieć ci, że załadował poprawny numer seryjny i dać wiadomość „OK”;

zone example.com/IN: loaded serial 5OK

Jeśli napotkasz inne wiadomości, oznacza to, że masz problem z plikiem strefy. Zazwyczaj komunikat jest dość opisowy o tym, która część jest nieprawidłowa.

Możesz sprawdzić strefę odwrotną przez podanie adresu in-addr.arpa i nazwy pliku. Dla naszej demonstracji, wpisalibyśmy to:

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

Powtarzam, to powinno dać ci podobny komunikat o załadowaniu poprawnego numeru seryjnego:

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

Jeśli wszystkie twoje pliki się sprawdzają, możesz ponownie uruchomić usługę Bind:

sudo service bind9 restart

Powinieneś sprawdzić logi wpisując:

sudo tail -f /var/log/syslog

Spójrz na ten log, aby upewnić się, że nie ma żadnych błędów.

Konfigurowanie wtórnego serwera wiążącego

Teraz, gdy mamy skonfigurowany serwer główny, możemy iść naprzód i skonfigurować serwer wtórny. Będzie to znacznie łatwiejsze niż w przypadku serwera głównego.

Konfigurowanie pliku opcji

Ponownie, zaczniemy od pliku named.conf.options. Otwórz go z uprawnieniami sudo w edytorze tekstu:

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

Wprowadzimy do tego pliku dokładnie te same modyfikacje, które wprowadziliśmy do pliku serwera głównego.

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

Zapisz i zamknij plik, gdy skończysz.

Konfigurowanie lokalnego pliku konfiguracyjnego

Następnie skonfigurujemy plik named.conf.local na serwerze wtórnym. Otwórz go z uprawnieniami sudo w edytorze tekstu:

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

Tutaj utworzymy każdą z naszych specyfikacji strefy, tak jak zrobiliśmy to na naszym głównym serwerze. Jednak wartości i niektóre parametry będą inne.

Po pierwsze, będziemy pracować nad strefą forward. Zacznij w ten sam sposób, jak w przypadku pliku głównego:

zone "example.com" {};

Tym razem ustawimy type na slave, ponieważ ten serwer działa jako drugorzędny dla tej strefy. Oznacza to po prostu, że otrzymuje on swoje pliki strefy poprzez transfer, a nie plik na lokalnym systemie. Dodatkowo, będziemy po prostu określać względną nazwę pliku zamiast bezwzględnej ścieżki do pliku strefy.

Powodem tego jest to, że dla stref drugorzędnych, Bind przechowuje pliki /var/cache/bind. Bind jest już skonfigurowany do szukania w tej lokalizacji katalogu, więc nie musimy określać ścieżki.

Dla naszej strefy forward, te szczegóły będą wyglądać tak:

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

Wreszcie, zamiast dyrektywy allow-transfer, określimy podstawowe serwery, według adresów IP, z których ten serwer będzie akceptował transfery stref. Jest to zrobione w dyrektywie o nazwie masters:

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

To kończy naszą specyfikację strefy forward. Możemy użyć tego samego formatu, aby zadbać o naszą specyfikację strefy odwrotnej:

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

Kiedy skończysz, możesz zapisać i zamknąć plik.

Testowanie plików i ponowne uruchamianie usługi

Nie musimy w rzeczywistości tworzyć plików stref na maszynie drugorzędnej, ponieważ, jak wspomnieliśmy wcześniej, ten serwer otrzyma pliki stref od serwera głównego. Tak więc jesteśmy gotowi do testów.

Powinniśmy jeszcze raz sprawdzić składnię pliku konfiguracyjnego. Ponieważ nie mamy żadnych plików stref do sprawdzenia, wystarczy, że użyjemy narzędzia named-checkconf:

sudo named-checkconf

Jeśli zwróci ono wynik bez żadnych błędów, oznacza to, że pliki, które zmodyfikowałeś, nie mają błędów składni.

Jeśli tak jest, możesz ponownie uruchomić usługę Bind:

sudo service bind9 restart

Sprawdź dzienniki zarówno na serwerze głównym, jak i pomocniczym, używając:

sudo tail -f /var/log/syslog

Powinieneś zobaczyć kilka wpisów, które wskazują, że pliki strefy zostały przesłane poprawnie.

Delegate Authority to your Name Servers

Twoje serwery nazw tylko autorytatywne powinny być teraz całkowicie skonfigurowane. Jednak nadal trzeba delegować uprawnienia dla domeny do serwerów nazw.

Aby to zrobić, trzeba będzie przejść do strony internetowej, gdzie zakupiono nazwę domeny. Interfejs i być może terminologia będą się różnić w zależności od rejestratora nazwy domeny, której użyłeś.

W ustawieniach domeny, poszukaj opcji, która pozwoli Ci określić serwery nazw, których chcesz użyć. Ponieważ nasze serwery nazw są w naszej domenie, jest to szczególny przypadek.

Zamiast rejestratora po prostu delegowanie uprawnień dla strefy poprzez wykorzystanie rekordów NS, będzie musiał utworzyć rekord kleju. Rekord glue to rekord A, który określa adresy IP serwerów nazw po określeniu serwerów nazw, do których deleguje uprawnienia.

Zwykle delegacja wymienia tylko serwery nazw, które będą obsługiwać uprawnienia domeny, ale gdy serwery nazw znajdują się w samej domenie, potrzebny jest rekord A dla serwerów nazw w strefie nadrzędnej. Gdyby tak się nie stało, resolwery DNS utknęłyby w pętli, ponieważ nigdy nie byłyby w stanie znaleźć adresu IP serwerów nazw domeny, aby podążać ścieżką delegacji.

Więc musisz znaleźć sekcję panelu sterowania rejestratora domeny, która pozwala określić serwery nazw i ich adresy IP.

Jako demonstracja, rejestrator Namecheap ma dwie różne sekcje serwerów nazw.

Jest sekcja o nazwie „Rejestracja serwerów nazw”, która pozwala określić adresy IP dla serwerów nazw w domenie:

Wewnątrz, będzie można wprowadzić adresy IP serwerów nazw, które istnieją w domenie:

To stworzy rekord A, które służą jako rekordy kleju, które trzeba w pliku strefy nadrzędnej.

Po wykonaniu tych czynności, powinieneś być w stanie zmienić aktywne serwery nazw na serwery Twojej domeny. W NameCheap, odbywa się to za pomocą opcji menu „Domain Name Server Setup”:

Tutaj możesz powiedzieć, aby użyć serwerów nazw, które dodałeś jako serwery autorytatywne dla Twojej witryny:

Zmiany mogą trochę potrwać, ale powinieneś zobaczyć dane z Twoich serwerów nazw, które będą używane w ciągu następnych 24-48 godzin dla większości rejestratorów.

Zakończenie

Powinieneś teraz mieć dwa autorytatywne serwery DNS skonfigurowane do serwowania Twoich domen. Mogą one być używane do przechowywania informacji o strefie dla dodatkowych domen, gdy zdobędziesz ich więcej.

Konfigurowanie i zarządzanie własnymi serwerami DNS daje Ci największą kontrolę nad tym, jak rekordy DNS są obsługiwane. Możesz wprowadzać zmiany i mieć pewność, że wszystkie istotne elementy danych DNS są aktualne u źródła. Chociaż inne rozwiązania DNS mogą ułatwić ten proces, ważne jest, aby wiedzieć, że masz opcje i zrozumieć, co dzieje się w bardziej pakietowych rozwiązaniach.

.