Defaults.Exposed › Naprawy › Konfiguracja serwerów nazw (różnorodność i SOA)

Jak naprawić Konfiguracja serwerów nazw (różnorodność i SOA)

Twoje serwery nazw to katalog, który mówi całemu internetowi, gdzie znaleźć Twoją witrynę i e-mail. Jeśli wszystkie siedzą w jednej sieci, a ona padnie, Twoja firma znika z internetu w tym samym momencie — bez witryny, bez e-maila, bez niczego — a niedbałe ustawienie zegara na tych serwerach może sprawić, że wprowadzane zmiany utkną na dni.

W skrócie dla Twojej firmy: Jeśli każdy serwer nazw Twojej domeny żyje w jednej sieci, jedna awaria lub atak na tę sieć wyłącza Twoją witrynę I e-mail razem — wciąż płacisz pensje i reklamy, podczas gdy żaden klient nie może Cię dosięgnąć. Osobno, źle skonfigurowane liczniki SOA mogą sprawić, że Twoje zmiany DNS (nowy serwer, przełączony dostawca poczty, awaryjne przekierowanie) propagują się dniami zamiast godzinami.

Ile może Cię to kosztować

• Jedyna sieć, w której siedzą wszystkie Twoje serwery nazw, ma zły dzień — awarię lub atak DDoS — i Twoja witryna oraz e-mail znikają w tym samym czasie. Klienci dostają strony błędu, Twoja skrzynka sprzedaży odbija wiadomości, a Twój informatyk nie może nic zrobić poza czekaniem na powrót cudzej sieci.
• Zespół bezpieczeństwa dużego klienta robi sprawdzenie dostawcy, widzi wszystkie Twoje serwery nazw u jednego dostawcy bez redundancji i odnotowuje Twoją domenę jako pojedynczy punkt awarii — tarcie na kontrakcie, który inaczej byś wygrał.
• Przenosisz się na nowy host WWW lub zmieniasz dostawcę poczty, ale błędny licznik „refresh” w rekordzie SOA sprawia, że inne serwery DNS nadal podają Twój stary adres przez dni — więc część klientów ląduje na martwej witrynie, a Twój e-mail rozszczepia się na dwoje.
• Incydent bezpieczeństwa zmusza Cię do pilnego przekierowania ruchu, ale liczniki SOA każą światu cache'ować Twoje stare rekordy przez tydzień, więc zmiana sprzed godziny wciąż nie dotarła do połowy internetu, podczas gdy problem trwa.
• Twoje dwa serwery nazw to technicznie dwie nazwy, ale rozwiązują się do tej samej szafy w tej samej sieci — więc redundancja, którą myślisz, że masz, to iluzja, a pojedyncza awaria wciąż wyłącza wszystko.

Dlaczego to ma znaczenie. Każda wizyta na Twojej witrynie i każdy e-mail do Ciebie zaczyna się od zapytania do Twoich serwerów nazw. To fundament, na którym siedzi reszta Twojej obecności w sieci. Jeśli ten fundament nie ma redundancji, pojedyncza awaria wyłącza wszystko naraz; jeśli jego wartości czasowe są błędne, każda wprowadzona zmiana działa z opóźnieniem — dokładnie wtedy, gdy najmniej możesz sobie na to pozwolić.

Co to jest, po ludzku

Zanim ktokolwiek dosięgnie Twojej witryny lub wyśle Ci e-mail, jego komputer musi zadać proste pytanie: „gdzie faktycznie mieszka ta domena?”. Serwery, które odpowiadają na to pytanie, to Twoje serwery nazw. To wpis katalogowy dla całej Twojej obecności w sieci — pierwsza rzecz, której dotyka każdy odwiedzający i każdy e-mail, zanim w grę wejdzie w ogóle Twoja witryna czy skrzynka.

Ta strona obejmuje dwie części dobrego ustawienia tego katalogu:

1. Różnorodność — czy masz co najmniej dwa serwery nazw i czy siedzą w naprawdę osobnych częściach sieci, by jedna awaria nie mogła uciszyć ich wszystkich naraz?
2. Rekord SOA — mały rekord „start of authority”, który trzyma wartości czasowe kontrolujące, jak długo reszta internetu ufa i cache’uje Twoje odpowiedzi DNS. Pomyl liczniki, a każda wprowadzona zmiana dociera do świata dłużej.

Żadne z tego nie jest efektowne. Oba to fundamenty. Gdy są dobre, nigdy o nich nie myślisz; gdy są złe, dowiadujesz się w najgorszym możliwym momencie.

Co to może Cię kosztować

• Wszystko offline naraz. Jeśli wszystkie Twoje serwery nazw żyją w jednej sieci, a ta sieć ma awarię lub zostaje trafiona atakiem DDoS, Twoja witryna i e-mail gasną razem. To nie teoria — atak na pojedynczego dostawcę DNS wyłączał z internetu duże, dobrze zaopatrzone firmy na większość dnia. Z redundancją między sieciami jedna awaria jest do przeżycia; bez niej jest totalna.

• Transakcja utracona na sprawdzeniu dostawcy. Zespół bezpieczeństwa lub zakupów większego klienta robi sprawdzenie przed podpisaniem, widzi wszystkie Twoje serwery nazw skupione u jednego dostawcy bez awaryjnej zapasowej drogi i oznacza Twoją domenę jako pojedynczy punkt awarii. To rodzaj drobnego, dającego się uniknąć znaku, który dodaje tarcia do kontraktu, który inaczej byś wygrał.

• Zmiany, które nie wchodzą. Zmieniasz hosty WWW, przenosisz dostawców poczty albo musisz w pośpiechu przekierować ruch. Błędny licznik „refresh” lub „expire” w rekordzie SOA sprawia, że inne serwery DNS nadal serwują Twoją starą odpowiedź przez dni. Połowa klientów ląduje na nowej witrynie, połowa na martwej; część poczty płynie do starego dostawcy, część do nowego. Zmiana sprzed godziny wciąż nie jest gotowa.

• Awaryjna sytuacja, której nie możesz szybko zakończyć. Podczas incydentu bezpieczeństwa musisz skierować ruch z dala od skompromitowanego serwera teraz. Jeśli Twoje liczniki SOA kazały światu cache’ować Twoje rekordy przez tydzień, Twoja poprawka pełznie po internecie, podczas gdy problem dalej kąsa.

• Redundancja, która nie jest prawdziwa. Masz dwa serwery nazw, więc zakładasz, że jesteś zabezpieczony — ale oba rozwiązują się do tej samej szafy w tej samej sieci. Pierwsza awaria sprzętu wyłącza całość, a siatka bezpieczeństwa, na którą liczyłeś, nigdy tam nie była.

Czym to właściwie jest

Różnorodność serwerów nazw. Twoja domena powinna wymieniać co najmniej dwa serwery nazw, a najlepiej, by siedziały na naprawdę niezależnych ścieżkach sieciowych — nie tylko dwie nazwy wskazujące na tę samą maszynę. Za kulisami każda nazwa serwera nazw rozwiązuje się do jednego lub więcej adresów IP, a naprawdę liczy się to, czy te adresy zajmują różne części routingu internetu. Poważny dostawca DNS rozprasza swoje serwery nazw po wielu osobnych blokach sieci i lokalizacjach na świecie, więc nawet dwa serwery nazw od tego samego dostawcy dają Ci prawdziwą, niezależną redundancję. Przypadek awarii jest przeciwny: pojedynczy mały host, gdzie oba serwery nazw to ta sama maszyna, więc jedna awaria jest totalna.

Uwaga dla czytelnika technicznego: nasz test liczy Twoje rekordy NS, a następnie przygląda się, ile prawdziwej różnorodności sieciowej za nimi stoi. Głównym sygnałem jest rozrzut odrębnych bloków sieci IP, do których rozwiązują się serwery nazw (z grubsza zakresy /16 dla IPv4 i /32 dla IPv6), z liczbą odrębnych nazw dostawców jako wsparciem. To celowo docenia hiperskalowych dostawców Anycast — Cloudflare, Google, AWS Route 53, Azure DNS — którzy ogłaszają jedną tożsamość sieciową z wielu globalnie osobnych ścieżek routingu i tak dostarczają prawdziwą różnorodność nawet z jednej marki. Posiadanie mniej niż dwóch serwerów nazw daje zero w tym teście i jest traktowane jako wysoka waga, bo to niezłagodzony pojedynczy punkt awarii dla całej domeny.

Rekord SOA. Każda strefa DNS ma dokładnie jeden rekord Start of Authority. Nazywa główny serwer nazw i kontakt administracyjny, niesie numer seryjny, który rośnie przy każdej zmianie, oraz — część, która liczy się dla Twojej firmy — trzyma cztery liczniki:

• Refresh — jak często serwery nazw drugorzędne sprawdzają główny pod kątem zmian. Dobry zakres: z grubsza 1 do 24 godzin (3600–86400 sekund).
• Retry — jak szybko ponowić próbę, jeśli refresh zawiedzie. Dobry zakres: z grubsza 5 do 60 minut (300–3600 sekund).
• Expire — jak długo serwery drugorzędne serwują dalej Twoje rekordy, jeśli w ogóle nie mogą dosięgnąć głównego. Dobry zakres: z grubsza 1 do 4 tygodni (604800–2419200 sekund).
• Minimum TTL — dolna granica tego, jak długo odpowiedzi (w tym odpowiedzi „ta nazwa nie istnieje”) są cache’owane. Powinna być rozsądną wartością dodatnią; 300 sekund to częsty wybór.

Jak wygląda dobry stan: SOA, które istnieje, ma ważny kontakt administracyjny i niesie liczniki wewnątrz tych zakresów. Wartości poza zakresami nie są śmiertelne — ale albo spowalniają Twoje zmiany (liczniki zbyt długie), albo niepotrzebnie obciążają serwery nazw (zbyt krótkie). Brakujący lub naprawdę zepsuty SOA to poważniejszy przypadek.

Jak to naprawić (darmowo, ~15 minut)

Ta część jest dla osoby zarządzającej Twoją domeną lub DNS — jeśli to nie Ty, przekaż jej tę sekcję. Poprawka jest darmowa; pobieramy opłatę tylko za pilnowanie, że pozostaje naprawiona.

Krok 1 — Upewnij się, że masz co najmniej dwa serwery nazw na różnorodnej infrastrukturze.

1. Sprawdź, co masz dziś. Uruchom dig NS twojadomena.pl (lub użyj dowolnego narzędzia „DNS lookup” w sieci) i odczytaj serwery nazw. Dwa lub więcej to minimum.
2. Jeśli masz tylko jeden albo oba są na jednym małym hoście, przenieś DNS do dostawcy, który daje redundancję domyślnie. Praktycznie każdy poważny dostawca to robi:
   • Cloudflare — przydziela dwa serwery nazw rozrzucone po globalnej sieci Anycast automatycznie, gdy dodajesz domenę.
   • AWS Route 53 — każda strefa hostowana dostaje cztery serwery nazw w osobnych sieciach Route 53.
   • Google Cloud DNS / Microsoft 365 / Azure DNS — podobnie udostępniają wiele serwerów nazw na niezależnej infrastrukturze.
3. By przełączyć, ustaw serwery nazw swojej domeny u rejestratora (gdzie kupiłeś domenę — np. GoDaddy, Namecheap) na te, które daje Twój nowy dostawca DNS. Ta zmiana może zająć 24–48 godzin, by w pełni się rozejść.
4. Dla odporności pas i szelki większe lub bardziej ryzykowne firmy mogą uruchomić drugorzędny DNS u drugiego niezależnego dostawcy (np. Cloudflare + Route 53 lub NS1 + Cloudflare). Dla większości małych firm to opcjonalne — pojedynczy renomowany dostawca już daje Ci prawdziwą redundancję między sieciami.

Krok 2 — Sprawdź (i w razie potrzeby napraw) liczniki SOA.

1. Uruchom dig SOA twojadomena.pl i odczytaj wartości refresh, retry, expire i minimum-TTL.
2. Porównaj je z zakresami powyżej. W zdecydowanej większości przypadków Twój dostawca DNS już ustawił rozsądne wartości domyślne i nie ma nic do roboty.
3. Jeśli wartość jest poza zakresem, napraw ją tam, gdzie hostowany jest Twój DNS:
   • U dostawców zarządzanych (Cloudflare, Route 53, Google, Azure) SOA jest w dużej mierze załatwiany za Ciebie; zwykle dostosowujesz go przez ustawienia DNS dostawcy lub wsparcie, a nie edytując go ręcznie.
   • Na samodzielnie prowadzonym serwerze nazw (BIND, PowerDNS) edytuj linię SOA w pliku strefy bezpośrednio i przeładuj strefę — pamiętając, by podbić numer seryjny, by serwery drugorzędne wychwyciły zmianę.
4. Po każdej zmianie uruchom sprawdzenia ponownie, by potwierdzić, że lista serwerów nazw i liczniki SOA wyglądają dobrze.

Częste błędy

• Traktowanie „dwóch nazw” jako „dwóch sieci”. Dwie nazwy serwerów nazw, które rozwiązują się do tej samej maszyny lub szafy, to pojedynczy punkt awarii w przebraniu. Liczą się niezależne ścieżki sieciowe, nie liczba nazw.
• Zakładanie, że więcej zawsze lepiej, bez różnorodności. Pięć serwerów nazw wszystkich na jednym kruchym hoście nie jest bezpieczniejsze niż jeden. Różnorodność bije ilość.
• Ustawianie liczników zbyt agresywnie. Skręcanie refresh lub minimum-TTL SOA w dół do „zmiany natychmiastowe” po prostu młotkuje Twoje serwery nazw i może pogorszyć awarie, z niewielką realną korzyścią. Rozsądne wartości domyślne już równoważą szybkość z obciążeniem.
• Ustawianie expire zbyt nisko. Jeśli serwery drugorzędne przestają serwować Twoją strefę zbyt szybko podczas awarii głównego, możliwa do odzyskania usterka staje się pełną awarią. Trzymaj expire w zakresie tygodni.
• Edytowanie strefy ręcznie i zapomnienie o numerze seryjnym. Na samodzielnie prowadzonych serwerach nazw serwery drugorzędne wychwytują zmiany tylko, gdy numer seryjny SOA rośnie. Zmień rekordy, lecz zostaw numer seryjny, a Twoja „poprawka” nigdy się nie rozejdzie.
• Pozostawienie DNS na nagiej wartości domyślnej rejestratora domeny. Wbudowany DNS niektórych rejestratorów to pojedyncza, minimalna konfiguracja. Przeniesienie DNS do prawdziwego dostawcy zwykle daje Ci redundancję i rozsądne liczniki SOA w jednym ruchu.

Podsumowanie

Twoje serwery nazw i ich rekord SOA to fundament, na którym siedzi wszystko inne. Dwa serwery nazw w naprawdę osobnych sieciach oznaczają, że pojedyncza awaria nie może wyłączyć całej Twojej firmy naraz; rozsądne liczniki SOA oznaczają, że zmiany, które wprowadzasz, faktycznie szybko docierają do świata. Oba są darmowe do poprawnego ustawienia, oba są zwykle już w dobrym stanie w chwili, gdy jesteś u właściwego dostawcy DNS, i oba są warte dwuminutowego sprawdzenia — bo dzień, w którym się liczą, to dzień, w którym najmniej możesz sobie pozwolić, by były błędne.

Najczęstsze pytania