DNS - co to jest i jak działa system nazw domenowych?

DNS, czyli Domain Name System, to system nazw domenowych, który tłumaczy nazwy takie jak ewektor.pl na techniczne informacje potrzebne do połączenia z usługą: adres IP serwera WWW, serwer pocztowy, alias subdomeny albo rekord weryfikacyjny. Bez DNS użytkownik musiałby wpisywać adresy liczbowe serwerów zamiast domen.

W praktyce DNS jest mapą techniczną domeny. Od tej mapy zależy, czy działa strona, poczta, subdomeny, certyfikat SSL, CDN, sklep, panel klienta i integracje z zewnętrznymi usługami. Jeden błędny rekord potrafi zepsuć tylko pocztę, tylko wersję z www, tylko certyfikat albo całą domenę.

Co to jest DNS?

To rozproszony, hierarchiczny system przechowywania informacji o domenach. Domena sama w sobie nie jest jeszcze serwerem. Jest nazwą, a rekordy DNS mówią, gdzie ta nazwa ma prowadzić i jakie usługi są z nią powiązane.

Najprostszy przykład to rekord A. Jeśli domena example.pl ma rekord A wskazujący na konkretny adres IPv4, przeglądarka może połączyć się z serwerem pod tym adresem. Inne rekordy odpowiadają za IPv6, pocztę, aliasy, serwery nazw, bezpieczeństwo albo weryfikację usług zewnętrznych.

DNS jest szczególnie ważny przy hostingu. Możesz mieć domenę u rejestratora, stronę na osobnym serwerze, pocztę w Google Workspace albo Microsoft 365, sklep na zewnętrznej platformie i subdomenę na innym systemie. To wszystko spina się właśnie rekordami DNS.

Jak działa DNS krok po kroku?

Po wpisaniu domeny w przeglądarce komputer nie zna od razu adresu IP serwera. Najpierw musi zapytać DNS. Często odpowiedź jest pobierana z pamięci podręcznej, ale jeśli resolver jej nie ma, przechodzi przez kolejne poziomy systemu.

Przeglądarka pyta system operacyjny o adres IP domeny.
System pyta resolver DNS, najczęściej ustawiony przez operatora internetu, router albo publiczną usługę DNS.
Resolver sprawdza cache. Jeśli zna odpowiedź, zwraca ją od razu.
Jeżeli nie zna odpowiedzi, pyta serwery root, potem serwery TLD, a następnie serwer autorytatywny domeny.
Serwer autorytatywny zwraca właściwy rekord, na przykład A, AAAA, MX albo TXT.
Komputer może połączyć się z właściwą usługą.

W całym procesie kluczowe są cztery poziomy: resolver rekurencyjny, root nameserver, TLD nameserver i serwer autorytatywny. To nie są synonimy. Każdy z nich robi coś innego.

Element	Rola	Co to oznacza praktycznie?
Resolver DNS	Szuka odpowiedzi w imieniu użytkownika.	To jego pytasz, gdy komputer chce znać IP domeny.
Root nameserver	Wskazuje serwery dla domen najwyższego poziomu.	Dla `.pl` kieruje dalej do infrastruktury odpowiedzialnej za tę końcówkę.
TLD nameserver	Obsługuje końcówkę domeny, np. `.pl`, `.com`, `.org`.	Wskazuje, które serwery nazw są autorytatywne dla konkretnej domeny.
Serwer autorytatywny	Przechowuje właściwą strefę DNS domeny.	To tutaj znajdują się rekordy decydujące o stronie, poczcie i subdomenach.

Dlaczego root serverów jest 13, ale nie tylko 13 fizycznych maszyn?

W DNS często mówi się o 13 root serverach, ale chodzi o 13 nazwanych autorytetów, oznaczanych od a.root-servers.net do m.root-servers.net. Za tymi nazwami stoi wiele fizycznych instancji rozmieszczonych w różnych lokalizacjach na świecie.

Do takiej dystrybucji używa się między innymi Anycast. W uproszczeniu: ta sama usługa może być ogłaszana z wielu miejsc, a ruch trafia do jednej z dostępnych instancji według decyzji routingu. Dzięki temu DNS root jest odporniejszy, szybszy i mniej zależny od pojedynczej lokalizacji.

Strefa DNS, SOA i serwery nazw

Strefa DNS to zestaw rekordów opisujących domenę. Można ją traktować jak plik konfiguracyjny domeny: zawiera informacje o stronie WWW, poczcie, subdomenach, aliasach, weryfikacjach i ustawieniach bezpieczeństwa.

Na początku strefy znajduje się rekord SOA, czyli Start of Authority. To rekord techniczny opisujący autorytatywną strefę DNS. Zawiera między innymi informacje potrzebne serwerom DNS do obsługi strefy, synchronizacji i cache’owania odpowiedzi negatywnych.

Rekordy NS wskazują serwery nazw odpowiedzialne za domenę. To one decydują, gdzie trzeba edytować rekordy. Jeśli domena ma ustawione serwery nazw Cloudflare, realna strefa jest w Cloudflare. Jeśli domena używa DNS hostingu, zmiany trzeba robić w panelu hostingu. Edycja rekordów w nieaktywnej strefie nie zmieni nic w internecie.

Najważniejsze rekordy

Nie trzeba znać wszystkich typów rekordów DNS, ale podstawowe rekordy warto rozumieć. Przy większości prac z domeną, hostingiem i pocztą wracają ciągle te same typy: A, AAAA, CNAME, MX, TXT, NS, SOA i czasem CAA.

Rekord	Do czego służy?	Typowy przykład
`A`	Wskazuje adres IPv4.	Domena główna kieruje na IP hostingu.
`AAAA`	Wskazuje adres IPv6.	Strona działa także po IPv6.
`CNAME`	Tworzy alias jednej nazwy na inną nazwę domenową.	`www` wskazuje na domenę główną albo usługę zewnętrzną.
`MX`	Wskazuje serwery obsługujące pocztę.	Poczta działa w Google, Microsoft albo na hostingu.
`TXT`	Przechowuje informacje tekstowe dla usług zewnętrznych.	SPF, DKIM, DMARC, weryfikacja domeny w narzędziach.
`NS`	Wskazuje serwery nazw domeny.	Domena używa DNS danego operatora.
`SOA`	Opisuje autorytatywną strefę DNS.	Wpływa między innymi na obsługę odpowiedzi negatywnych.
`CAA`	Ogranicza urzędy certyfikacji mogące wystawić certyfikat.	Domena pozwala wystawiać certyfikaty tylko wybranym CA.
`SRV`	Wskazuje usługę, host i port.	Niektóre konfiguracje VoIP, komunikatorów i usług firmowych.

CNAME, apex domeny i ograniczenie z RFC 1034

Rekord CNAME jest wygodny, ale ma ważne ograniczenie: nazwa, która ma rekord CNAME, nie powinna mieć żadnych innych rekordów. Wynika to z zasady opisanej w RFC 1034. Alias ma być aliasem, a nie jednocześnie nazwą z własnym zestawem rekordów.

To tłumaczy, dlaczego zwykły CNAME nie powinien być ustawiany na domenie głównej, czyli apexie strefy, na przykład example.pl. Na apexie muszą już istnieć rekordy SOA i NS, a często także MX i TXT. Gdyby apex był zwykłym CNAME, kolidowałby z tymi rekordami.

W praktyce: dla subdomeny, na przykład www.example.pl, zwykle można użyć CNAME. Dla domeny głównej trzeba zastosować rekordy A/AAAA albo funkcję operatora DNS typu ALIAS, ANAME lub CNAME Flattening.

CNAME Flattening działa tak, że operator DNS sam rozwiązuje wskazaną nazwę do adresów IP i zwraca użytkownikowi rekordy adresowe. Z zewnątrz nie jest to zwykły CNAME na apexie, tylko mechanizm dostawcy DNS, który daje wygodę aliasu bez złamania podstawowego modelu strefy.

MX i NS nie powinny wskazywać na CNAME

Rekordy MX i NS powinny wskazywać na nazwy, które mają poprawne rekordy adresowe, a nie na aliasy CNAME. W przeciwnym razie można doprowadzić do niejednoznacznej albo problematycznej konfiguracji poczty i delegacji DNS.

Jeśli operator poczty podaje serwer mx.example-mail.com, należy wpisać dokładnie ten host jako wartość MX. Nie tworzy się po drodze własnego aliasu CNAME dla serwera pocztowego, jeśli instrukcja usługi tego nie wymaga.

DNS, strona WWW i poczta

Strona internetowa najczęściej zależy od rekordów A, AAAA albo CNAME. Domena główna może wskazywać na IP serwera, a wersja www może być aliasem do domeny głównej lub zewnętrznej usługi.

Poczta działa osobno. Za odbieranie wiadomości odpowiadają rekordy MX. To dlatego strona może działać poprawnie, a poczta jednocześnie może być zepsuta. Te dwie rzeczy nie muszą korzystać z tego samego serwera.

Rekordy TXT: SPF, DKIM i DMARC

Rekordy TXT są często traktowane jak dodatki, ale w poczcie są krytyczne. SPF określa, które serwery mogą wysyłać wiadomości w imieniu domeny. DKIM dodaje podpis kryptograficzny do wiadomości. DMARC mówi odbiorcom, co robić z wiadomościami, które nie przechodzą weryfikacji.

Błędy w rekordach TXT nie zawsze powodują całkowite zatrzymanie poczty. Częściej pogarszają dostarczalność. Wiadomości mogą trafiać do spamu, być oznaczane jako podejrzane albo odrzucane przez bardziej rygorystyczne serwery odbiorcze.

TTL, cache i propagacja zmian

TTL, czyli Time To Live, określa, jak długo odpowiedź DNS może być przechowywana w pamięci podręcznej resolvera. Dzięki cache DNS internet działa szybciej, bo resolver nie pyta za każdym razem autorytatywnego serwera o tę samą domenę. Cena za to jest prosta: zmiany DNS nie zawsze są widoczne natychmiast.

Jeśli rekord miał TTL ustawiony na 3600 sekund, resolver może trzymać starą odpowiedź przez około godzinę. Jeśli TTL wynosił 86400 sekund, stara odpowiedź może utrzymywać się znacznie dłużej. Dlatego przed migracją strony albo poczty często obniża się TTL z wyprzedzeniem.

Negative caching i rola rekordu SOA

Cache DNS dotyczy nie tylko poprawnych odpowiedzi. Resolver może zapamiętać także odpowiedź negatywną: że dana nazwa nie istnieje albo że istnieje nazwa, ale nie ma rekordu danego typu. To zjawisko nazywa się negative caching.

Przykład: tworzysz subdomenę panel.example.pl, ale zanim dodasz rekord DNS, ktoś już ją sprawdził. Resolver dostał odpowiedź NXDOMAIN, czyli informację, że nazwa nie istnieje. Po chwili dodajesz rekord poprawnie, ale część resolverów może nadal pamiętać wcześniejszą odpowiedź negatywną.

Czas takiego cache’owania wynika z danych SOA w odpowiedzi autorytatywnej. W RFC 2308 opisano, że odpowiedź negatywna powinna zawierać rekord SOA, a TTL dla tej odpowiedzi jest brany z minimum pola SOA.MINIMUM i TTL samego rekordu SOA. Dlatego przy trudnych przypadkach „dodałem rekord, a dalej nie działa” problemem nie zawsze jest zwykły TTL rekordu, którego wcześniej nie było.

Jak przygotować zmianę DNS?

Przed migracją warto obniżyć TTL dla rekordów, które będą zmieniane. Nie robi się tego pięć minut przed zmianą, tylko wcześniej, aby stare wartości TTL zdążyły wygasnąć w cache resolverów. Po zakończeniu migracji TTL można podnieść z powrotem.

Przy nowych subdomenach najlepiej najpierw dodać rekord, a dopiero potem testować adres w przeglądarce, narzędziach SEO albo checkerach DNS. Masowe sprawdzanie nieistniejącej jeszcze nazwy może utrwalić odpowiedź negatywną w resolverach i wprowadzić niepotrzebne opóźnienie diagnostyczne.

Migracja hostingu bez psucia poczty

Przy zmianie hostingu są dwa bezpieczne scenariusze. Pierwszy to przeniesienie całych serwerów nazw do nowego operatora. Wtedy trzeba odtworzyć pełną strefę DNS: stronę, pocztę, subdomeny, SPF, DKIM, DMARC, rekordy weryfikacyjne i ewentualne rekordy niestandardowe.

Drugi scenariusz to pozostawienie obecnych serwerów nazw i zmiana tylko konkretnych rekordów, na przykład A dla domeny i CNAME dla www. To często bezpieczniejsze, jeśli poczta działa u zewnętrznego operatora i nie chcemy jej przypadkiem ruszać.

Co zmieniasz?	Ryzyko	Co sprawdzić przed zmianą?
Serwery nazw `NS`	Możesz zgubić całą starą strefę DNS.	Eksport starej strefy, rekordy poczty, subdomeny, TXT.
Rekord `A` domeny	Strona może wskazać zły serwer.	Adres IP nowego hostingu, SSL, przekierowania.
Rekordy `MX`	Poczta może przestać dochodzić.	Pełna instrukcja operatora poczty.
Rekordy `TXT`	Pogorszenie dostarczalności maili albo utrata weryfikacji usług.	SPF, DKIM, DMARC, narzędzia Google, mailing, CRM.
Rekord `CAA`	Certyfikat SSL może się nie wystawić.	Czy wybrany urząd certyfikacji jest dozwolony.

Najgorsza migracja to jednoczesna zmiana hostingu, DNS, poczty i SSL bez spisania starej strefy. Wtedy trudno ustalić, który element faktycznie zawiódł.

Bezpieczeństwo, subdomeny i wpływ na SEO

Bezpieczeństwo domeny i DNSSEC

DNS jest krytyczny dla bezpieczeństwa domeny. Dostęp do panelu DNS pozwala przekierować stronę na inny serwer, zmienić pocztę, dodać rekord weryfikacyjny do obcej usługi albo zaburzyć działanie certyfikatów. Konto rejestratora i operatora DNS powinno mieć silne hasło oraz uwierzytelnianie dwuskładnikowe.

DNSSEC dodaje podpisy kryptograficzne do danych DNS, aby resolver mógł sprawdzić, czy odpowiedź nie została podmieniona. Nie zastępuje SSL i nie szyfruje treści strony. Przy zmianie operatora DNS trzeba jednak uważać na rekordy DS w delegacji domeny, bo zostawienie starych danych DNSSEC może unieruchomić domenę dla resolverów walidujących podpisy.

Subdomeny, wildcard i usługi zewnętrzne

Subdomena to nazwa utworzona pod domeną główną, na przykład blog.example.pl, panel.example.pl albo sklep.example.pl. Każda subdomena może mieć własny rekord A, AAAA, CNAME, TXT albo inny rekord wymagany przez usługę.

Rekord wildcard, na przykład *.example.pl, obsługuje wiele nieistniejących subdomen jednym wpisem. Może być użyteczny w aplikacjach SaaS, ale utrudnia diagnostykę, bo przypadkowa literówka w subdomenie też może zacząć kierować na serwer.

DNS a SEO

DNS nie zastępuje SEO i nie jest czynnikiem treściowym. Ma jednak znaczenie techniczne. Jeśli domena nie rozwiązuje się stabilnie, robot wyszukiwarki może mieć problem z dostępem do strony. Jeśli błędny rekord kieruje część ruchu na stary serwer, użytkownicy i roboty mogą widzieć różne wersje witryny.

Przy migracjach SEO najważniejsza jest ciągłość działania: właściwe rekordy dla domeny z www i bez www, działający SSL, poprawne przekierowania 301 i brak długiej przerwy w dostępności. DNS jest tutaj fundamentem technicznym, który ma być nudny i przewidywalny.

Jak sprawdzić DNS w praktyce?

Diagnostykę DNS trzeba zacząć od pytania: które serwery nazw są autorytatywne dla domeny? Dopiero potem ma sens sprawdzanie rekordów. Jeśli zmieniasz rekordy w panelu, który nie obsługuje aktywnej strefy, zmiany będą widoczne tylko w panelu, nie w realnym DNS.

Do sprawdzania używa się narzędzi takich jak dig, nslookup albo publiczne checkery DNS. Warto porównać odpowiedzi z różnych resolverów: operatora internetu, Google Public DNS, Cloudflare DNS albo Quad9.

Przykładowe komendy diagnostyczne

dig example.pl A
dig example.pl NS
dig example.pl SOA
dig example.pl MX
dig www.example.pl CNAME
dig panel.example.pl A
dig example.pl TXT

Przy problemach z cache można zapytać konkretny resolver:

dig @1.1.1.1 example.pl A
dig @8.8.8.8 example.pl A
dig @9.9.9.9 example.pl A

Jeśli różne resolvery zwracają różne odpowiedzi, zwykle oznacza to cache, trwającą propagację albo niespójność strefy. Jeśli wszystkie resolvery zwracają ten sam błędny wynik, problem prawdopodobnie leży w aktywnej strefie DNS.

Najczęstsze błędy w konfiguracji

Problem	Możliwa przyczyna	Co sprawdzić?
Strona nie działa po zmianie hostingu	Rekord `A` wskazuje stare IP albo odpowiedź jest w cache.	Aktywne `NS`, rekord `A`, TTL.
Działa domena bez `www`, ale nie działa `www`	Brakuje rekordu dla subdomeny `www`.	`CNAME` albo `A` dla `www`.
Poczta nie dochodzi	Błędne rekordy `MX`.	Docelowe serwery poczty i priorytety `MX`.
Wiadomości trafiają do spamu	Niepoprawny SPF, DKIM lub DMARC.	Rekordy `TXT` i źródła wysyłki poczty.
Nie można wystawić SSL	Domena nie wskazuje na serwer albo rekord `CAA` ogranicza urząd certyfikacji.	`A`, `AAAA`, `CAA`, konfiguracja serwera.
Dodałeś subdomenę, ale nadal „nie istnieje”	Resolver zapamiętał wcześniejszą odpowiedź `NXDOMAIN`.	Negative caching, `SOA`, różne resolvery.
Zmiany w panelu nie dają efektu	Edytowana jest nieaktywna strefa DNS.	Realne serwery nazw domeny.
Domena główna nie przyjmuje `CNAME`	Apex strefy ma już `SOA` i `NS`.	Czy operator obsługuje `ALIAS`, `ANAME` lub `CNAME Flattening`.

DNS – co trzeba zapamiętać?

DNS nie jest dodatkiem do domeny, tylko jej techniczną warstwą sterowania. Rekordy DNS decydują, gdzie działa strona, gdzie trafia poczta, jak działają subdomeny, czy certyfikat SSL może zostać wystawiony i czy zewnętrzne usługi potrafią zweryfikować domenę.

Najważniejsze pojęcia to strefa DNS, serwery nazw, rekordy A, AAAA, CNAME, MX, TXT, SOA, TTL i cache. Przy każdej większej zmianie trzeba najpierw ustalić, gdzie znajduje się aktywna strefa, a dopiero potem edytować rekordy.

Najwięcej awarii bierze się nie z samego DNS, tylko z mylenia poziomów: domeny z hostingiem, rekordu A z pocztą, zwykłego CNAME z apexem domeny albo TTL z negative caching. Gdy te różnice są jasne, większość problemów DNS da się zdiagnozować bez zgadywania.