Wtórny serwer DNS: czym jest i jak działa

Czym jest wtórny serwer DNS?

Wtórny serwer DNS to autorytatywny serwer nazw, który przechowuje kopię strefy DNS tylko do odczytu i odpowiada na zapytania o nią z takim samym autorytetem jak serwer podstawowy. Nie ma własnej wersji strefy: otrzymuje ją od serwera podstawowego w ramach transferu strefy i utrzymuje tę kopię w synchronizacji.

Z zewnątrz serwer podstawowy i wtórny są nierozróżnialne. Oba figurują w rekordach NS domeny, oba odpowiadają z flagą AA (authoritative answer), a resolwery wybierają ten, który odpowie szybciej. Różnica polega jedynie na tym, gdzie edytowane są dane: rekordy zmieniasz na serwerze podstawowym, a wtórny podąża za nim.

Starsza dokumentacja i wiele plików konfiguracyjnych wciąż nazywa te dwie role master i slave. BIND, PowerDNS i większość paneli akceptują obie nazwy; znaczenie jest to samo.

Od każdej domeny produkcyjnej oczekuje się co najmniej dwóch autorytatywnych serwerów nazw w różnych sieciach — RFC 2182 wyjaśnia dlaczego, a większość rejestrów odmawia delegacji z mniejszą liczbą. Wtórny serwer DNS to sposób, w jaki instalacja z jednym serwerem spełnia ten wymóg bez ręcznego utrzymywania drugiej pełnej instalacji DNS.

Podstawowy a wtórny DNS

Podstawowy (master). Przechowuje edytowalną kopię strefy — w plikach strefy dla BIND, w bazie danych dla PowerDNS, w magazynie panelu dla cPanel, Plesk, DirectAdmin lub CyberPanel. Każda zmiana rekordu odbywa się tutaj, a każda zmiana powinna zwiększać numer seryjny SOA strefy.

Wtórny (slave). Przechowuje kopię uzyskaną przez transfer strefy. Nigdy nie przyjmuje edycji; wszystko zmienione lokalnie zostaje nadpisane przy następnym transferze. Odpowiada na zapytania autorytatywnie, nie odsyła żadnych zmian i porzuca strefę, jeśli nie może połączyć się z serwerem podstawowym dłużej niż wynosi czas expire w SOA.

Co to oznacza w praktyce:

- Dodanie rekordu to edycja wyłącznie na serwerze podstawowym. Serwer wtórny sam przejmuje zmianę. - Jeśli serwer podstawowy nie działa, wtórny nadal odpowiada — ale nowych zmian nie można wprowadzać, dopóki podstawowy nie wróci. - Jeśli nie działa serwer wtórny, podstawowy nadal odpowiada i nic nie ginie; resolwery po prostu korzystają z pozostałego serwera nazw. - Oba serwery muszą być wpisane w rekordach NS u rejestratora, inaczej resolwery nigdy o nic nie zapytają serwera wtórnego.

Jak serwer wtórny otrzymuje strefę

Mechanizmem jest transfer strefy, zdefiniowany przez sam protokół DNS, dzięki czemu dowolny serwer wtórny może współpracować z dowolnym serwerem podstawowym niezależnie od oprogramowania.

1. Autoryzacja. Serwer podstawowy musi zezwalać na transfery do adresu IP serwera wtórnego (allow-transfer w BIND, allow-axfr-ips w PowerDNS) albo akceptować współdzielony klucz TSIG. Bez tego serwer wtórny dostaje odmowę. 2. Pierwszy transfer. Serwer wtórny prosi o całą strefę żądaniem AXFR przez port TCP 53 i zapisuje wynik. Od tej chwili jest autorytatywny dla strefy. 3. Utrzymywanie synchronizacji. Serwer wtórny ponownie sprawdza rekord SOA serwera podstawowego według harmonogramu wyznaczonego przez wartość refresh w SOA strefy. Jeśli numer seryjny serwera podstawowego jest wyższy niż jego własny, wykonuje transfer ponownie — całej strefy (AXFR) albo tylko zmian (IXFR), gdy obie strony to obsługują. 4. NOTIFY. Zamiast czekać na licznik refresh, serwer podstawowy może wysłać komunikat NOTIFY w chwili zmiany strefy; serwer wtórny sprawdza wtedy numer seryjny natychmiast. Ze skonfigurowanym NOTIFY zmiany docierają do serwera wtórnego w ciągu sekund. 5. Wygaśnięcie. Jeśli serwer podstawowy pozostaje nieosiągalny dłużej niż wartość expire w SOA, serwer wtórny przestaje odpowiadać na zapytania o strefę, zamiast serwować dane, które mogą być mocno nieaktualne.

Dwa szczegóły odpowiadają za większość nieudanych konfiguracji. Numer seryjny musi faktycznie rosnąć przy każdej zmianie — serwer wtórny porównuje liczby, nie treść. Poza tym AXFR używa TCP, nie UDP: zapora, która przepuszcza tylko UDP 53, pozwala na zwykłe zapytania, ale po cichu blokuje każdy transfer strefy. Protokół transferu jest szczegółowo opisany w Jak działają transfery stref AXFR, a liczniki czasu w Czym jest rekord SOA w DNS i dlaczego ma znaczenie dla Twojej domeny.

Dlaczego potrzebujesz wtórnego serwera DNS

Dostępność. Pojedynczy autorytatywny serwer nazw to pojedynczy punkt awarii dla każdej domeny, którą obsługuje. Restart po aktualizacji jądra, awaria sprzętu, DDoS na serwer — i domeny w ogóle się nie rozwiązują: strony WWW, poczta i API przestają działać jednocześnie. Z serwerem wtórnym w innej sieci resolwery dostają odpowiedzi od niego, a użytkownicy nic nie zauważają.

Zasady rejestratorów i rejestrów. Większość rejestrów wymaga co najmniej dwóch serwerów nazw do delegowania domeny, a niektóre sprawdzają, czy znajdują się w różnych sieciach. Wpisanie tego samego serwera pod dwiema nazwami spełnia formalność, ale nie cel: obie nazwy padają razem.

Buforowanie Cię nie uratuje. Resolwery buforują rekordy tylko przez ich TTL — od minut do godzin. Serwer podstawowy niedostępny dłużej niż TTL to domena, która znikła z internetu, a serwery pocztowe, które nie mogą rozwiązać Twojego MX, odbiją lub wstrzymają wiadomości.

Odległość. Serwer wtórny w drugiej lokalizacji odpowiada użytkownikom położonym bliżej niego, a oba serwery dzielą między siebie obciążenie zapytaniami. To korzyść uboczna, nie główny powód: głównym powodem jest to, że jeden serwer w końcu padnie, a serwer wtórny utrzymuje wtedy domenę online.

Redundancja DNS: dlaczego ma znaczenie i jak ją osiągnąć opisuje dokładniej, co naprawdę się psuje i jak się przed tym zabezpieczyć.

Własny serwer wtórny a hostowany

Własny drugi serwer. Druga instalacja BIND lub PowerDNS na innej maszynie, najlepiej w innym centrum danych, skonfigurowana jako serwer wtórny dla każdej strefy. Daje pełną kontrolę i kosztuje tylko tyle, co serwer. Koszt jest operacyjny: drugi host do aktualizowania i monitorowania, reguły zapory po obu stronach oraz każda nowa strefa rejestrowana na serwerze wtórnym ręcznie — albo automatyzowana skryptami, które sam utrzymujesz. Wiele instalacji z jednym serwerem właśnie z tego powodu nigdy do tego nie dochodzi.

Hostowana usługa wtórnego DNS. Dostawca utrzymuje wtórne serwery nazw; Ty zezwalasz na transfery strefy z jego adresu IP i kierujesz rekordy NS na jego nazwę hosta (albo na własną nazwę hosta z rekordem glue — zobacz Czym są rekordy glue w DNS i kiedy są potrzebne). Twój serwer pozostaje podstawowym, sposób edycji DNS się nie zmienia, a zadaniem dostawcy jest działać, gdy Twój serwer nie działa. Kompromis polega na tym, że połowa Twojego DNS zależy od strony trzeciej, więc jej dostępność i odseparowanie sieciowe od Twojej mają znaczenie.

Panele hostingowe. W cPanel, Plesk, DirectAdmin i CyberPanel droga ręczna jest trudniejsza, niż się wydaje: panel regeneruje konfigurację serwera DNS, więc ręczne zmiany są nadpisywane, a każda nowa domena wymaga zarejestrowania na serwerze wtórnym. Właśnie do tego istnieją integracje podpinające się do zdarzeń domenowych panelu; poniższe przewodniki dla paneli pokazują zarówno drogę ręczną, jak i zautomatyzowaną.

Niezależnie od wyboru lista kontrolna jest ta sama: transfery dozwolone z adresu serwera wtórnego, włączony NOTIFY, otwarty TCP 53, oba serwery nazw w delegacji i numer seryjny zwiększany przy każdej zmianie.

Sprawdzanie, czy serwer wtórny działa

Zapytaj bezpośrednio każdy serwer autorytatywny o rekord SOA strefy. Zastąp example.com swoją domeną, a dwie nazwy hostów swoimi serwerami nazw:

dig SOA example.com @ns1.example.com +short
dig SOA example.com @ns2.example.com +short

Oba muszą odpowiedzieć, a numer seryjny (trzecie pole) musi być identyczny. Serwer wtórny odpowiadający niższym numerem seryjnym nie przejął najnowszej zmiany; taki, który odpowiada SERVFAIL lub REFUSED, nigdy nie wczytał strefy albo ją wygasił.

Sprawdź delegację tak, jak widzi ją świat:

dig NS example.com +short

Oba serwery nazw muszą być na liście. Serwer wtórny w idealnej synchronizacji, ale nieobecny w rekordach NS, nie otrzymuje żadnych zapytań i niczego nie chroni.

Na koniec upewnij się, że sam transfer strefy jest możliwy z sieci serwera wtórnego — z hosta serwera wtórnego albo z dowolnego hosta, którego adres IP dopuszcza serwer podstawowy:

dig AXFR example.com @ns1.example.com

Pełny wydruk strefy oznacza, że transfery działają; komunikat transfer failed lub REFUSED oznacza, że reguły allow-transfer serwera podstawowego albo zapora na TCP 53 blokują serwer wtórny.

Typowe błędy

- Zapomnienie o zwiększeniu numeru seryjnego SOA. Serwer podstawowy odpowiada nowymi danymi, serwer wtórny widzi ten sam numer seryjny i nigdy nie wykonuje transferu. Najczęstsza przyczyna sytuacji „działa na ns1, nie działa na ns2”. - Otwarcie UDP 53, ale nie TCP 53. Zapytania działają, transfery nie. Każda strefa na serwerze wtórnym po cichu wygasa. - Brak serwera wtórnego w rekordach NS. Serwer wtórny synchronizuje się idealnie i nikt go o nic nie pyta. - Oba serwery nazw na tym samym hoście lub w tej samej sieci. Spełnia formalność rejestratora, ale nie chroni przed awarią, którą ma przetrwać. - Krótki expire w SOA. Jeden dzień to częsta wartość domyślna w panelach; weekendowa awaria serwera podstawowego pociąga wtedy za sobą serwer wtórny. Zwykłą wartością są dwa tygodnie. - Edytowanie rekordów na serwerze wtórnym. Znikają przy następnym transferze. - Zapomnienie o serwerze wtórnym przy dodawaniu nowej domeny. Każda nowa strefa musi zostać zarejestrowana na serwerze wtórnym, ręcznie lub automatycznie; strefa istniejąca tylko na serwerze podstawowym nie ma żadnej redundancji.

Powiązane przewodniki

Konfiguracja i mechanizmy leżące u podstaw:

- Jak skonfigurować wtórny serwer DNS - Jak działają transfery stref AXFR - Czym jest rekord SOA w DNS i dlaczego ma znaczenie dla Twojej domeny - Redundancja DNS: dlaczego ma znaczenie i jak ją osiągnąć - Czym są rekordy glue w DNS i kiedy są potrzebne

Panele hostingowe:

- Jak dodać wtórny DNS do panelu hostingowego cPanel/WHM - Jak dodać wtórny DNS do panelu hostingowego Plesk - Jak dodać wtórny DNS do panelu hostingowego DirectAdmin - Jak dodać wtórny DNS do panelu hostingowego CyberPanel