Redundancja DNS: dlaczego ma znaczenie i jak ją osiągnąć

DNS to pojedynczy punkt awarii

Każda strona internetowa, API i usługa online zależy od DNS, aby przekształcić nazwy domen w adresy IP. Jeśli Twój DNS przestanie działać, cała Twoja obecność online zniknie — nawet jeśli serwery za nią są w pełni sprawne.

Pojedynczy serwer nazw to pojedynczy punkt awarii. Awarie sprzętu, problemy sieciowe, ataki DDoS lub nawet źle skonfigurowana reguła zapory mogą wyłączyć go z działania. Gdy tak się stanie, nikt nie będzie mógł dotrzeć do Twojej usługi.

Gdy DNS pada: lekcje z prawdziwych awarii

Awarie DNS nie są hipotetyczne. W październiku 2016 roku potężny atak DDoS na jednego dostawcę DNS (Dyn) na wiele godzin wyłączył Twittera, GitHuba, Reddita, Spotify i dziesiątki innych dużych serwisów — nie dlatego, że zawiodły ich własne serwery, lecz dlatego, że zawiodła jedyna usługa DNS, na której polegały.

Wniosek jest prosty: jeśli wszystkie serwery nazw Twojej domeny są u jednego dostawcy, ten dostawca jest Twoim pojedynczym punktem awarii. Niezależny wtórny serwer nazw na osobnej infrastrukturze utrzymuje Twoją domenę w działaniu nawet wtedy, gdy Twój główny DNS gaśnie.

Co oznacza redundancja DNS

Redundancja DNS oznacza uruchomienie wielu niezależnych serwerów nazw dla tej samej strefy. Jeśli jeden zawiedzie, pozostałe nadal odpowiadają na zapytania. Klienci i resolvery automatycznie próbują alternatywnych serwerów nazw, gdy pierwszy jest nieosiągalny.

Prawdziwa redundancja wymaga:

– Wielu serwerów nazw (co najmniej dwóch — przejście z jednego na dwa usuwa pojedynczy punkt awarii) – Geograficznego rozproszenia w różnych sieciach i centrach danych – Automatycznej synchronizacji, aby wszystkie serwery zwracały te same rekordy – Niezależnych domen awarii — serwery nie powinny dzielić tego samego zasilania, sieci ani dostawcy hostingu

Jak działa failover DNS

Gdy resolver DNS wysyła zapytanie o Twoją domenę, otrzymuje listę wszystkich serwerów nazw z rekordów NS. Jeśli pierwszy serwer nazw nie odpowie w ramach limitu czasu (zwykle 2–5 sekund), resolver wypróbuje następny.

Dzieje się to przejrzyście — użytkownicy końcowi nie widzą żadnego błędu. Failover jest wbudowany w sam protokół DNS. Jedynym kosztem jest kilka sekund dodatkowego opóźnienia przy pierwszym wyszukiwaniu, które następnie jest buforowane.

Architektura podstawowego i wtórnego DNS

Najczęstsze podejście do redundancji DNS to model główny-wtórny (master-slave):

– Serwer główny jest miarodajnym źródłem prawdy. Tutaj wprowadzasz wszystkie zmiany DNS. – Jeden lub więcej serwerów wtórnych otrzymuje dane strefy z serwera głównego poprzez transfery AXFR/IXFR. – Wszystkie serwery są wymienione jako rekordy NS i odpowiadają na zapytania na równi.

Ta architektura jest prosta, sprawdzona w boju i obsługiwana przez każde większe oprogramowanie serwera DNS.

Ile serwerów nazw potrzebujesz?

Najważniejszy krok to przejście z jednego serwera nazw na dwa. Jeden serwer nazw to pojedynczy punkt awarii; drugi, niezależny serwer nazw go usuwa — i właśnie ten pierwszy skok daje zdecydowanie największy wzrost niezawodności.

Twój serwer główny plus jeden niezależny wtórny, w osobnej sieci i u innego dostawcy, dają dwa serwery nazw — co spełnia też minimum wymagane przez praktycznie każdego rejestratora domen. RFC 2182 zaleca trzy jako dodatkowy zapas dla bardzo obciążonych lub krytycznych stref, ale najważniejsza nie jest sama liczba, lecz to, by Twoje serwery nazw nie dzieliły tej samej domeny awarii. Dwa serwery w tej samej szafie są znacznie słabsze niż dwa serwery w niezależnych sieciach.

Dwóch dostawców bije dwa serwery w jednym miejscu

Redundancja pomaga tylko wtedy, gdy Twoje serwery nazw mogą zawodzić niezależnie. Dwa serwery w tym samym centrum danych dzielą zasilanie, sieć i routing wyjściowy — jeden incydent może wyłączyć oba naraz. Prawdziwą odporność daje rozproszenie serwerów nazw między różnych dostawców i regiony.

Właśnie to dodaje usługa wtórnego DNS: zostaw swój główny serwer tam, gdzie jest, i umieść niezależny wtórny serwer na osobnej infrastrukturze, w wybranym przez siebie regionie. Twoja domena przetrwa teraz utratę dowolnej ze stron — a nie tylko restart jednej maszyny w tym samym pomieszczeniu.

Najczęstsze błędy w redundancji DNS

Unikaj tych pułapek podczas konfigurowania redundancji DNS:

Wszystkie serwery nazw w tej samej sieci: Jeśli sieć przestanie działać, wszystkie serwery przestaną działać. Umieść serwery wtórne w różnych centrach danych i u różnych dostawców.

Zapomnienie o zezwoleniu na transfery strefy: Serwer wtórny nie może się synchronizować, jeśli AXFR jest zablokowany na serwerze głównym.

Ignorowanie numeru seryjnego SOA: Serwer główny musi inkrementować numer seryjny SOA przy każdej zmianie. Jeśli numer seryjny nie rośnie, serwery wtórne nie pobiorą aktualizacji.

Brak monitorowania serwerów wtórnych: Serwer wtórny udostępniający przestarzałe rekordy jest gorszy niż brak serwera wtórnego. Skonfiguruj alerty na nieudane transfery strefy.

Dlaczego warto używać zarządzanej usługi wtórnego DNS

Uruchomienie własnego wtórnego serwera nazw wymaga utrzymywania dodatkowej infrastruktury. Zarządzana usługa wtórnego DNS robi to za Ciebie:

– Automatyczna synchronizacja strefy AXFR – Niezależny wtórny serwer na osobnej infrastrukturze, w wybranej przez Ciebie lokalizacji – Wbudowane monitorowanie i alerty – Brak obciążenia związanego z zarządzaniem serwerem

Zachowujesz pełną kontrolę nad rekordami DNS na swoim serwerze głównym. Zarządzany serwer wtórny po prostu je lustrzanie odwzorowuje i odpowiada na zapytania, gdy jest to potrzebne.

SecondDNS daje to wszystko w bezpłatnym 3-miesięcznym okresie próbnym — dodaj swoją domenę, bez karty kredytowej.

Powiązane przewodniki

Zbuduj redundantny DNS dzięki tym przewodnikom:

- Jak skonfigurować wtórny serwer DNS - Jak działają transfery stref AXFR - Personalizowane serwery nazw: konfiguracja, rekordy glue i pułapki - Jak dodać wtórny DNS do cPanel/WHM - Jak dodać wtórny DNS do Plesk - Jak dodać wtórny DNS do DirectAdmin - Jak dodać wtórny DNS do CyberPanel