DNS: co to jest, jak działa i kiedy wpływa na SEO?

Działający serwer nie wystarczy, jeśli domena prowadzi w złe miejsce. Zanim przeglądarka pobierze stronę, DNS musi wskazać adres usługi obsługującej nazwę taką jak example.com. Błędna albo brakująca odpowiedź może więc wyłączyć witrynę, pocztę i integracje, mimo że poszczególne serwery nadal działają.

Jak DNS łączy domenę z usługami?

DNS (Domain Name System), czyli system nazw domen, jest rozproszonym systemem informacji o domenach. Nie jest pojedynczym serwerem ani wyłącznie „książką telefoniczną internetu”. W rekordach DNS można zapisać adresy IPv4 i IPv6, wskazać inny host, określić serwery obsługujące strefę i pocztę, a także potwierdzić własność domeny w zewnętrznych usługach.

Użytkownik zwykle nie komunikuje się bezpośrednio z serwerem autorytatywnym domeny. Prośbę przeglądarki lub systemu operacyjnego obsługuje rekurencyjny resolver DNS — na przykład resolver operatora, firmowej sieci albo wybranej usługi publicznej. Resolver znajduje odpowiedź i zapisuje ją w pamięci podręcznej.

Jak działa zapytanie DNS krok po kroku?

Przy pierwszym wejściu na stronę proces może wyglądać następująco:

1. Przeglądarka i system operacyjny sprawdzają, czy mają jeszcze aktualną odpowiedź w pamięci podręcznej.
2. Jeśli jej nie mają, pytanie trafia do rekurencyjnego resolvera.
3. Resolver również najpierw sprawdza własny cache.
4. Gdy odpowiedzi brakuje, resolver pyta serwer główny, gdzie szukać informacji o danej domenie najwyższego poziomu, na przykład .pl.
5. Serwer TLD wskazuje autorytatywne serwery nazw właściwej domeny.
6. Serwer autorytatywny zwraca odpowiedni rekord, na przykład A albo AAAA.
7. Resolver przekazuje odpowiedź urządzeniu i przechowuje ją zgodnie z wartością TTL.

Jeżeli potrzebny rekord jest już w cache, większość tej ścieżki nie jest wykonywana ponownie. To właśnie dlatego dwie osoby mogą przez pewien czas otrzymywać różne odpowiedzi po zmianie konfiguracji DNS.

W tym opisie zapytanie urządzenia do resolvera jest rekurencyjne: klient oczekuje gotowej odpowiedzi. Pytania resolvera do kolejnych serwerów są zwykle iteracyjne — otrzymuje odpowiedź albo wskazanie, gdzie pytać dalej. Właściciel strony nie musi konfigurować tego procesu, ale powinien rozumieć, skąd mogą brać się opóźnienia i różne wyniki diagnostyki.

Najważniejsze rekordy DNS dla strony i sklepu

W panelu operatora domeny lub dostawcy DNS zobaczysz rekordy o różnych funkcjach. Dla strony internetowej, sklepu i usług marketingowych najczęściej znaczenie mają:

CNAME nie jest przekierowaniem HTTP. Przeglądarka nie otrzymuje kodu 301 ani nowego adresu URL — resolver kontynuuje wyszukiwanie wskazanej nazwy. Z kolei zmiana NS ma znacznie szerszy zakres niż edycja pojedynczego A lub CNAME, ponieważ może przenieść obsługę całej strefy do innego operatora.

TTL i propagacja DNS — kiedy zmiana będzie widoczna?

TTL (Time to Live) określa, jak długo resolver może przechowywać odpowiedź w pamięci podręcznej przed ponownym sprawdzeniem rekordu. Jeśli rekord A miał TTL równy 3600 sekund, resolver może korzystać ze starej odpowiedzi przez godzinę od chwili jej zapisania.

Popularne określenie „propagacja DNS” bywa mylące. Zmiana nie rozchodzi się po internecie jak plik kopiowany między serwerami. Nowy rekord może być już dostępny na serwerze autorytatywnym, podczas gdy część resolverów nadal ma w cache wcześniejszą odpowiedź. Dodatkowe zasady dotyczą zmian delegacji NS i odpowiedzi negatywnych, dlatego nie da się uczciwie obiecać jednego czasu dla każdej operacji.

Jaki TTL ustawić przed migracją?

Przy stabilnej konfiguracji dłuższy TTL ogranicza liczbę ponownych zapytań. Przed planowaną zmianą hostingu warto go czasowo obniżyć, aby stare odpowiedzi szybciej wygasły. Google w instrukcji zmiany hostingu podaje jako rozsądny przykład TTL rzędu kilku godzin ustawiony co najmniej tydzień przed migracją.

Po udanym przełączeniu i zakończeniu obserwacji można wrócić do docelowej wartości. Utrzymywanie bardzo niskiego TTL bez potrzeby zwiększa liczbę zapytań i nie daje samo w sobie korzyści SEO.

Jak DNS wpływa na SEO i wynik biznesowy?

DNS nie jest ustawieniem, które podnosi pozycje po wpisaniu „lepszej” wartości. Jego wpływ zaczyna się wcześniej: użytkownik i robot muszą najpierw odnaleźć host, zanim pobiorą stronę.

Problemy z DNS można zobaczyć w raporcie statystyk indeksowania w Google Search Console. Stan hosta rozdziela błędy pobierania robots.txt, rozwiązywania DNS oraz połączenia z serwerem. Jeżeli Googlebot regularnie nie może rozwiązać nazwy, dostępność ogranicza crawlowanie. Po usunięciu awarii warto sprawdzić, czy robot wrócił do ważnych klas URL-i i jak zmieniły się statystyki crawl budgetu.

Czas rozwiązania nazwy jest jednym z etapów poprzedzających połączenie. Dalszą część drogi — odpowiedź serwera, pobieranie zasobów, renderowanie i interakcję — diagnozujemy osobno, między innymi za pomocą Core Web Vitals.

Jak sprawdzić rekordy DNS i znaleźć problem?

Na macOS i Linuksie podstawowe informacje można odczytać poleceniem dig:

1
2
3
4
5
6

dig A example.com
dig AAAA example.com
dig CNAME www.example.com
dig NS example.com
dig TXT example.com

Wynik pokazuje między innymi status odpowiedzi, sekcję ANSWER i TTL. Najczęściej spotkasz:

• NOERROR — zapytanie zostało poprawnie obsłużone; nie zawsze oznacza, że sekcja ANSWER zawiera oczekiwany rekord,
• NXDOMAIN — wskazana nazwa nie istnieje,
• SERVFAIL — resolver nie mógł zwrócić poprawnej odpowiedzi, na przykład z powodu błędu serwera autorytatywnego albo walidacji DNSSEC.

Pojedyncze sprawdzenie nie zawsze wystarczy. Po zmianie porównaj odpowiedź serwera autorytatywnego z odpowiedziami kilku resolverów i sprawdź osobno A oraz AAAA. Zdarza się, że poprawny IPv4 maskuje stary rekord IPv6, przez co strona działa tylko części użytkowników. W Windowsie do podstawowego sprawdzenia można użyć nslookup.

Jeśli problem dotyczy widoczności w Google, sprawdź również stan hosta w Google Search Console, zamiast oceniać sytuację wyłącznie na podstawie tego, czy strona otwiera się na jednym komputerze.

Checklista przed zmianą hostingu lub DNS

Przełączenie warto potraktować jak zmianę produkcyjną, a nie pojedynczą edycję w panelu domeny:

1. Zrób inwentaryzację całej strefy. Zapisz A, AAAA, CNAME, NS, MX, TXT oraz rekordy używane przez zewnętrzne usługi.
2. Obniż TTL z wyprzedzeniem. Zrób to przed migracją, kiedy w cache nie ma jeszcze starych odpowiedzi z długim czasem życia.
3. Skonfiguruj i przetestuj nowy hosting. Sprawdź aplikację, certyfikat HTTPS, formularze, płatności, integracje i analitykę przed publicznym przełączeniem.
4. Przenieś rekordy niezwiązane bezpośrednio z WWW. To szczególnie ważne przy zmianie NS, która obejmuje całą strefę.
5. Nie wyłączaj od razu starego środowiska. Część resolverów może jeszcze kierować użytkowników na poprzedni adres.
6. Monitoruj oba środowiska. Kontroluj błędy, ruch, konwersje, pocztę i stan hosta w Search Console.
7. Zachowaj możliwość wycofania zmiany. Zapisz stare wartości i ustal, kto podejmuje decyzję o rollbacku.
8. Po stabilizacji przywróć docelowy TTL. Najpierw potwierdź, że nowe odpowiedzi są widoczne i wszystkie usługi działają.

DNSSEC, DoH i DoT chronią różne elementy

Te trzy mechanizmy bywają wrzucane do jednego worka, ale rozwiązują inne problemy:

DNSSEC ogranicza ryzyko przyjęcia sfałszowanej odpowiedzi, ale błędna konfiguracja łańcucha zaufania może spowodować SERVFAIL u resolverów, które prowadzą walidację. DoH i DoT utrudniają podsłuchanie lub modyfikację zapytania na odcinku klient–resolver. Nie oznacza to pełnej anonimowości — operator wybranego resolvera nadal obsługuje zapytanie. Mechanizmy te są komplementarne, co wyjaśnia również dokumentacja bezpieczeństwa Google Public DNS.