Najkrótsza wersja tego, co warto zapamiętać
- CNAME wskazuje jedną nazwę DNS na drugą nazwę DNS, a nie na adres IP.
- Najlepiej sprawdza się dla subdomen, na przykład `www` albo `app`.
- Nie powinien współistnieć z innymi rekordami pod tą samą nazwą.
- Dla domeny głównej zwykle potrzebujesz A, AAAA albo rozwiązania typu ALIAS/flattening.
- Zmienione wpisy DNS potrafią propagować się od kilku minut do kilku godzin, czasem dłużej przez cache.
Czym jest rekord CNAME i kiedy naprawdę się przydaje
Ja patrzę na CNAME jak na prosty mechanizm „przeadresowania” w DNS: jedna nazwa staje się aliasem drugiej, bardziej kanonicznej nazwy. Dzięki temu nie wpisujesz w DNS adresu IP, tylko odwołujesz się do innej nazwy hosta, która sama prowadzi dalej do właściwego celu.
To rozwiązanie jest szczególnie wygodne, gdy korzystasz z hostingu zewnętrznego, platformy SaaS albo usługi, której adres IP może się zmieniać. Zamiast poprawiać kilka miejsc po każdej zmianie infrastruktury, aktualizujesz tylko nazwę docelową. Najczęściej używa się tego przy subdomenach, bo dla `www.twojadomena.pl` albo `app.twojadomena.pl` taki model jest po prostu praktyczny.
Warto zapamiętać jedną rzecz: CNAME nie mówi przeglądarce „przekieruj użytkownika na inną stronę”, tylko pomaga resolverowi DNS znaleźć właściwy serwer. To ważna różnica, bo przekierowanie HTTP i alias DNS rozwiązują zupełnie inne problemy. Za chwilę pokażę, jak to ustawić bez konfliktów z resztą strefy DNS.
Jak dodać CNAME bez bałaganu w DNS
Przy dodawaniu takiego wpisu nie chodzi o sam klik w panelu, tylko o poprawny układ nazw. Dobrze skonfigurowany CNAME jest prosty, ale źle wstawiony potrafi wywołać serię problemów: od niedziałającej strony po konflikt z pocztą albo certyfikatem SSL.
- Wybierz nazwę, która ma być aliasem, najczęściej subdomenę, na przykład `www`, `app` albo `cdn`.
- Ustal pełną nazwę docelową, czyli canonical name, do którego alias ma prowadzić.
- Sprawdź, czy pod tą samą nazwą nie istnieją już inne rekordy DNS.
- Wpisz cel dokładnie tak, jak wymaga panel hostingu, czasem z kropką na końcu, jeśli panel tego oczekuje.
- Zapisz zmiany i poczekaj na propagację, zwykle od kilkunastu minut do kilku godzin.
Praktycznie najczęściej widzę dwa scenariusze: `www` wskazuje na domenę główną albo subdomena wskazuje na adres nadany przez zewnętrzną platformę. Jeśli podczas migracji chcesz szybciej widzieć efekty, TTL warto czasowo ustawić niżej, na przykład na 300 lub 600 sekund. Po ustabilizowaniu konfiguracji można wrócić do 3600 sekund albo wartości zalecanej przez operatora. To nie skraca samego rozchodzenia się DNS do zera, ale ogranicza czas życia starej informacji w cache.
W praktyce dobrze ustawiony alias to połowa sukcesu. Druga połowa to zrozumienie ograniczeń, bo tu właśnie najczęściej pojawiają się nieporozumienia.
Ograniczenia, które najczęściej zaskakują
Domena główna jest wyjątkiem
Najważniejsze ograniczenie brzmi: zwykłego CNAME nie stawia się na domenie głównej, czyli w strefie typu `example.pl` bez żadnego prefiksu. Wynika to z tego, że taki rekord nie może współistnieć z obowiązkowymi wpisami DNS na tym poziomie, przede wszystkim z `NS` i `SOA`. Jeśli ktoś próbuje wymusić CNAME na root domeny, zwykle kończy się to błędną strefą albo obejściem typu ALIAS, ANAME lub CNAME flattening, jeśli operator to wspiera.
Jedna nazwa nie lubi konkurencji
Jeżeli pod tą samą nazwą istnieje CNAME, nie powinny tam stać inne rekordy, na przykład A, AAAA, MX czy TXT. To nie jest kaprys panelu, tylko zasada samego DNS. W praktyce oznacza to, że jeśli `www` ma być CNAME, to nie dorzucasz do `www` drugiego wpisu A „na wszelki wypadek”. Taki układ jest po prostu sprzeczny z logiką DNS.
Przeczytaj również: Cesja domeny OVHcloud - Jak przekazać bez błędów?
CNAME nie robi przekierowania w przeglądarce
To częsty błąd przy stronach i kampaniach marketingowych. Alias DNS nie zmienia adresu widocznego w pasku przeglądarki, więc jeśli chcesz przenieść użytkownika z jednej domeny na drugą i pokazać nowy URL, potrzebujesz przekierowania 301 albo 302 na poziomie serwera, CDN albo reguł hostingu. CNAME tylko pomaga dotrzeć do właściwego hosta.
Te trzy zasady porządkują większość wdrożeń. Gdy już je masz z tyłu głowy, sensownie wypada porównać CNAME z innymi typami rekordów.
CNAME a A, AAAA i ALIAS w praktyce
Najłatwiej podejmować decyzję nie po nazwie rekordu, tylko po tym, co ma finalnie zostać osiągnięte. Poniżej zestawienie, które zwykle wystarcza, żeby nie mylić podstawowych przypadków.
| Rekord | Do czego służy | Największa zaleta | Ograniczenie |
|---|---|---|---|
| A | Wskazuje adres IPv4 | Jest prosty i bezpośredni | Musisz znać konkretny adres IP |
| AAAA | Wskazuje adres IPv6 | Obsługuje infrastrukturę IPv6 | Nie zastąpi rekordu dla IPv4 |
| CNAME | Wskazuje nazwę na nazwę | Łatwo podłącza subdomeny i usługi zewnętrzne | Nie działa na domenie głównej i nie może mieć sąsiadów pod tą samą nazwą |
| ALIAS / ANAME | Rozwiązuje podobny problem jak CNAME, ale zwykle dla domeny głównej | Pomaga przy root domeny tam, gdzie CNAME jest niedozwolony | To rozwiązanie zależne od dostawcy DNS |
W praktyce wybór jest prosty: jeśli masz IP, użyj A albo AAAA. Jeśli masz nazwę hosta i pracujesz na subdomenie, CNAME zwykle będzie najlepszy. Jeśli celem jest domena główna, szukasz wsparcia dla ALIAS, ANAME albo flatteningu po stronie dostawcy DNS. Cloudflare stosuje CNAME flattening właśnie po to, żeby uprościć taki scenariusz, ale nie każdy operator daje identyczną funkcję.
Takie rozróżnienie oszczędza potem mnóstwo czasu przy wdrożeniach, migracjach i integracjach z narzędziami marketingowymi.
Gdzie ten rekord sprawdza się najlepiej
CNAME najlepiej pracuje tam, gdzie domena ma być tylko aliasem wygodnym dla użytkownika albo dla zewnętrznej platformy. W polskich wdrożeniach najczęściej widzę kilka powtarzalnych przypadków.
- `www` jako alias domeny głównej - wygodne przy stronach budowanych na zewnętrznym hostingu, CMS-ie albo kreatorze stron.
- `app`, `panel`, `dashboard` - dobry wybór, gdy panel aplikacji stoi na innym środowisku niż główna strona.
- `cdn` i `static` - sensowne przy dystrybucji zasobów, szczególnie gdy korzystasz z CDN.
- `verify`, `go`, `track` - częste w narzędziach marketingowych, analitycznych i przy weryfikacji własności domeny.
- Subdomeny techniczne - przy integracjach z platformami typu sklep, system rezerwacyjny, helpdesk lub mailing operacyjny.
To prowadzi do ostatniego kroku, który pomija wielu administratorów: weryfikacji i sensownego zaprojektowania strefy DNS na przyszłość.
Jak sprawdzić konfigurację i nie zablokować sobie kolejnych zmian
Po zapisaniu zmian nie zakładam od razu, że wszystko działa. Najpierw sprawdzam, czy rekord rzeczywiście się rozpropagował i czy nie ma konfliktów z cache DNS. Do szybkiej weryfikacji wystarcza zwykle `dig`, `nslookup` albo panel dostawcy hostingu, ale warto spojrzeć z dwóch różnych sieci, bo lokalny cache potrafi zamaskować problem.
- Sprawdź, czy nazwa wskazuje dokładnie na oczekiwany host, a nie na stary zapis z cache.
- Upewnij się, że pod tą samą nazwą nie ma drugiego rekordu, który wchodzi w konflikt.
- Zweryfikuj certyfikat SSL na końcowym hoście, bo sam DNS nie naprawi błędu HTTPS.
- Jeśli zmieniasz adres strony, ustaw osobno przekierowanie 301, zamiast liczyć na sam CNAME.
- Przy migracji trzymaj TTL niżej, a po zakończeniu wróć do stabilniejszej wartości.
Najlepsza praktyka, jaką stosuję przy nowych projektach, jest dość prosta: domenę główną prowadzę przez A, AAAA albo ALIAS, a CNAME zostawiam dla subdomen usługowych. Taki podział jest czytelny, mniej podatny na konflikty i znacznie łatwiejszy do utrzymania, kiedy za pół roku trzeba podmienić hosting, platformę sklepową albo narzędzie do marketing automation. Jeśli projektujesz DNS od zera, właśnie taka dyscyplina daje najwięcej spokoju w codziennej pracy.
