DNS wytłumaczony prosto – co się dzieje między kupnem domeny a działającą stroną

Aktualizacja: wrzesień 2026

Informacja: ten materiał może zawierać linki afiliacyjne. Jeżeli skorzystasz z takiego linku i dokonasz zakupu, PICKNIVO może otrzymać prowizję. Nie zwiększa to ceny po Twojej stronie.

Wyobraź sobie DNS jako książkę telefoniczną internetu: Ty znasz nazwę (np. twojafirma.pl), a DNS odnajduje w niej numer, pod którym faktycznie mieszka Twoja strona (adres IP serwera). Problem w tym, że ta „książka telefoniczna” nie jest jedna – kopie trzyma tysiące serwerów na całym świecie, i kiedy zmieniasz w niej wpis, nie wszystkie od razu dostają aktualizację. Kupiłeś domenę, a zamiast swojej strony widzisz pustą stronę rejestratora albo błąd w przeglądarce. To nie oznacza, że coś zepsułeś — to najczęściej normalny, przejściowy etap między zakupem domeny a momentem, w którym cały internet „dowie się”, gdzie ma szukać Twojej strony. Winowajcą jest zwykle DNS (Domain Name System) i czas potrzebny na tzw. propagację zmian.

Ten artykuł tłumaczy krok po kroku, co właściwie dzieje się między kupnem domeny a działającą stroną: kto za co odpowiada, co oznaczają rekordy DNS widoczne w panelu, dlaczego trzeba czasem poczekać, oraz jak odróżnić „jeszcze się propaguje” od „coś jest źle skonfigurowane”. Nie jest to poradnik krok po kroku do konfiguracji jednego konkretnego hostingu — do tego służą osobne poradniki PICKNIVO, do których linkujemy na końcu.

Trzy różne rzeczy, które łatwo pomylić: rejestrator, DNS, hosting

Zanim przejdziemy do mechaniki, warto rozdzielić trzy usługi, które początkujący najczęściej traktują jak jedną rzecz:

• Rejestrator domen — firma, u której kupujesz i rejestrujesz nazwę domeny (np. twojafirma.pl).
• Host DNS — usługa, która przechowuje i odpowiada na zapytania o rekordy DNS Twojej domeny (tzw. strefę DNS) i decyduje, gdzie kierowany jest ruch.
• Hosting www — miejsce, gdzie fizycznie leżą pliki Twojej strony.

To trzy logicznie odrębne usługi. Bardzo często są sprzedawane razem przez jedną firmę — wygodne rozwiązanie dla początkujących — ale równie dobrze można je rozdzielić: domenę kupić u jednego rejestratora, DNS trzymać u innego dostawcy, a stronę hostować jeszcze gdzie indziej.

W Polsce domenami .pl administruje NASK, który prowadzi oficjalny Krajowy Rejestr Domen. Użytkownicy nie rejestrują domeny bezpośrednio w NASK — robią to za pośrednictwem akredytowanych rejestratorów, którzy mają podpisaną umowę z NASK. Dlatego kupując domenę .pl, zawsze masz do czynienia z pośrednikiem, nie z samym rejestrem.

Co właściwie robi DNS, gdy wpisujesz adres strony

DNS to hierarchiczny, rozproszony system, którego zadaniem jest tłumaczenie nazw domen czytelnych dla człowieka (np. twojafirma.pl) na adresy IP, które rozumieją komputery i serwery. W praktyce, kiedy wpisujesz adres strony w przeglądarce, dzieje się seria zapytań:

1. Przeglądarka pyta resolver DNS (najczęściej serwer Twojego dostawcy internetu), czy zna adres tej domeny.
2. Jeśli resolver nie ma odpowiedzi w pamięci podręcznej, pyta serwer główny (root), który kieruje go do serwera odpowiedzialnego za daną końcówkę domeny (np. .pl albo .com).
3. Serwer TLD wskazuje serwery nazw (nameservery) odpowiedzialne konkretnie za Twoją domenę.
4. Resolver pyta te serwery (tzw. autorytatywne) o właściwy rekord i otrzymuje odpowiedź, np. adres IP.
5. Odpowiedź wraca do przeglądarki, a resolver zapamiętuje ją na jakiś czas, żeby nie powtarzać całej ścieżki przy kolejnym zapytaniu.

To zapamiętywanie ma dwa poziomy. Resolver, który raz ustalił, jakie serwery nazw obsługują Twoją domenę, przechowuje tę informację — dokumentacja Amazon Route 53 podaje jako przykładowy, typowy czas około dwóch dni, ale to ilustracja, a nie uniwersalna reguła obowiązująca każdego dostawcę. Osobno, każdy konkretny rekord (np. adres IP strony) ma swój własny czas ważności w pamięci podręcznej — o tym za chwilę, przy okazji propagacji.

Rekordy DNS wytłumaczone po ludzku

W panelu zarządzania domeną prędzej czy później zobaczysz listę rekordów. Oto co naprawdę robią te najważniejsze.

A i AAAA — adres serwera

Rekord A wskazuje, pod jakim adresem IPv4 znajduje się dana domena lub subdomena — to podstawowy rekord, dzięki któremu domena w ogóle prowadzi do serwera Twojej strony. Rekord AAAA robi dokładnie to samo, tylko dla nowszego adresu IPv6.

CNAME — alias, nie adres

Rekord CNAME nie wskazuje adresu IP, tylko inną nazwę domenową — jest aliasem. Resolver, trafiając na CNAME, „idzie” pod wskazaną nazwę i dopiero tam szuka właściwego adresu. Ma to dwa ważne ograniczenia: CNAME nie może być ustawiony na samej głównej domenie (tzw. root/apex) i nie może współistnieć z innym rekordem (np. MX) przy tej samej nazwie. To jeden z najczęstszych błędów konfiguracji popełnianych przez początkujących.

MX — gdzie trafia poczta

Rekord MX określa, który serwer (lub serwery) odbiera pocztę e-mail dla domeny. Każdy MX ma numer priorytetu — im niższy, tym wcześniej próbowany, co pozwala ustawić serwer zapasowy na wypadek awarii głównego. Cel MX musi być nazwą hosta, która sama ma swój rekord A/AAAA — nie może to być goły adres IP. Błędne wskazanie adresu IP zamiast nazwy hosta to częsta przyczyna problemów z pocztą.

NS — kto zarządza strefą

Rekord NS deleguje zarządzanie strefą DNS domeny do konkretnych serwerów nazw. Przy rejestracji domeny standardowo wymaga się wskazania co najmniej dwóch serwerów nazw — dla redundancji, na wypadek awarii jednego z nich.

TXT — miejsce na dane tekstowe (SPF/DKIM/DMARC)

Rekord TXT przechowuje dowolny tekst. W praktyce najczęściej służy do publikowania danych uwierzytelniających pocztę (SPF, DKIM, DMARC) oraz kodów weryfikacyjnych używanych przez zewnętrzne usługi (np. Google Search Console).

Warto rozumieć różnicę między tymi trzema mechanizmami, bo „dodanie jednego rekordu” nie rozwiązuje całego tematu bezpieczeństwa poczty:

• SPF to rekord TXT, który wskazuje, jakie serwery mają prawo wysyłać pocztę w imieniu domeny. Sprawdza jednak tylko ukryty adres „koperty” (technicznego nadawcy), a nie widoczny w kliencie poczty adres „Od” — dlatego samo SPF nie zatrzyma podszywania się pod widoczną nazwę nadawcy.
• DKIM dodaje kryptograficzny podpis do wysyłanej wiadomości, weryfikowany kluczem publicznym opublikowanym w DNS. Potwierdza integralność i autentyczność nadawcy, ale sam w sobie nie mówi odbiorcy, co zrobić, gdy weryfikacja się nie powiedzie.
• DMARC spina to wszystko w całość: wymaga, żeby SPF lub DKIM przeszły i były zgodne z domeną widoczną w polu „Od”, a dodatkowo mówi serwerom odbierającym, jak traktować wiadomości, które tego testu nie przejdą (odrzucić, poddać kwarantannie albo tylko monitorować), i umożliwia raportowanie z powrotem do właściciela domeny.

Jeśli więc ktoś ustawi samo SPF i uzna temat za zamknięty, może się mylić — pełna ochrona wymaga świadomego ułożenia wszystkich trzech elementów.

Propagacja DNS: dlaczego trzeba poczekać

To najczęstsze źródło frustracji po zmianie ustawień domeny. Propagacja DNS to okres po zmianie rekordu, w którym serwery resolverów na całym świecie wciąż trzymają w pamięci starą odpowiedź, dopóki nie wygaśnie i nie zapytają ponownie serwera autorytatywnego o nową wartość.

Kluczowe pojęcie to TTL (Time To Live) — wartość w sekundach ustawiona na każdym rekordzie, mówiąca resolverom, jak długo mogą serwować odpowiedź z pamięci podręcznej, zanim muszą zapytać ponownie. Im wyższy TTL, tym dłużej po zmianie część użytkowników może jeszcze widzieć starą wersję. Nie ma jednej uniwersalnej wartości domyślnej — różni dostawcy posługują się różnymi przykładami, od 3600 sekund (1 godzina) po 86 400 sekund (24 godziny).

Ile realnie trzeba czekać?

Powiedzmy wprost: źródła podają różne liczby i żadnej z nich nie warto traktować jako jedynej prawdy.

Przesuń tabelę w bok, aby zobaczyć wszystkie kolumny →

Uczciwa odpowiedź brzmi: to zależy od TTL danego rekordu oraz od tego, jak rygorystycznie dostawca internetu odbiorcy respektuje ten TTL. Realistycznie mówimy o zakresie od kilku minut (przy krótkim TTL) do około 2–3 dni w skrajnych przypadkach, przy czym większość odwiedzających zobaczy zmianę w ciągu kilku godzin. Żadna pojedyncza liczba podana przez jednego dostawcę nie powinna być traktowana jako gwarancja dla wszystkich.

Jest jeszcze jeden czynnik, o którym mało kto pisze: część dostawców internetu ignoruje ustawiony TTL i odświeża własną pamięć podręczną tylko co 2–3 dni, niezależnie od tego, co mówi rekord. To jedno z wyjaśnień, dlaczego niektórzy użytkownicy zgłaszają wyjątkowo długie oczekiwanie.

Jak przyspieszyć planowaną zmianę

Jeśli wiesz z wyprzedzeniem, że będziesz zmieniać rekord (np. przy migracji hostingu), obniż TTL tego rekordu do około 300 sekund na 24–48 godzin przed planowaną zmianą. Dzięki temu resolvery, które w międzyczasie odświeżą się przy krótkim TTL, po faktycznej zmianie odbiorą nową wartość w ciągu minut, a nie godzin czy dni.

Jak sprawdzić, czy to już działa, czy coś jest źle skonfigurowane

Zanim założysz, że problemem jest wyłącznie propagacja, warto to zweryfikować.

Darmowe narzędzia do sprawdzania propagacji. Publicznie dostępne strony (przykładowo dnschecker.org, wymieniany przez jednego z polskich dostawców hostingu w jego bazie wiedzy) pokazują, dla poszczególnych typów rekordów, czy zmiana dotarła już do resolverów w różnych lokalizacjach na świecie. To najszybszy sposób, żeby zobaczyć realny stan zamiast zgadywać.

Typowy komunikat błędu. W przeglądarkach z rodziny Chrome charakterystycznym objawem całkowitego braku rozwiązania domeny jest błąd DNS_PROBE_FINISHED_NXDOMAIN — oznacza on, że przeglądarka w ogóle nie mogła znaleźć żadnego adresu IP dla wpisanej domeny. To sygnał wart odnotowania, choć bez sprawdzenia propagacji trudno od razu stwierdzić, czy to kwestia czasu, czy błędu w konfiguracji.

Kiedy to NIE jest propagacja. Propagację zbyt łatwo obwinia się za wszystko. W praktyce, jeśli po kilku dniach strona wciąż nie działa, warto sprawdzić inne, bardziej prawdopodobne przyczyny:

• rekord CNAME ustawiony na głównej domenie albo obok innego rekordu przy tej samej nazwie (patrz sekcja o CNAME wyżej),
• rekord MX wskazujący bezpośrednio na adres IP zamiast na nazwę hosta,
• domena wciąż wskazuje na domyślne serwery nazw rejestratora, mimo że DNS miał zostać przeniesiony gdzie indziej,
• zwykła literówka w adresie IP lub nazwie hosta.

Żadna z tych sytuacji nie „naprawi się sama” z czasem — to błędy konfiguracji, a nie kwestia oczekiwania.

Domeny .pl — na co zwrócić uwagę

Domenami .pl administruje NASK poprzez Krajowy Rejestr Domen, a rejestracji dokonuje się wyłącznie przez akredytowanych rejestratorów.

Aktualne zasady nazewnictwa (warto zawsze zweryfikować je u swojego rejestratora, bo regulamin NASK może się zmieniać) obejmują między innymi: dozwolone są litery łacińskie, cyfry i myślniki (a także polskie znaki diakrytyczne w wariantach IDN), maksymalna długość nazwy to 63 znaki bez końcówki, nazwa nie może zaczynać się ani kończyć myślnikiem, ani mieć myślników jednocześnie na 3. i 4. pozycji, a zastrzeżonych nazw usługowych, takich jak „www”, „ftp”, „http” czy „https”, nie można zarejestrować jako całej nazwy domeny.

Ściągawka: od zakupu domeny do działającej strony

1. Kupujesz domenę u akredytowanego rejestratora (w przypadku .pl — zawsze pośrednio, przez rejestratora współpracującego z NASK).
2. Ustawiasz, gdzie ma wskazywać DNS domeny — u samego rejestratora, u dostawcy hostingu albo u zewnętrznego dostawcy DNS.
3. W strefie DNS dodajesz rekordy: A/AAAA do serwera strony, ewentualnie MX do serwera poczty, CNAME dla aliasów (np. www), TXT dla weryfikacji i uwierzytelniania poczty.
4. Czekasz na propagację — od kilku minut do maksymalnie kilku dni, w zależności od TTL. W tym czasie widok „strony zaparkowanej” albo błąd w przeglądarce jest normalny.
5. Sprawdzasz stan propagacji narzędziem online zamiast zgadywać.
6. Jeśli po kilku dniach strona wciąż nie działa, szukasz błędu konfiguracji (zły rekord, złe serwery nazw, literówka), a nie kolejnego dnia czekania.

Co dalej — powiązane poradniki PICKNIVO

Ten artykuł tłumaczy mechanizm. Jeśli szukasz gotowego planu działania, sprawdź:

• Jak założyć stronę internetową od zera w 2026 — prosty plan
• Jak uruchomić stronę firmy w 60 minut — plan minimum
• Hostinger — jak ocenić ofertę przed zakupem hostingu