Jak skonfigurować DNS dla domeny i sprawdzić, czy działa poprawnie

Przed zmianą DNS przygotuj wartości od hostingu i dostawcy poczty oraz ustal, który operator obsługuje aktywne serwery nazw domeny. Autorytatywny DNS to usługa, której serwery przechowują aktywną strefę i odpowiadają za publikowane rekordy.

Zbierz przed edycją:

• dostęp do panelu aktywnego operatora DNS;
• adres IPv4, IPv6 lub nazwę hosta podaną przez hosting;
• rekordy MX oraz wymagane wartości SPF, DKIM i DMARC od dostawcy poczty;
• obecną delegację NS, rekordy i ustawienia DNSSEC;
• osobę, która po zmianie sprawdzi stronę i skrzynki.

Domenę można kupić u jednej firmy, a rekordy utrzymywać u innej. W panelu rejestratora sprawdź serwery nazw przypisane do domeny, a następnie zaloguj się do panelu operatora, który nimi zarządza. Zapisanie kopii strefy przed edycją ułatwia przywrócenie poprzednich wartości.

Edycja rekordów zmienia zawartość strefy. Zmiana serwerów nazw (NS) przenosi obsługę całej strefy do innego operatora. Przed zmianą NS odtwórz u nowego operatora rekordy strony, poczty, subdomen i weryfikacji usług. Jeżeli domena używa DNSSEC, zaplanuj również bezpieczne przeniesienie lub ponowne skonfigurowanie tego zabezpieczenia.

Jeżeli DNS jest częścią prac nad sklepem, sprawdź też dostępność strony i HTTPS po zmianie. Przy okazji prac nad szybkością sklepu optymalizacja szybkości WooCommerce obejmuje techniczną analizę działania witryny.

Rekord A wskazuje IPv4, AAAA wskazuje IPv6, CNAME kieruje nazwę na inną nazwę, MX określa serwer poczty, TXT przechowuje ustawienia tekstowe usług, a NS wskazuje serwery nazw. Tabela pokazuje zastosowanie każdego typu i typowy błąd.

Tabela pomaga dobrać typ rekordu do celu, ale wartości należy pobierać od operatora hostingu lub poczty. Adresy w przykładach dokumentacji nie są wartościami do skopiowania do domeny firmowej. Cloudflare opisuje typy rekordów w dokumentacji rekordów DNS; stan sprawdziliśmy w październiku 2026.

Rekord A mapuje nazwę na IPv4, a AAAA na IPv6. CNAME jest aliasem do innej nazwy hosta i zwykle nie może współistnieć z innymi rekordami pod tą samą nazwą. Panele DNS mogą też ograniczać użycie CNAME dla domeny głównej.

Rekord MX kieruje pocztę przychodzącą, a jego priorytet określa kolejność serwerów. SPF określa, które systemy mogą wysyłać pocztę w imieniu domeny, DKIM pozwala sprawdzić podpis wiadomości, a DMARC określa politykę dla wiadomości, które nie przejdą kontroli. Te ustawienia są zwykle publikowane jako oddzielne rekordy TXT.

Edycja strefy DNS i zmiana serwerów nazw to różne operacje. Rekord NS w strefie opisuje serwery nazw, natomiast delegacja ustawiona u rejestratora wskazuje, które serwery mają obsługiwać domenę.

Stronę kierujemy na serwer przez A, AAAA lub CNAME zgodnie z wartością przekazaną przez hosting. Najpierw ustal, czy dostawca podał oddzielne wartości dla domeny głównej i hosta `www`.

1. Otwórz panel operatora aktywnej strefy DNS.
2. Odszukaj rekordy domeny głównej, często oznaczonej jako `@`, oraz `www`.
3. Porównaj typ i cel rekordów z instrukcją hostingu.
4. Zmień tylko rekordy wymagane przez konfigurację lub migrację.
5. Zapisz zmianę i sprawdź, czy panel nie zgłasza konfliktu nazwy albo typu.
6. Otwórz domenę główną i `www`, sprawdź przekierowanie oraz certyfikat HTTPS.

Hosting może wskazać adres IPv4, IPv6 albo nazwę hosta. Dla IPv4 używa się A, dla IPv6 AAAA, a dla nazwy hosta dostawca może wymagać CNAME lub innego typu rekordu. Wartości i typy dobieraj do instrukcji dostawcy, zamiast zakładać, że każda domena korzysta z takiego samego układu.

Nie dodawaj kilku rekordów A lub AAAA bez potwierdzenia hostingu. Różne adresy mogą rozdzielać ruch między serwery, a nieaktualny adres może kierować część użytkowników do innej witryny. Jeśli `www` ma być CNAME, sprawdź, czy pod tą nazwą nie ma innych rekordów, które panel uznaje za konfliktowe.

Ciągłość poczty wymaga właściwych rekordów MX oraz konfiguracji SPF, DKIM i DMARC zgodnej z instrukcją aktualnego dostawcy. Nie zastępuj rekordów wartościami z przykładowej konfiguracji innej usługi.

Przed zmianą MX zapisz dotychczasowe serwery i priorytety. Przy migracji poczty przygotuj nowe skrzynki i aliasy przed zmianą rekordów. Pozostawienie starych MX może rozdzielać dostarczanie wiadomości między poprzedniego i nowego operatora.

SPF publikuje się zwykle jako rekord TXT i powinien uwzględniać wszystkie systemy wysyłające pocztę w imieniu domeny. Domena powinna mieć jedną politykę SPF, ponieważ kilka osobnych rekordów SPF może powodować błąd weryfikacji. DKIM używa rekordu wskazanego przez operatora, a DMARC należy skonfigurować zgodnie z potrzebami organizacji i wynikami kontroli poczty.

Tabela łączy zmieniany rekord pocztowy z możliwym objawem i testem po wdrożeniu. Test wysyłki pomaga odróżnić problem z rekordem od problemu ze skrzynką lub filtrem dostawcy.

Po zmianie wyślij wiadomość na zewnętrzną skrzynkę i odpowiedz na nią. W nagłówkach obu wiadomości sprawdź wyniki SPF, DKIM i DMARC. Obecność rekordu w panelu DNS nie potwierdza jeszcze, że wiadomość przeszła kontrolę.

Google Workspace podaje własne wartości rekordów i informuje o czasie rozpoznania zmian do 72 godzin. Ten termin dotyczy wskazanej usługi, nie każdej zmiany DNS. Stan dokumentacji sprawdziliśmy w październiku 2026: MX dla Google Workspace, SPF, DKIM i DMARC.

TTL (Time to Live) określa, jak długo resolver DNS może przechowywać odpowiedź w pamięci podręcznej przed ponownym zapytaniem o rekord. Resolver DNS to usługa, która odpowiada urządzeniu użytkownika na pytanie o adres domeny.

Zmiana może być widoczna w aktywnej strefie, gdy część resolverów nadal korzysta z wcześniejszej odpowiedzi. Różni użytkownicy mogą więc otrzymywać różne wyniki do czasu wygaśnięcia zapamiętanej wartości. Czas zależy między innymi od poprzedniego TTL, rodzaju zmiany i pamięci podręcznej po stronie urządzenia.

Przed planowaną migracją można obniżyć TTL z wyprzedzeniem, jeśli operator na to pozwala. Obniżenie TTL tuż przed zmianą nie skróci czasu dla odpowiedzi zapisanych wcześniej z dłuższą wartością.

Cloudflare podaje automatyczny TTL wynoszący 300 sekund dla odpowiednich rekordów DNS-only. To ustawienie Cloudflare, a nie gwarantowany czas aktualizacji dla każdej domeny. Stan dokumentacji sprawdziliśmy w październiku 2026: TTL w Cloudflare.

Po zapisaniu rekordu nie zmieniaj go ponownie tylko dlatego, że jedna sieć pokazuje stary wynik. Najpierw sprawdź odpowiedź aktywnego serwera nazw, a potem porównaj ją z resolverami publicznymi i odczekaj poprzedni TTL.

Konfiguracja działa, gdy aktywna strefa publikuje wartości zgodne z instrukcją dostawcy, a strona i poczta przechodzą testy użytkowe. Sprawdź osobno domenę główną oraz `www`, ponieważ mogą mieć różne rekordy.

• Delegacja: porównaj serwery nazw u rejestratora z tymi, które wskazuje operator DNS.
• Strona: sprawdź A, AAAA lub CNAME i porównaj cel z instrukcją hostingu.
• Poczta: odczytaj MX i TXT, a następnie wyślij oraz odbierz testową wiadomość.
• HTTPS: otwórz stronę i sprawdź, czy certyfikat obejmuje używany host.
• Resolver: porównaj odpowiedzi w Google Public DNS Lookup lub Google Admin Toolbox Dig.

Google Public DNS Lookup pozwala zapytać o domenę i typ rekordu, a Google Admin Toolbox udostępnia narzędzie Dig. Wyniki porównuj z konfiguracją operatora. Sam poprawny odczyt rekordu DNS nie potwierdza, że serwer strony odpowiada prawidłowo.

Perspektywa KC Mobile. W testach po zmianie oddzielamy kontrolę odpowiedzi DNS od testu strony i poczty. Taki podział pomaga ustalić, czy problem dotyczy delegacji, rekordu, serwera WWW czy obsługi wiadomości.

Najczęstsze błędy po zmianie DNS wynikają z nieaktualnego A, konfliktu rekordów, starych MX, błędnego SPF albo niezgodności delegacji. Zanim wprowadzisz kolejną zmianę, porównaj wynik z instrukcją właściwego dostawcy.

Tabela pokazuje pierwszy bezpieczny test i działanie dla typowych objawów. Przy problemie z DNSSEC sprawdź po kolei delegację NS, stan DNSSEC oraz zgodność rekordu DS u rejestratora z kluczami i konfiguracją aktywnej strefy. Dopiero potem zmieniaj ustawienia zgodnie z instrukcją operatora DNS i rejestratora.

Cloudflare wskazuje nieaktualny rekord DS po zmianie serwerów nazw jako jedną z przyczyn błędów walidacji DNSSEC. W diagnostyce można użyć DNSViz albo `dig`, ale zmianę DS wykonuj na podstawie wartości dostarczonych przez operatora. Stan dokumentacji sprawdziliśmy w październiku 2026: diagnostyka DNSSEC oraz diagnostyka delegacji.

Jeżeli zmiana NS jest konieczna, upewnij się, że nowy operator ma kopię rekordów strony, poczty, usług i subdomen. Po naprawie DNS możesz osobno zlecić analizę szybkości sklepu WooCommerce, jeśli dalszym problemem jest wydajność witryny.

• Co to jest DNSSEC i jak wdrożyć je dla swojej domeny?
• Cloudflare - co to jest, jak działa i kiedy przydaje się firmie
• Gzip i Brotli - jak włączyć kompresję strony WWW i sprawdzić efekt?
• Optymalizacja stron z dynamicznymi tabelami danych pod szybkość i SEO