Delegacja domeny oznacza wskazanie serwerów nazw, które mają być autorytatywne dla jej strefy DNS. Jeśli chcesz tylko przenieść stronę na inny hosting, zwykle wystarczy zmiana rekordu A. Serwery nazw zmieniaj wtedy, gdy nowy operator ma przejąć zarządzanie całą strefą, razem z rekordami strony, poczty i usług dodatkowych.1
Czym jest delegacja domeny i czym różni się od zmiany rekordów DNS?
DNS jest rozproszoną bazą danych podzieloną na strefy. Delegacja wskazuje, które serwery nazw odpowiadają autorytatywnie za daną strefę. Mechanizm wynika z modelu opisanego w RFC 1034, gdzie granice stref powstają przez delegowanie części przestrzeni nazw do innych serwerów autorytatywnych.1
Zmiana rekordu DNS działa poziom niżej. Nie zmieniasz wtedy operatora strefy, tylko jedną informację w istniejącej strefie. Wpis example.pl. 3600 IN A 203.0.113.20 kieruje domenę na adres IPv4 serwera, a TTL wynoszący 3600 sekund, czyli 1 godzinę, mówi resolverom, jak długo mogą tę odpowiedź pamiętać.2 Rekord A nie deleguje domeny do nowego systemu DNS.
Przy domenach .pl zmianę delegacji zleca się rejestratorowi. NASK wskazuje, że operacja odbywa się za pośrednictwem partnera, według jego procedury, a serwery nazw muszą być prawidłowo przygotowane do obsługi domeny.6
Najważniejsze liczby: TTL to maksymalny czas przechowywania rekordu w pamięci resolvera, podawany w sekundach.2 Cyber_Folks stosuje zależnie od panelu domyślne TTL 3600 albo 14400 sekund.8 Cloudflare ustawia Auto na 300 sekund, dla rekordów DNS only pozwala poza planem Enterprise na minimum 60 sekund, a maksimum wynosi 1 dzień.10 OVHcloud podaje do 24 godzin dla zmian w strefie i do 48 godzin dla zmiany serwerów DNS domeny.7
Kiedy wystarczy rekord A, a kiedy trzeba zmienić serwery nazw?
Jeśli obecny DNS działa prawidłowo i chcesz jedynie przenieść witrynę, najbezpieczniej zostawić delegację bez zmian. Zmień rekord A dla domeny głównej na adres IPv4 nowego hostingu. Jeśli serwer udostępnia IPv6, ustaw analogicznie AAAA, który zgodnie z RFC 3596 przechowuje pojedynczy adres IPv6 o długości 128 bitów.5
Ten wariant jest szczególnie wygodny, gdy poczta działa u innego dostawcy. Rekordy MX, TXT dla SPF, DKIM i DMARC oraz pozostałe ustawienia zostają na dotychczasowym DNS. Cyber_Folks potwierdza w dokumentacji, że do skierowania samej strony na ich hosting wystarczy rekord A wskazujący adres IP serwera.9
Zmiana serwerów nazw ma sens, gdy hosting ma przejąć obsługę całego DNS albo gdy chcesz przenieść zarządzanie strefą do wyspecjalizowanego operatora. Obecną delegację zastępujesz wtedy wartościami w rodzaju ns1.example.net i ns2.example.net. Dla domen .pl NASK wymaga podania co najmniej dwóch serwerów przeznaczonych do utrzymywania domeny.6
Jakie rekordy DNS spotkasz przy podpinaniu domeny?
Rekordy różnią się funkcją, więc A, MX i NS nie są zamiennikami. RFC 1035 definiuje między innymi typy A, NS, CNAME, MX i TXT oraz ich podstawową składnię.2 AAAA został zdefiniowany później, w RFC 3596.5
| Typ | Do czego służy | Przykładowa wartość |
|---|---|---|
| A | Wskazuje adres IPv4 hosta | 203.0.113.20 |
| AAAA | Wskazuje adres IPv6 hosta | 2001:db8::20 |
| CNAME | Tworzy alias do innej nazwy | www.example.pl. CNAME example.pl. |
| MX | Wskazuje serwer przyjmujący pocztę | 10 mail.example.pl. |
| TXT | Przechowuje tekst używany między innymi przez SPF i weryfikację usług | v=spf1 include:example.net ~all |
| NS | Wskazuje serwer nazw odpowiedzialny za strefę | ns1.example.net. |
Priorytet rekordu MX jest liczbą, przy czym niższa wartość oznacza większą preferencję serwera pocztowego.2 Wpis 10 mail1.example.pl. ma więc pierwszeństwo przed 20 mail2.example.pl.
Szczególną uwagę zachowaj przy CNAME. RFC 2181 określa, że nazwa będąca aliasem CNAME nie może jednocześnie mieć innych zwykłych danych DNS.3 Nie ustawiaj więc CNAME i MX pod dokładnie tą samą nazwą.
Jak zmienić serwery nazw krok po kroku?
Najpierw dodaj domenę do nowego hostingu albo usługi DNS. Operator powinien pokazać serwery nazw przypisane do strefy, na przykład ns1.operator.example i ns2.operator.example. Nie kopiuj adresów z przypadkowej instrukcji, bo część dostawców przypisuje różne zestawy DNS do różnych usług.
Następnie utwórz na nowych serwerach kompletną strefę. Dopiero po jej sprawdzeniu zaloguj się do panelu rejestratora i znajdź opcję serwery DNS, delegacja albo nameservers. Usuń stare wartości, wpisz nowe i zapisz zmianę. Przy domenie .pl zmianę delegacji realizuje partner, czyli rejestrator obsługujący domenę.6
W OVHcloud ta operacja znajduje się przy domenie, na karcie serwerów DNS, gdzie można wybrać modyfikację serwerów nazw.7 Dokumentacja zaleca, żeby przed zmianą nowa strefa już istniała i miała właściwe rekordy NS.7
Nie myl edycji rekordów NS widocznych wewnątrz strefy ze zmianą delegacji u rejestratora. OVHcloud odradza ręczne podmienianie rekordów NS w swojej strefie, gdy faktycznym celem jest zmiana serwerów nazw przypisanych do domeny.7
Ile trwa propagacja DNS i jaką rolę gra TTL?
Słowo propagacja upraszcza zjawisko. Po zmianie rekordu nie rusza żaden globalny proces, który rozsyła nową wartość do wszystkich resolverów. Serwery rekurencyjne przechowują wcześniejszą odpowiedź do czasu wygaśnięcia TTL. RFC 1034 opisuje TTL jako okres, przez który rekord może pozostawać w pamięci podręcznej przed odrzuceniem.1
Jeżeli rekord A ma przed migracją TTL 14400 sekund, resolver może korzystać ze starego adresu przez maksymalnie 4 godziny od chwili jego pobrania.2 Cyber_Folks stosuje 14400 sekund jako domyślną wartość w części paneli, a w cyber_Admin domyślne TTL wynosi 3600 sekund.8 home.pl również podaje 3600 sekund jako wartość domyślną w opisanej konfiguracji rekordów.11
Przed planowaną migracją można obniżyć TTL, ale trzeba zrobić to, zanim stara wartość wygaśnie w istniejących cache. Przy TTL 86400 sekund zmianę na 300 sekund najlepiej wykonać co najmniej 24 godziny przed właściwym przełączeniem.1 RFC 1034 wprost opisuje obniżenie TTL przed przewidywaną zmianą jako sposób skrócenia okresu niespójności.1
Nie każdy operator pozwala ustawić dowolnie niską wartość. W dokumentacji Cloudflare rekordy proxied mają Auto równe 300 sekund, a zwykłe rekordy DNS only mają poza Enterprise minimalne TTL 60 sekund i maksymalne 1 dzień.10 Sam protokół dopuszcza znacznie szerszy zakres, bo RFC 2181 określa maksymalny TTL jako 2147483647 sekund.3
Dlaczego SOA ma znaczenie podczas oczekiwania na zmianę?
SOA opisuje parametry strefy i zawiera między innymi numer seryjny oraz pola związane z jej obsługą. RFC 1035 opisuje pola SERIAL, REFRESH, RETRY, EXPIRE i MINIMUM oraz ich wartości czasowe w sekundach.2 Współczesnego SOA.MINIMUM nie należy jednak interpretować wyłącznie według tego dokumentu.
RFC 2308 zmieniło znaczenie SOA.MINIMUM dla negatywnego cache.4 Czas przechowywania odpowiedzi NXDOMAIN albo NODATA wynika z mniejszej wartości spośród SOA.MINIMUM i TTL rekordu SOA.4 Ma to praktyczny skutek po utworzeniu rekordu, którego chwilę wcześniej nie było, bo resolver może nadal pamiętać wcześniejszą odpowiedź negatywną.
RFC 2308 wskazuje też, że wartości negatywnego cache rzędu od 1 do 3 godzin sprawdzają się jako rozsądne ustawienia domyślne, a wartości przekraczające 1 dzień uznano za problematyczne.4 To jeden z powodów, dla których nowy rekord nie zawsze pojawia się natychmiast, nawet przy krótkim TTL.
Operator może dodatkowo publikować własne maksymalne czasy. OVHcloud podaje, że zmiana rekordu w strefie propaguje się do 24 godzin, a zmiana serwerów nazw domeny do 48 godzin.7 Cyber_Folks dla zmiany delegacji podaje w jednej instrukcji oczekiwanie do 24 godzin, a w dokumentacji konfiguracji domen okres do 48 godzin.9
Jak nie stracić poczty podczas zmiany delegacji?
Największym ryzykiem przy pełnej delegacji nie jest strona, tylko pominięte rekordy pocztowe. Zanim zmienisz serwery nazw, odczytaj ze starej strefy wszystkie rekordy MX i powiązane rekordy A lub CNAME dla nazw używanych przez serwery pocztowe. Skopiuj również TXT odpowiedzialne za SPF, DKIM, DMARC i weryfikację usług.
Nową strefę przygotuj przed zmianą NS. Jeśli pocztę obsługuje nadal stary dostawca, jego MX powinny pozostać takie same także na nowych serwerach DNS. RFC 1035 definiuje MX jako nazwę hosta przyjmującego pocztę wraz z wartością preferencji.2
Dobrym testem jest porównanie odpowiedzi starego i nowego serwera jeszcze przed delegacją. Konkretny serwer odpytasz poleceniem dig @ns1.nowyoperator.example example.pl MX. W ten sam sposób sprawdź TXT, A, AAAA oraz rekordy dla nazw typu www, mail i selektorów DKIM.
Po przełączeniu nie wyłączaj starej strefy natychmiast. Dopóki część resolverów ma w cache poprzednią delegację, może nadal kierować zapytania do dawnych serwerów nazw. To szczególnie ważne tam, gdzie operator podaje maksymalny czas zmiany delegacji liczony w dziesiątkach godzin, jak 48 godzin w OVHcloud.7
Jak sprawdzić, czy domena wskazuje właściwy serwer?
Najbardziej użyteczne jest polecenie dig. Zapytanie dig example.pl A pokaże rekord IPv4, dig example.pl MX rekordy pocztowe, a dig example.pl NS serwery nazw. Numer seryjny strefy zobaczysz przez dig example.pl SOA. OVHcloud również wskazuje zapytanie o SOA jako metodę kontroli zmian DNS.7
W Windows użyjesz nslookup example.pl, a następnie odpytasz wybrany resolver zamiast domyślnego DNS dostawcy internetu. Dzięki temu porównasz odpowiedzi z kilku miejsc i odróżnisz stary cache od błędnej strefy autorytatywnej.
Dla domen .pl sprawdź także WHOIS. NASK wskazuje bazę WHOIS jako miejsce, w którym ustalisz podmiot obsługujący domenę, natomiast czynności administracyjne wykonuje się przez rejestratora.6 Sam WHOIS nie zastępuje zapytania DNS do serwerów autorytatywnych.
Jakie błędy najczęściej psują delegowanie domeny?
Pierwszy to skierowanie domeny głównej na nowy serwer bez konfiguracji dla www. Jeśli hosting nie tworzy aliasu automatycznie, dodaj osobny rekord, na przykład www.example.pl. CNAME example.pl. CNAME wskazuje nazwę kanoniczną aliasu zgodnie z definicją RFC 1035.2
Drugi błąd to obniżenie TTL dopiero w chwili migracji. Jeśli stary rekord został wcześniej zapisany na 86400 sekund, samo przestawienie go na 300 sekund nie skróci życia kopii, która już siedzi w resolverze.1 TTL redukuje się więc z wyprzedzeniem co najmniej równym starej wartości.
Trzeci problem to CNAME utworzony pod nazwą, pod którą mają istnieć także inne rekordy. RFC 2181 zabrania zwykłemu węzłowi CNAME posiadania równocześnie innych danych DNS.3 Konflikt dotyczy na przykład próby połączenia CNAME i MX dla tej samej nazwy.
Czwarty błąd polega na uznaniu pamięci przeglądarki za propagację DNS. DNS ma własne cache w systemie operacyjnym, resolverze lokalnym i resolverach rekurencyjnych, a przeglądarka dodatkowo przechowuje dane o połączeniach. Jeśli dig pokazuje już nowy adres, a witryna nadal otwiera starą wersję, sprawdź cache aplikacji, CDN, proxy i samego hostingu zamiast ponownie zmieniać rekord.
Co zrobić, gdy strona działa, a poczta przestała?
Jeżeli witryna odpowiada z nowego serwera, ale wiadomości nie dochodzą, zacznij od dig example.pl MX. Sprawdź, czy wynik odpowiada konfiguracji dostawcy poczty. Następnie odpytaj rekord A albo AAAA hosta wskazanego przez MX. RFC 1035 określa, że celem MX jest nazwa hosta obsługującego wymianę poczty, a nie adres IP.2
Jeśli problem pojawił się zaraz po zmianie NS, porównaj strefę sprzed migracji z nową. Najczęściej brakuje rekordu MX, adresu hosta pocztowego albo TXT potrzebnego do autoryzacji wysyłki. Nie przywracaj starego rekordu A tylko dlatego, że przestała działać poczta, bo to niezależne elementy strefy.
Sprawdź też odpowiedzi bezpośrednio z serwerów autorytatywnych. Jeśli nowy serwer zwraca prawidłowy MX, a publiczny resolver stary, przyczyną jest cache. Jeśli serwer autorytatywny sam zwraca złą wartość, problem leży w konfiguracji strefy i czekanie na propagację go nie naprawi.
Co zrobić, gdy poczta działa, a strona nie otwiera się z nowego hostingu?
Jeżeli MX jest prawidłowy, a strona nie działa, sprawdź A i AAAA dla domeny głównej oraz rekord dla www. Rekord A przechowuje adres IPv4, a AAAA pojedynczy adres IPv6.25 Stary AAAA bywa szczególnie zdradliwy, bo część klientów spróbuje połączenia po IPv6 mimo prawidłowo zmienionego A.
Potem sprawdź konfigurację po stronie hostingu. Prawidłowy DNS nie przypisuje domeny do konta WWW. Domena musi być dodana w panelu serwera, serwer HTTP musi ją rozpoznawać, a certyfikat TLS powinien obejmować używaną nazwę.
Przy pełnej zmianie serwerów nazw sprawdź delegację niezależnie od strefy. Serwer autorytatywny może mieć idealny rekord A, a użytkownicy go nie zobaczą, jeśli domena nadrzędna nadal odsyła do starego zestawu NS. Dla domen .pl delegację ustawiasz przez rejestratora, a NASK może odmówić zmiany, jeśli nowe serwery nie są skonfigurowane do obsługi domeny.6
Bezpieczna kolejność przy migracji jest więc prosta: przygotuj nowy hosting i strefę, obniż wcześniej TTL, sprawdź rekordy pocztowe, wykonaj zmianę A albo delegacji zgodnie z zakresem migracji, a potem porównuj odpowiedzi serwerów autorytatywnych i resolverów. Dzięki temu wiesz, czy problem leży w rekordzie, cache, delegacji, czy w konfiguracji samego serwera.
Źródła
Zweryfikowano: wrzesień 2026
Dokumenty RFC opisujące działanie DNS, warunki techniczne Rejestru domeny .pl oraz dokumentacja OVHcloud, Cyber_Folks, Cloudflare i home.pl.
- RFC 1034: Domain Names, Concepts and Facilities
- RFC 1035: Domain Names, Implementation and Specification
- RFC 2181: Clarifications to the DNS Specification
- RFC 2308: Negative Caching of DNS Queries
- RFC 3596: DNS Extensions to Support IP Version 6
- Warunki techniczne nazw domeny .pl i zarządzanie domeną
- Domain name and DNS FAQ
- Jak edytować rekordy DNS?
- Dodawanie domeny w panelu cyber_Admin i weryfikacja konfiguracji
- Time to Live (TTL)
- Jak utworzyć i wydelegować subdomenę na zewnętrzne DNS?
Najczęściej zadawane pytania
Czym jest delegacja domeny?
To wskazanie serwerów nazw, które odpowiadają autorytatywnie za strefę DNS domeny. Delegację ustawia się u rejestratora, a nie w samej strefie. Zmiana pojedynczego rekordu, na przykład A albo MX, dzieje się poziom niżej i nie zmienia operatora strefy.
Czy żeby zmienić hosting, trzeba zmieniać serwery nazw?
Nie zawsze. Jeśli dotychczasowy DNS działa dobrze, wystarczy zmienić rekord A domeny na adres IP nowego serwera, a przy IPv6 dodatkowo AAAA. Serwery nazw zmieniasz wtedy, gdy nowy operator ma przejąć całą strefę, z rekordami poczty i usług dodatkowych.
Ile trwa propagacja DNS?
Tyle, ile wynosi TTL starego rekordu w pamięci resolverów. Przy TTL 3600 sekund to godzina, przy 14400 sekund cztery godziny. Operatorzy podają też własne maksymalne czasy: OVHcloud do 24 godzin dla zmiany rekordu w strefie i do 48 godzin dla zmiany serwerów nazw.
Jak przygotować domenę do migracji, żeby zmiana poszła szybko?
Obniż TTL z wyprzedzeniem co najmniej równym jego obecnej wartości. Przy TTL 86400 sekund ustaw 300 sekund na dobę przed przełączeniem. Samo obniżenie TTL w chwili migracji nie skróci życia kopii, które resolvery już pobrały.
Dlaczego po zmianie DNS przestała działać poczta?
Najczęściej dlatego, że nowa strefa nie ma rekordów MX i TXT ze starej konfiguracji. Sprawdź dig example.pl MX oraz rekordy SPF, DKIM i DMARC, a rekordu A strony nie przywracaj, bo poczta i strona to niezależne elementy strefy.
