LEKCJA 11 - SERWER DNS

Wprowadzenie do lekcji

Dokument ten stanowi zwieńczenie trylogii o najważniejszych serwerach. Uruchamialiśmy serwer Dynamic Host Configuration Protocol, powoływaliśmy do życie Routing i NAT, przyszła więc pora na uruchomienie kolejnego istotnego w sieci serwera - serwera DNS.

Czym jest usługa DNS to raczej każdy wie, jednak na wszelki wypadek pozwolę sobie przypomnieć. DNS to skrót od Domain Name System i jest to hierarchiczny, rozproszony system nazw sieciowych, odpowiadający na zapytania o nazwy domen. Stwierdzenie "jest to usługa zamieniająca domenę na nazwę IP" jest dość powierzchownym stwierdzeniem i nadaje się na lekcje Informatyki w szkole podstawowej. DNS nie tylko tłumaczy domeny na adresy IP, ale może np. tłumaczyć adresy IP na domeny (tzw. RevDNS), a nawet domeny na domeny (CNAME). Hierarchiczny oznacza, że opiera się na jakiejś hierarchii, w tym przypadku będziemy mieć 13 głównym serwerów zwanych root-servers, do których są podłączone mniejsze serwery w różnych krajach. Do tych serwerów mogą być podłączone inne serwery np. operatorów domen, operatorów internetowych itd. Z kolei do tych serwerów często podłączone są serwery mniejsze – firmowe, domowe. Rozproszony oznacza, że nie skupia się w jednym miejscu. Serwery DNS rozproszone są po krajach, kontynentach, miastach itd.

Znając to, możemy przejść do instalacji naszego serwera DNS. Użyjemy do tego implementacji o nazwie BIND w wersji 9. Jest to serwer stworzony przez Internet Systems Consortium, które można kojarzyć z serwera DHCP. BIND to skrót od Berkley Internet Name Domain. Wpierw jednak warto zaktualizować repozytoria i pakiety na naszym serwerze. Jeżeli zaś chodzi o dalsze wyjaśnienia na temat DNS, to będę wszystko tłumaczył w dalszej części tego dokumentu.

I. Instalacja BIND9

11-1

Zaczynamy od instalacji pakietów, wykonując polecenia: 

$ sudo apt update
$ sudo apt install -y bind9 bind9-doc bind9-utils bind9-dnsutils

Komendy te zainstalują serwer BIND9, dodatkowe oprogramowanie oraz dokumentację. Po zakończeniu instalacji możemy przejść do właściwej konfiguracji.

Przed przystąpieniem do dalszej konfiguracji podsumujmy najważniejsze informacje:

  • Adres IP serwera: 192.168.10.10
  • Docelowa domena: egzamin.local
  • Nazwa domenowa serwera: server00.egzamin.local
  • Adres IP klienta: 192.168.10.100
  • Nazwa domenowa klienta: klient1.egzamin.local

Zamiast .local można wybrać inną domenę, pamiętając, aby nie była to domena publiczna, taka jak .com, .pl czy .edu. Najlepiej skorzystać z domeny przeznaczonej do sieci lokalnych.  

II. Konfiguracja serwera BIND9

11-2

Zaczynamy od ustawienia nazwy domenowej naszego serwera. Edytujemy plik hosts na naszym serwerze za pomocą komendy:

$ sudo nano /etc/hosts 

Dopisujemy w nim naszą docelową nazwę domenową zgodnie ze schematem przedstawionym na zrzucie ekranu.

11-3

Następnie sprawdzamy, czy serwer posiada zdefiniowaną przez nas nazwę domenową, używając polecenia: 

$ hostname -f  

UWAGA!

Zanim przejdziemy dalej: serwer BIND9 posiada bardzo restrykcyjną składnię plików konfiguracyjnych. Podczas edycji należy zwrócić uwagę, aby wszystko było wpisane poprawnie, ponieważ w przeciwnym razie serwer nie zadziała. Należy pilnować, aby nie pomijać znaków oraz nie przepisywać parametrów bezrefleksyjnie. Wysoko zalecane jest zrobienie kopii pliku przed jego edycją.

11-4

Konfiguracja BIND9 znajduje się w katalogu /etc/bind.

Kolorem zielonym oznaczono najważniejsze pliki, których będziemy używać podczas dalszej konfiguracji: 

$ cd /etc/bind/
$ ls -l  
11-5

Konfigurację naszego serwera DNS zaczynamy od pliku named.conf.options.

Zaznaczone na żółto ukośniki komentarza należy usunąć, a adres 0.0.0.0 zmienić na adres serwera DNS, do którego będą przekazywane zapytania w przypadku braku wpisu w naszych strefach. Czerwonym podświetleniem w edytorze nano nie musimy się przejmować. 

$ sudo nano /etc/bind/named.conf.options  
11-6

Wpisujemy adres DNS Google, czyli 8.8.8.8. Zapisujemy plik.  

11-7 
$ sudo nano /etc/bind/named.conf

Przechodzimy do pliku named.conf, gdzie jedynie sprawdzamy obecność trzech linii oznaczonych kolorem zielonym.  

11-8 
$ sudo nano /etc/bind/named.conf.local

Kolejnym plikiem jest named.conf.local, zainkludowany w named.conf.

Konfigurację można zapisać w obu plikach, lecz zalecaną i przejrzystą metodą jest umieszczenie jej w named.conf.local, dlatego właśnie z niego korzystamy.  

11-9

Kolorem zielonym oznaczono strefę forward, a kolorem niebieskim strefę reverse. 

Tworzenie strefy zaczynamy od słowa zone, po czym podajemy nazwę naszej domeny (egzamin.local), klasę IN oraz otwieramy nawias klamrowy. 

Wewnątrz nawiasów klamrowych podajemy parametry obsługi domeny:

  • type primary; (zapis type master; również zadziała, lecz pozostawiono go dla kompatybilności wstecznej) informuje, że nasz serwer pełni rolę serwera głównego. W przypadku serwera zapasowego wpisuje się type secondary; (dawniej type slave;), który pobiera dane o strefie z serwera primary.
  • file określa ścieżkę do pliku zawierającego bazę rekordów danej strefy.
  • allow-update { none; }; całkowicie blokuje dynamiczne aktualizowanie strefy (Dynamic DNS / RFC 2136), stosowane na przykład przez serwer DHCP.
  • allow-transfer { IP; }; określa adresy IP serwerów zapasowych (secondary), które mają uprawnienia do pobrania całej strefy. Podajemy tutaj adres serwera secondary, natomiast jeśli taki serwer nie występuje, ustawiamy wartość none.
  • also-notify { IP; }; określa adresy IP serwerów zapasowych, które mają otrzymać natychmiastowe powiadomienie o zmianie w strefie, bez konieczności definiowania ich w rekordach NS.


Następnie przechodzimy do konfiguracji strefy reverse. Zapis parametrów jest analogiczny, różnicą jest wskazanie dedykowanego pliku oraz nazwa domeny w postaci X.in-addr.arpa. Zmienna X to odwrócona część sieciowa adresu IP. Jeśli nasz serwer pracuje w sieci 192.168.10.0/24, to część sieciowa po odwróceniu daje 10.168.192. W przypadku adresu publicznego (na przykład serwera DNS Google 8.8.4.4) podaje się po prostu pełny adres zapisany od tyłu, czyli 4.4.8.8.in-addr.arpa. Podajemy odpowiednią ścieżkę pliku dla strefy wstecznej, a reszta parametrów pozostaje taka sama jak w strefie wyszukiwania do przodu. 

Należy bezwzględnie pamiętać o średnikach po zamknięciu nawiasów klamrowych.

11-10

Przechodzimy do konfiguracji strefy forward. Kopiujemy przykładowy plik konfiguracyjny db.local i nadajemy mu taką nazwę, jaką zadeklarowaliśmy przy parametrze file – w naszym przypadku forward.egzamin.local.db.

Po skopiowaniu otwieramy plik do edycji:

$ sudo cp /etc/bind/db.local /etc/bind/forward.egzamin.local.db
$ sudo nano /etc/bind/forward.egzamin.local.db
11-11

W oryginalnej zawartości pliku modyfikujemy wpisy nagłówka SOA:

Wpisy oznaczone kolorem zielonym (localhost. oraz root.localhost.) zamieniamy na pełną nazwę domenową wybraną dla naszego serwera oraz skrzynkę administratora: server00.egzamin.local. oraz root.server00.egzamin.local.

Należy pamiętać o kropce na końcu każdej nazwy FQDN.

Kolorem niebieskim oznaczono numer serial, który zwiększamy przy każdej edycji pliku, informując w ten sposób serwery o zmianie zawartości bazy.

Linie oznaczone na czerwono (odnoszące się do pętli zwrotnej) usuwamy lub zastępujemy własnymi wpisami.  

11-12

Po uzupełnieniu nagłówka SOA przechodzimy do dodawania właściwych rekordów:

  • Rekord @ IN NS definiuje serwer nazw server00.egzamin.local.
  • Rekord A przypisuje adres IP 192.168.10.10 do nazwy server00.
  • Kolejny rekord A przypisuje adres IP 192.168.10.100 do nazwy klient1.
  • Rekord CNAME tworzy alias wskazujący, że pod alternatywną nazwą ubdesk kryje się host klient1.egzamin.local.

Jeżeli adres IP przydziela serwer DHCP, w sytuacji pobrania innego adresu nasze wpisy statyczne przestaną działać. Należy wówczas ustawić statyczną konfigurację interfejsu lub wykonać stałą rezerwację adresu w DHCP.  

11-13

Przechodzimy do konfiguracji strefy reverse.

Kopiujemy plik szablonu db.127 pod nazwę podaną w named.conf.local (reverse.egzamin.local.db) i otwieramy go:

$ sudo cp /etc/bind/db.127 /etc/bind/reverse.egzamin.local.db
$ sudo nano /etc/bind/reverse.egzamin.local.db  
11-14

Podobnie jak w strefie forward, w nagłówku zamieniamy localhost. na nazwę domenową naszego serwera oraz aktualizujemy numer serial przy każdej zmianie. 

11-15

Modyfikujemy właściwe rekordy strefy:

  • Rekord NS zapisujemy identycznie jak w strefie forward.
  • Pozostałe rekordy to rekordy typu PTR:
  • Wpis 10 wskazuje, że pod adresem 192.168.10.10 znajduje się server00.egzamin.local.
  • Wpis 100 wskazuje, że pod adresem 192.168.10.100 znajduje się klient1.egzamin.local.

Również tutaj bezwzględnie pamiętamy o kropkach na końcach nazw domenowych.

W tym pliku dodajemy rekordy PTR dla wszystkich hostów posiadających rekordy A w strefie forward (z pominięciem aliasów CNAME). Zapisujemy plik i opuszczamy edytor.

11-16

Sprawdzamy poprawność składniową plików konfiguracyjnych za pomocą komend:

$ sudo named-checkconf
$ sudo named-checkzone egzamin.local /etc/bind/forward.egzamin.local.db
$ sudo named-checkzone 10.168.192.in-addr.arpa /etc/bind/reverse.egzamin.local.db

W poleceniach named-checkzone najpierw podajemy nazwę strefy, a następnie ścieżkę do weryfikowanego pliku. Prawidłowy wynik kończy się komunikatem OK.

11-17

Gdy konfiguracja nie wykazuje błędów, restartujemy usługę BIND9 i sprawdzamy jej stan: 

$ sudo systemctl restart named
$ systemctl status named

III. Przygotowanie serwera do świadczenia usługi

 Ostatnim etapem jest przygotowanie systemu do kierowania zapytań do naszego serwera DNS. 

11-18

Konfigurację zaczynamy od weryfikacji Netplana. Upewniamy się, że w sekcji nameservers aktywnej karty sieciowej wprowadzony jest adres naszego serwera DNS, czyli 192.168.10.10.

11-19

Wprowadzoną konfigurację stosujemy komendą:

$ sudo netplan apply
11-20

Testujemy działanie serwera za pomocą poleceń dig oraz nslookup:

$ dig klient1.egzamin.local
$ nslookup klient1.egzamin.local

Zdarza się, że zapytanie nie zostanie obsłużone od razu. W narzędziu dig widzimy brak sekcji odpowiedzi, a nslookup zwraca błąd SERVFAIL. Wynika to z faktu, że system odpytuje domyślny lokalny stub-resolver 127.0.0.53, omijając BIND9.  

10-21

W takim przypadku należy wyedytować plik /etc/resolv.conf. W stanie domyślnym wskazuje on adres pętli zwrotnej oraz domyślną domenę localdomain.

10-22

Plik modyfikujemy w następujący sposób:

  • nameserver zmieniamy na adres IP naszego serwera DNS (192.168.10.10).
  • search zmieniamy na nazwę naszej domeny (egzamin.local).

Po naniesieniu zmian zapisujemy plik i wychodzimy.

10-23

Ponowne wywołanie polecenia dig zwraca sekcję ANSWER: 1 (zaznaczoną na zielono), a nslookup bez problemu tłumaczy nazwę na docelowy adres IP. Od tego momentu usługa odpowiada prawidłowo.

10-24

Opcja search w pliku resolv.conf określa domenę przeszukiwania. Standardowo przy weryfikacji hosta podaje się pełną nazwę domenową. Dzięki opcji search wystarczy wpisać samą nazwę hosta (klient1), a system sam doklei resztę domeny. Działa to analogicznie przy poleceniu ping.

IV. Utrwalenie pliku resolv.conf

W systemie Ubuntu plik resolv.conf jest dynamicznie generowany, przez co po restarcie powraca do stanu pierwotnego. Przechodzimy do trwałego zapisania wprowadzonych zmian.

10-25

Usuwamy istniejący link symboliczny i tworzymy fizyczny plik:

$ sudo rm /etc/resolv.conf
$ sudo nano /etc/resolv.conf
10-26

W pliku wpisujemy następującą zawartość:

nameserver 192.168.10.10
options edns0
search egzamin.local

Zapisujemy plik i opuszczamy nano.

10-27

Nadajemy plikowi atrybut niezmienności (ang. immutable) i restartujemy nasz serwer, aby potwierdzić trwałość konfiguracji:

$ sudo chattr +i /etc/resolv.conf
$ sudo reboot
10-28

Po restarcie sprawdzamy zawartość pliku poleceniem cat /etc/resolv.conf.

Wpisy pozostały zachowane. W ten sposób prawidłowo skonfigurowaliśmy nasz serwer DNS i jest on gotowy do obsługi ruchu stacji klienckich. Adres serwera DNS przekazujemy klientom za pośrednictwem serwera DHCP lub konfigurujemy go statycznie na ich kartach sieciowych. Na stacjach z systemem Ubuntu Desktop plik resolv.conf konfigurujemy analogicznie jak na serwerze.