Jak ustawić przekierowania DNS

Przekierowania związane z ruchem do domeny bywają mylone z działaniem samego systemu DNS. Ten poradnik pomoże ci świadomie zaplanować i przeprowadzić zmiany tak, by użytkownicy trafiali we właściwe miejsce, a serwisy działały bez przerw. Zobaczysz różnicę między przekierowaniem na poziomie serwera WWW i zmianą rekordów DNS, poznasz ograniczenia, najlepsze praktyki oraz narzędzia do weryfikacji. Dzięki temu unikniesz utraty ruchu, błędów certyfikatów i kłopotów z pocztą.

Podstawy: co naprawdę znaczy “przekierowanie” w kontekście DNS

Czym jest i czego nie robi DNS

DNS to system tłumaczący nazwy na adresy IP. Nie wykonuje on faktycznych “przekierowań” ruchu HTTP; jedynie wskazuje, pod jaki adres ma połączyć się przeglądarka czy aplikacja. Gdy mówimy o przekierowaniu, często chodzi o dwa różne mechanizmy:

• Zmiana wskazań w strefie DNS (np. inny adres IP lub alias do innej nazwy) – warstwa sieciowa, “gdzie jest serwis”.
• Przekierowanie HTTP 301/302 – odpowiedź serwera WWW nakazująca przeglądarce przejście pod inny URL – warstwa aplikacyjna, “pod jaki URL przenieść użytkownika”.

W praktyce, aby domena “przenosiła” użytkownika pod inną domenę/URL, potrzebne jest przekierowanie HTTP. Sama zmiana DNS spowoduje, że użytkownik trafi na inny serwer, ale nie zmieni widocznego adresu w pasku przeglądarki.

Najczęstsze rekordy i ich rola

• rekord A – wskazuje IPv4 serwera docelowego (np. 203.0.113.10).
• AAAA – odpowiednik dla IPv6 (np. 2001:db8::10).
• CNAME – alias jednej nazwy na inną nazwę (np. blog.example.com → hosting.example.net).
• ALIAS/ANAME – specyficzne dla niektórych dostawców, pozwalają na alias w wierzchołku strefy (apex, np. example.com), gdzie tradycyjnie CNAME jest niedozwolony.
• MX, TXT, SRV – inne typy wpływające m.in. na pocztę i usługi dodatkowe; zwykle nie dotykasz ich przy webowym przekierowaniu.

Jeżeli chcesz, by nazwa wskazywała na inny serwer, zmieniasz rekordy A/AAAA lub ustawiasz alias CNAME/ALIAS. Jeżeli chcesz, by użytkownik został przeniesiony na inny adres URL, konfigurujesz przekierowanie HTTP na serwerze (lub używasz funkcji “URL redirect” w panelu dostawcy, jeśli taką oferuje).

Kiedy DNS, a kiedy HTTP 301/302

• DNS – kiedy zmieniasz lokalizację usługi (hosting, IP serwera), ale chcesz zachować ten sam adres URL. To nie “przekierowuje” przeglądarki, tylko podmienia adres serwera.
• HTTP 301 (trwale) – gdy przenosisz treści pod nowy adres i chcesz przekazać sygnały SEO.
• HTTP 302/307 (tymczasowo) – gdy przeniesienie jest chwilowe, np. w trakcie prac.
• Specjalny “URL redirect record” – oferowany przez część dostawców DNS; to uproszczony mechanizm HTTP redirect hostowany przez nich.

Ograniczenia, cache i TTL

Zmiany DNS nie działają natychmiast. Każdy rekord ma TTL – czas, przez jaki odpowiedź może być buforowana. Zbyt długie TTL spowolnią zmianę, zbyt krótkie zwiększą liczbę zapytań i obciążenie. Efekt “starego” IP może utrzymywać się w sieci nawet kilka godzin. Właśnie dlatego dobre planowanie i testy są kluczowe.

Plan działania: przygotowanie do zmiany

Inwentaryzacja strefy

Spisz wszystkie nazwy i rekordy w strefie: wierzchołek (apex) example.com, subdomena www.example.com, inne subdomeny (api, app, blog), rekordy MX (poczta), TXT (SPF, DKIM), SRV (VoIP, Skype), CNAME (aliasy). Zidentyfikuj, które wpisy obsługują ruch WWW, a które dotyczą poczty czy innych usług. Dzięki temu unikniesz przypadkowego “złamania” poczty podczas przenosin serwisu.

Obniżenie TTL

Na 24–48 godzin przed planowaną zmianą zmniejsz TTL kluczowych rekordów (A/AAAA/CNAME) do np. 300 s. Umożliwi to szybszą propagacja nowych wartości. Po zakończeniu prac możesz wrócić do wyższych TTL (np. 3600–14400 s), co poprawi wydajność i stabilność.

Weryfikacja środowiska docelowego

• Sprawdź, czy serwer docelowy nasłuchuje na właściwych portach (80/443), ma zainstalowany certyfikat HTTPS dla nowej nazwy i potrafi zrealizować ewentualne przekierowanie HTTP (np. z www → bez www lub odwrotnie).
• Jeśli używasz wynikowego przekierowania (301/302), przygotuj reguły na serwerze (Nginx, Apache, aplikacja) lub w ramach usług CDN/WAF.
• Jeśli przenosisz jedynie adres IP, upewnij się, że aplikacja jest wdrożona i gotowa do obsługi ruchu.

Backup i okno serwisowe

Zrób zrzut strefy (eksport do pliku) i przygotuj okno serwisowe – nawet jeśli przewidujesz brak przestoju. Miej gotowy plan powrotu do poprzedniej konfiguracji. Zadbaj o komunikację – jeżeli zmiana może być zauważalna, uprzedź użytkowników i zespół.

Instrukcje krok po kroku: najczęstsze scenariusze

1) www → domena główna (apex) lub na odwrót

Cel: użytkownik wchodzi na www.example.com i trafia na example.com (zmiana URL) lub odwrotnie.

• Ustaw DNS:
  • apex (example.com) – rekord A/AAAA do serwera www.
  • www.example.com – jeśli dostawca pozwala, użyj CNAME → example.com; inaczej wskaż tym samym IP w rekordach A/AAAA.
• Włącz na serwerze WWW przekierowanie HTTP 301 z jednej wersji do drugiej:
  • z www → apex lub z apex → www (wybierz jedną wersję kanoniczną).
• Upewnij się, że certyfikat TLS obejmuje obie nazwy (SAN): example.com i www.example.com.

Pamiętaj: na wierzchołku strefy tradycyjnie nie można użyć CNAME. Jeśli chcesz, by apex aliasował się do innej nazwy (np. hostingu), użyj typu ALIAS/ANAME, jeśli wspiera go twój dostawca.

2) Przeniesienie domeny na inny serwer (zmiana IP)

• W panelu DNS zmień rekordy A (i AAAA, jeśli używasz IPv6) na nowe IP.
• Obniżony TTL przyspieszy propagację, ale licz się z kilkugodzinnym okresem przejściowym.
• Na serwerze docelowym skonfiguruj witrynę, certyfikat TLS i ewentualne reguły przekierowań.

Ta operacja nie zmienia adresu w pasku przeglądarki – użytkownik trafia na nowy serwer pod tym samym URL.

3) Subdomena na inną domenę (alias i przekierowanie URL)

Cel: blog.example.com ma przenosić użytkownika do example.org/blog.

• DNS: ustaw dla blog.example.com rekord CNAME wskazujący na host, który obsłuży przekierowanie HTTP (np. dedykowany serwer “redirector” lub usługa dostawcy).
• HTTP: na docelowym serwerze skonfiguruj 301 z blog.example.com → https://example.org/blog (lub użyj pozycji “URL redirect” w panelu, jeśli istnieje).

Sam CNAME nie zmieni adresu w pasku; alias jedynie wskaże, gdzie szukać odpowiedzi. Za zmianę URL odpowiada odpowiedź 301/302.

4) “URL redirect record” w panelu dostawcy

Część dostawców oferuje specjalny typ wpisu “URL redirect” lub “Forward”. W praktyce tworzą oni własny serwer, który odbiera ruch dla twojej nazwy i odsyła 301/302 do wskazanego URL.

• Wybierz typ: stałe (301) lub tymczasowe (302) przekierowanie.
• Wskaż źródłową nazwę (np. old.example.com) i docelowy adres URL.
• Sprawdź, czy działa również dla HTTPS – niektórzy dostawcy automatycznie wydają certyfikat, inni wymagają twojego TLS lub działają tylko dla HTTP.

5) Wildcard (przechwytywanie wielu subdomen)

Jeśli chcesz, aby dowolna nieistniejąca subdomena kierowała w jedno miejsce:

• Ustaw rekord *.example.com → IP serwera “redirector” lub CNAME do hosta usługi przekierowań.
• Na serwerze przygotuj reguły, które dla każdej nazwy generują odpowiednie 301 – np. każdą nazwę kierują do https://example.com.
• Uwaga na certyfikaty: wildcard TLS (*.example.com) może być konieczny dla pełnego wsparcia HTTPS.

6) Poczta i inne usługi nie powinny ucierpieć

Zmiana A/AAAA dla apexu lub www nie powinna dotykać rekordów MX, TXT (SPF, DKIM) czy SRV. Uważaj jednak na globalne “przenosiny” strefy (np. zmiana serwerów nazw NS) – przenieś komplet rekordów, by nie przerwać działania poczty.

7) IPv6 i spójność

Jeżeli używasz AAAA, zsynchronizuj zmiany z A. Różne wskazania dla IPv4 i IPv6 mogą powodować niespójne działanie zależne od klienta. Testuj z i bez IPv6.

W panelach popularnych dostawców

Cloudflare

• DNS:
  • Dodaj rekord A/AAAA lub CNAME. Zdecyduj, czy ma być “Proxy” (chmurka pomarańczowa) czy “DNS only” (szara chmurka). Proxy pozwoli użyć reguł przekierowań na poziomie platformy.
• Przekierowanie:
  • Rules → Redirect Rules: zdefiniuj dopasowanie (np. Hostname equals old.example.com) i akcję “Static Redirect” 301/302 do docelowego URL.
  • Dawniej: Page Rules; obecnie zalecane są Redirect Rules.
• TLS:
  • Upewnij się, że tryb TLS jest poprawny (np. Full). Wystaw certyfikat na obie nazwy (apex i www) – CF może zapewnić własny certyfikat edge.

OVH

• DNS:
  • Strefa DNS → Dodaj/edytuj rekordy A/AAAA dla apex i www. Dla aliasów użyj CNAME.
• Przekierowanie:
  • OVH ma opcję “Przekierowania” (URL). Wybierz typ 301/302, źródło (np. domena lub subdomena) oraz docelowy URL.
• Uwaga:
  • Jeśli hostujesz stronę poza OVH, najlepiej konfiguruj przekierowanie po stronie serwera WWW, by mieć pełną kontrolę.

home.pl / nazwa.pl

• DNS:
  • Dodaj/zmień A/AAAA/CNAME. Panel zwykle pozwala też na “Przekierowanie URL”.
• Przekierowanie:
  • Wybierz stałe (301) dla migracji docelowej, tymczasowe (302) dla testów. Wprowadź ścieżkę docelową.
• TLS:
  • Sprawdź, czy przekierowanie URL działa z HTTPS – część dostawców wymaga wykupienia certyfikatu lub daje wsparcie tylko dla HTTP.

AWS Route 53

• DNS:
  • Użyj A (Alias) do zasobów AWS (np. CloudFront, ELB) – to odpowiednik ALIAS. Dla subdomen możesz użyć CNAME.
• Przekierowanie:
  • Prosta opcja: S3 Static Website Hosting w trybie “redirect requests” – bucket o nazwie źródłowej domeny może odsyłać 301 do innego Hostname/ścieżki.
  • Zaawansowane: CloudFront z Function/Lambda@Edge do reguł przekierowań.
• TLS:
  • Certyfikaty w ACM (us-east-1 dla CloudFront). Zapewnij pokrycie wszystkich nazw.

GitHub Pages (przykład usługi PaaS)

• DNS:
  • Ustaw CNAME dla subdomeny (np. www → username.github.io) lub A/AAAA do wskazanych IP dla apex (zgodnie z dokumentacją GitHub).
• Przekierowanie:
  • GitHub Pages obsługuje canonical i automatycznie może przekierować www ↔ apex po właściwej konfiguracji CNAME/A.
• HTTPS:
  • Włącz “Enforce HTTPS” i poczekaj na wystawienie certyfikatu.

Weryfikacja i rozwiązywanie problemów

Testy DNS: dig/nslookup

• Sprawdź rekordy:
  • dig +short example.com A
  • dig +short example.com AAAA
  • dig +short www.example.com CNAME
• Wymuś konkretne serwery:
  • dig @1.1.1.1 www.example.com
  • dig @8.8.8.8 www.example.com
• Podgląd TTL:
  • dig www.example.com +nocmd +noall +answer

Jeżeli wyniki różnią się między resolverami lub krajami, to normalne w trakcie propagacja. Czekaj zgodnie z TTL, a następnie weryfikuj ponownie.

Testy HTTP: curl i nagłówki

• Sprawdź przekierowanie:
  • curl -I http://example.com – szukaj Location i kodu 301/302.
  • curl -I -L http://example.com – śledzi łańcuch przekierowań.
• HTTPS:
  • curl -I https://example.com – zweryfikuj certyfikat i nagłówki bezpieczeństwa.

Jeśli widzisz pętlę (np. 301 między www i apex), sprawdź logikę reguł. Jedna strona powinna być kanoniczna, druga zawsze na nią przekierowywać.

Certyfikaty i mieszany ruch

• Jeśli użytkownik łączy się z https://www.example.com, serwer musi posiadać certyfikat na www.example.com. Brak dopasowania spowoduje błąd TLS, zanim dojdzie do jakiegokolwiek przekierowania.
• Dla wildcardów użyj certyfikatu *.example.com (i ewentualnie SAN dla apexu).

SEO i jakość przekierowań

• Używaj 301 dla trwałych zmian; 302 dla tymczasowych.
• Unikaj łańcuchów przekierowań (A → B → C). Staraj się kierować bezpośrednio do celu.
• Ustaw canonical na stronie docelowej, rozważ HSTS po ustabilizowaniu ruchu HTTPS.

Cache, przeglądarki i systemy pośrednie

• Flush DNS lokalnie:
  • Windows: ipconfig /flushdns
  • macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
  • Linux: zależnie od usługi (systemd-resolved, nscd)
• Pamiętaj o cache w przeglądarce i CDN. W razie potrzeby oczyść zasoby i wymuś odświeżenie.

Plan awaryjny i rollback

• Jeśli ruch nie działa poprawnie, przywróć poprzednie rekordy z kopii.
• Utrzymuj krótkie TTL podczas okna migracji, by szybciej wrócić do stanu sprzed zmian.
• Dokumentuj zmiany: data, rekord, stara wartość, nowa wartość, uzasadnienie.

Podsumowując praktycznie, najpierw określ cel: czy zmieniasz lokalizację usługi (DNS), czy przenosisz użytkowników pod nowy URL (HTTP 301/302). Zaplanuj TTL, przygotuj serwer i certyfikaty HTTPS, zweryfikuj wyniki narzędziami (dig, curl), a następnie utrzymuj porządek w strefie – zwłaszcza dla apexu, gdzie nie zawsze dostępny jest ALIAS. Dzięki temu twoje “przekierowanie” będzie szybkie, bezpieczne i przewidywalne, a każdy rekord i CNAME trafi dokładnie tam, gdzie powinien.