Subdomena to pojęcie, które porządkuje przestrzeń adresową w internecie, pozwalając logicznie podzielić zasoby w obrębie jednej nazwy bazowej. Dla twórców stron www, administratorów i osób zarządzających marką jest to narzędzie organizacyjne, techniczne i strategiczne zarazem. W ujęciu słownikowym subdomena to etykieta (lub ciąg etykiet) dodana przed nazwą bazową (tzw. domeną nadrzędną), tworząca w pełni kwalifikowaną nazwę hosta. W praktyce umożliwia to uruchomienie wielu niezależnych serwisów, środowisk i usług pod jedną parasolową nazwą, z własnym ruchem, konfiguracją serwera i politykami bezpieczeństwa. Dzięki temu można oddzielić aplikację webową od panelu administracyjnego, serwis główny od wersji testowej, a także wydzielić geograficzne lub produktowe sekcje marki bez kupowania dodatkowych nazw.
Definicja i logika nazewnictwa
W najbardziej ścisłym sensie subdomena to każda część nazwy hosta dodana przed domeną nadrzędną. Jeśli nazwa bazowa to example.com, to adres blog.example.com lub eu.shop.example.com zawiera subdomenę odpowiednio blog lub eu.shop. Hierarchia jest czytelna: im dalej w lewo, tym bardziej szczegółowa część nazwy. Główna nazwa bazowa (example.com) bywa nazywana domeną drugiego poziomu (SLD), zaś końcowe rozszerzenie (.com, .pl, .org) to domena najwyższego poziomu (TLD). Każdy punkt rozdziela etykiety, czyli kolejne poziomy. To uporządkowanie oddaje strukturę systemu nazw i umożliwia przekazywanie odpowiedzialności za różne fragmenty przestrzeni adresowej niezależnym jednostkom.
Istotne jest odróżnienie subdomen od ścieżek URL. Adres blog.example.com i example.com/blog/ mogą wskazywać na ten sam serwis, ale w pierwszym przypadku mówimy o innym hoście w ramach tej samej przestrzeni nazw, a w drugim – o zasobie w obrębie tego samego hosta. Różnica jest zasadnicza technicznie: subdomena może wskazywać na inne serwery, mieć własny certyfikat, własne reguły cache’owania, a nawet oddzielne polityki bezpieczeństwa i rejestry DNS. Z kolei ścieżka to porządek wewnątrz jednego hosta. Z perspektywy odwiedzającego to często detal, ale dla architektury informacji i skalowalności aplikacji – kwestia kluczowa.
Znaki dozwolone w etykietach subdomen to litery, cyfry i łączniki, z ograniczeniem długości każdej etykiety do 63 znaków i całej nazwy (FQDN) do 253 znaków. Dla nazw w alfabetach narodowych stosuje się standard IDN i transliterację do Punycode, co pozwala używać znaków diakrytycznych, przy jednoczesnym zachowaniu kompatybilności z globalną infrastrukturą sieciową. Niektóre konwencje stały się de facto standardami – np. www. dla serwisu głównego czy m. dla wersji mobilnej – jednak nie mają one szczególnego statusu poza przyzwyczajeniem i praktyką wdrożeniową.
Warto też rozróżnić znaczenie nazw technicznych i marketingowych. “Panel” lub “admin” to nazwy czytelne dla zespołu, ale stanowią jednocześnie sygnał dla potencjalnych atakujących. Świadome nazewnictwo, maskowanie oczywistych przestrzeni administracyjnych i stosowanie odpowiednich mechanizmów uwierzytelniania pomaga zminimalizować ryzyko. Jednocześnie przejrzystość podziału na subdomeny sprzyja zarządzaniu cyklem życia usług – łatwiej wdrożyć osobne polityki wygaszania, retencji logów czy migracji.
Na poziomie semantyki marki subdomeny przenoszą znaczenia: region (pl., de.), linia produktów (shop., academy.), funkcja (api., static., img.). Zgodność tych etykiet z mapą usług zwiększa zrozumiałość oferty, a w konsekwencji ułatwia nawigację i komunikację z użytkownikiem.
Pierszeństwo ma jednak warstwa systemowa. Sama domena to kontener dla ustawień i delegacji, a subdomeny są praktycznymi uchwytami, które wiążą nazwy z konkretnymi adresami, usługami i politykami. Dzięki temu, bez kupowania nowych nazw, można wydzielać niezależne obszary działania i zarządzać nimi bardziej precyzyjnie.
Jak działają subdomeny w DNS
Mechanizmem, który sprawia, że subdomeny są rozwiązywane na adresy i usługi, jest system nazw domenowych – DNS. To rozproszona, hierarchiczna baza rekordów, w której każda strefa zarządza swoim fragmentem przestrzeni nazw. Z perspektywy subdomen kluczowe są dwa zjawiska: delegacja i rozwiązywanie rekordów. Delegacja (ang. zone cut) to sytuacja, w której właściciel domeny nadrzędnej wskazuje serwery nazw właściwe dla podstrefy, oddając za nią odpowiedzialność innemu zestawowi serwerów DNS. Dzięki temu subdomena może być utrzymywana niezależnie – przez inny zespół, dostawcę hostingu, region czy środowisko chmurowe.
Po stronie rozwiązywania rekordów mamy do czynienia z typami danych powiązanych z konkretną nazwą: A i AAAA wiążą nazwę hosta z adresem IP (IPv4 oraz IPv6), MX wskazuje serwery poczty, TXT przenosi metadane (np. dla weryfikacji własności, SPF, DKIM, polityk DMARC), SRV i napisy z prefiksami podkreślenia (_sip, _imap) definiują usługi. Dla subdomen szczególnie istotny jest rekord aliasujący CNAME, który sprawia, że nazwa nie wskazuje bezpośrednio na IP, lecz “wskazuje na wskazanie” – czyli inny host, którego adres ostatecznie zostanie rozwikłany. To kluczowe w środowiskach CDN, platformach PaaS i systemach o dynamicznej topologii, gdzie adres docelowy bywa zmienny, a zarządzanie aliasem jest wygodniejsze niż stałe aktualizacje IP.
Stosowany bywa również wzorzec wildcard – czyli rekord definiujący zachowanie dla wszystkich niejawnie zdefiniowanych subdomen w danym poziomie (np. *.example.com). Ułatwia to szybkie uruchamianie wielu subdomen bez każdorazowych zmian DNS, ale niesie implikacje bezpieczeństwa i diagnostyki: trudniej wykryć niezamierzone wskazania, a podatności typu subdomain takeover mogą mieć szerszy zasięg, jeśli “dzikie” nazwy są akceptowane przez infrastrukturę. Należy też pamiętać, że wildcard nie obejmuje nazw już jawnie zdefiniowanych ani subsubdomen, jeśli strefa została odcięta delegacją (zone cut).
Istotne są czasy życia rekordów (TTL), czyli okresy cache’owania odpowiedzi przez resolvery pośrednie i przeglądarki. Krótszy TTL ułatwia szybkie przełączenia ruchu i reagowanie na awarie, ale zwiększa liczbę zapytań DNS i obciążenie serwerów. Dłuższy TTL poprawia wydajność, kosztem elastyczności. W praktyce dla środowisk produkcyjnych stosuje się kompromisy – krótsze TTL dla krytycznych aliasów i dłuższe dla stabilnych rekordów A/AAAA. Warto też pamiętać, że apex (szczyt) strefy – np. example.com – nie może standardowo użyć CNAME, bo koliduje to z innymi rekordami strefy; w takich sytuacjach dostawcy oferują rekordy pseudo-typu ALIAS lub ANAME, które implementują alias na poziomie serwera autorytatywnego, zachowując kompatybilność.
Sama rozdzielczość DNS jest kaskadowa: od rootów, przez registry TLD, do serwerów autorytatywnych konkretnej domeny i ewentualnie delegowanych subdomen. Wydajność i niezawodność zapewnia redundancja serwerów nazw, georozproszenie i anycast. Dla projektów, które agresywnie korzystają z subdomen, warto zaprojektować strefy tak, by zachować czytelny podział odpowiedzialności (np. osobne serwery nazw dla regionów lub środowisk), oraz wprowadzić standardy nazewnictwa, które pozwolą uniknąć konfliktów i pułapek cache’owania.
Zastosowania praktyczne
Subdomeny pozwalają porządkować systemy i zespoły. Jedna firma może jednocześnie utrzymywać serwis główny pod www.example.com, panel klienta pod my.example.com, API pod api.example.com, statyczne zasoby pod static.example.com oraz wersję testową w staging.example.com. Każdy z tych hostów może mieć odrębny cykl wdrożeń, rolę w infrastrukturze i zespół utrzymaniowy. Dodatkowo łatwo kierować ruch na różne klastry – np. region-eu.example.com do europejskich centrów danych, zaś region-us.example.com do amerykańskich. Takie rozmieszczenie ułatwia spełnienie wymogów prawnych (lokalizacja danych), skraca opóźnienia sieciowe i upraszcza plany awaryjne.
Drugi obszar zastosowań to separacja ryzyka i wydajności. Jeśli kampania marketingowa zwiększy ruch w subdomenie event.example.com, serwis bazowy pozostaje stabilny. Analogicznie, nową usługę eksperymentalną można uruchomić w trybie beta w beta.example.com i dopiero po walidacji włączyć do głównego strumienia. Subdomena pozwala implementować mechanizmy cutover i canary release – najpierw część ruchu kierowana jest na nową infrastrukturę pod alternatywną nazwą, a po weryfikacji parametry ruchu są płynnie przesuwane.
Subdomeny wspierają też integrację z zewnętrznymi dostawcami. Usługi mailingowe, CDN, helpdesk czy narzędzia do obsługi dokumentów często wymagają skierowania konkretnej subdomeny na ich infrastrukturę. Dzięki temu zachowujesz spójność marki (adresy w Twojej domenie), a jednocześnie korzystasz z w pełni zarządzanych platform. W praktyce oznacza to dodanie odpowiednich rekordów w DNS oraz, opcjonalnie, konfigurację przekierowań i nagłówków, tak by zachować właściwe polityki bezpieczeństwa i prywatności.
W modelu SaaS powszechny jest schemat klient-w-subdomenie: klient1.example.com, klient2.example.com. Pozwala to izolować konfigurację i dane, jednocześnie zachowując centralne zarządzanie kodem i infrastrukturą. Należy jednak decyzję o takiej architekturze poprzedzić analizą kosztów operacyjnych (zarządzanie certyfikatami, logami, monitoringiem) oraz konsekwencjami w zakresie adresów, ciasteczek i uprawnień między hostami.
Popularnym wzorcem jest też wydzielenie poczty i usług towarzyszących: mail.example.com jako interfejs webmail, smtp.example.com i imap.example.com dla klientów pocztowych, z odrębnymi rekordami MX, SPF, DKIM i DMARC. Taki podział zwiększa przejrzystość, ułatwia debugowanie oraz porządkuje ruch sieciowy i zasady filtrowania w zaporach.
Nie należy zapominać o środowiskach developerskich. Subdomeny typu dev.example.com lub preview.feature-123.example.com wspierają recenzję kodu, testy przeglądarkowe i prezentacje dla interesariuszy. Pozwala to wdrażać mechanizmy ephemeral – krótkotrwałe, samoczynnie wygaszające się środowiska przypięte do gałęzi w repozytorium. Warunkiem bezpiecznego użycia jest jasna polityka dostępu oraz automatyczne czyszczenie rekordów i certyfikatów po domknięciu zadań.
Konfiguracja krok po kroku u dostawcy DNS i hostingu
Proces uruchomienia subdomeny zaczyna się od rozróżnienia ról: rejestrator (gdzie kupujesz domenę), dostawca serwerów nazw (gdzie utrzymujesz strefę DNS) i hosting/aplikacja (gdzie faktycznie działa usługa). Często te role pełni jedna firma, ale nie jest to konieczne. Najpierw upewnij się, że Twoje serwery nazw są właściwie skonfigurowane i odnotowane w rejestrze TLD – to one będą autorytatywne dla Twojej domeny.
Kiedy chcesz dodać nową subdomenę, zwykle wystarczy założyć rekord A/AAAA wskazujący na adres IP serwera, albo rekord aliasu – np. CNAME – wskazujący inny host, który z kolei rozwiązuje się na IP. Jeśli subdomena ma być delegowana innemu zespołowi lub dostawcy, utwórz rekordy NS dla tej subdomeny (zone cut), wskazujące serwery nazw nowej strefy. Od tej chwili konfiguracja poniżej tej etykiety będzie utrzymywana niezależnie. Dla środowisk dynamicznych (PaaS, CDN) często zaleca się aliasowanie, aby przerzucić odpowiedzialność za zmiany adresacji na dostawcę.
Po dodaniu rekordu zweryfikuj odpowiedź DNS przy użyciu narzędzi typu dig lub nslookup oraz serwisów diagnostycznych online. Jeśli czas życia rekordu (TTL) jest długi, zmiany mogą propagować się wolniej. W środowiskach, gdzie przewidujesz częste przełączenia (np. blue-green), ustaw krótsze TTL na etapie wdrożeń i po stabilizacji wydłuż wartości, aby zmniejszyć obciążenie i latencję zapytań.
Kolejny krok to konfiguracja warstwy aplikacyjnej/serwera. W przypadku serwera www ustaw nazwę hosta w wirtualnym hoście (np. server_name w Nginx, VirtualHost w Apache) lub w usłudze chmurowej (np. mapping domeny w usługach PaaS). Upewnij się, że żądania kierowane na nową subdomenę trafiają do właściwego backendu albo reverse proxy. Jeśli korzystasz z CDN, dodaj subdomenę jako źródło lub hosta końcowego i wdróż odpowiednie polityki cache, kompresji oraz nagłówki bezpieczeństwa.
Jeśli nazwa ma obsługiwać treści szyfrowane, przygotuj certyfikat i skonfiguruj endpointy do ruchu HTTPS. W przypadku wielu subdomen rozważ certyfikat typu SAN (Subject Alternative Name) lub wildcard – jednak ich dobór zależy od modelu ryzyka i częstości zmian. Dobrą praktyką jest automatyzacja wydawania i odnawiania certyfikatów w potokach CI/CD, tak by minimalizować okna podatności i błędy ludzkie. Pamiętaj też o odpowiednich przekierowaniach (301) między wariantami protokołu i hostów, aby uniknąć duplikacji treści oraz problemów z ciasteczkami i politykami bezpieczeństwa.
Dodatkowo, jeśli subdomena ma służyć do wysyłki e-mail, skonfiguruj właściwe rekordy TXT dla SPF, klucze DKIM, oraz politykę DMARC. Dla systemów telefonii lub usług czasu rzeczywistego użyj rekordów SRV. W infrastrukturze mikroserwisowej mapuj subdomeny na ingress w klastrach Kubernetes lub bramach API, utrzymując jednocześnie spójny system obserwowalności (metryki, logi, śledzenie żądań) na poziomie hostów.
Subdomeny a bezpieczeństwo, cookies i izolacja
Architektura oparta o subdomeny upraszcza separację obowiązków i uprawnień, ale też rodzi specyficzne ryzyka. Podstawowym mechanizmem uwierzytelniania przeglądarkowego są ciasteczka – cookies – których zasięg można kształtować atrybutem Domain. Ciasteczko ustawione na domenę nadrzędną (np. .example.com) będzie widoczne we wszystkich jej subdomenach, co ułatwia SSO i współdzielenie sesji, ale zwiększa potencjalną powierzchnię ataku: każdy host w tej przestrzeni może teoretycznie oddziaływać na stan sesji. Z kolei ciasteczka ograniczone do konkretnej subdomeny (np. auth.api.example.com) lepiej izolują kontekst, kosztem większej złożoności przy integracji. Dodatkowo atrybuty Secure, HttpOnly i SameSite pomagają ograniczać wektory XSS i CSRF oraz nadużycia przy wywołaniach między subdomenami.
Warstwa transportowa wymaga właściwego szyfrowania. Wdrożenie protokołów SSL i TLS na każdej subdomenie zapewnia poufność i integralność danych, a mechanizmy rozszerzające, takie jak HSTS z flagą includeSubDomains, wymuszają stałe użycie HTTPS w całym drzewie nazw. Deklaracja HSTS przyspiesza i utwardza ochronę przed downgrade’ami oraz atakami typu SSL stripping, ale wymaga dyscypliny: po jej aktywacji wszystkie subdomeny muszą konsekwentnie obsługiwać HTTPS, w przeciwnym razie część usług stanie się niedostępna dla współczesnych przeglądarek. Planując HSTS, wprowadź okres karencji i monitoruj zgodność hostów przed włączeniem includeSubDomains lub preload.
Szczególnej uwagi wymaga zjawisko subdomain takeover – przejęcia nieaktywnej subdomeny wskazującej na zewnętrzną platformę bez istniejącego zasobu. Typowa sytuacja: rekord CNAME kieruje na nazwę w usłudze chmurowej, ale dany zasób (np. instancja, bucket) został usunięty. Atakujący może utworzyć zasób pod identyczną nazwą w tej usłudze i w efekcie przejąć ruch na Twoją subdomenę. Mitigacje obejmują: inwentaryzację aliasów, automatyczne skanowanie “wiszących” wskazań, politykę usuwania rekordów po deprowizjonowaniu oraz stosowanie wzorców, które utrudniają tworzenie kolizyjnych nazw przez osoby trzecie.
Izolacja systemów to nie tylko przeglądarka. Na poziomie serwerów i chmury każde środowisko powinno mieć osobne tożsamości maszyn, polityki dostępu i tajemnice (sekrety). Nawet jeśli kilka subdomen wskazuje na jeden reverse proxy, downstream powinien być odseparowany logicznie (np. osobne namespace’y, sieci wirtualne, ograniczone reguły firewall). W praktyce oznacza to, że kompromitacja jednego hosta (np. panelu administracyjnego) nie pociąga automatycznie całego drzewa subdomen.
Wreszcie, polityki nagłówków bezpieczeństwa muszą być dostrojone per subdomena. Content-Security-Policy, Permissions-Policy, Referrer-Policy i X-Frame-Options bywają różne dla aplikacji API, paneli i serwisów publicznych. Takie różnicowanie jest łatwiejsze i klarowniejsze, gdy każdy typ usługi ma własną subdomenę, a nie jest modułem w obrębie jednego hosta.
Subdomeny a SEO, analityka i marketing
W obszarze widoczności w wyszukiwarkach subdomeny mają wymierne skutki. Algorytmy traktują je często jak oddzielne byty, co może rozproszyć autorytet strony głównej. To, czy wartość linków przechodzi między hostami w obrębie jednego TLD+1, zależy od wielu czynników i zmienia się w czasie. W praktyce, gdy treść jest ściśle powiązana z głównym serwisem i wspiera jego cele, subfoldery bywają korzystniejsze. Jeśli jednak treść ma inną funkcję, publiczność lub wymaga odmiennej technologii, osobna subdomena bywa właściwym wyborem. Optymalizacja SEO powinna więc uwzględniać architekturę informacji, strategię linkowania wewnętrznego i spójność sygnałów technicznych.
Trzeba też zadbać o uniknięcie duplikacji treści. Jeśli ten sam materiał jest dostępny pod kilkoma hostami (np. www.example.com i m.example.com), wprowadź rel=canonical i odpowiednie przekierowania. Dla wersji językowych używaj hreflang, a sitemapy utrzymuj osobno lub zbiorczo – w zależności od stopnia niezależności serwisów. Z perspektywy narzędzi analitycznych subdomeny mogą być raportowane jako odrębne strumienie lub scalone – zależnie od ustawień. Warto ustalić standardy tagowania kampanii (UTM) i struktury kont, aby zespoły marketingu, produktu i sprzedaży interpretowały dane spójnie.
Subdomeny mogą też wspierać eksperymenty i personalizację. Wydzielając hosty testowe lub tematyczne landing pages, ograniczasz wpływ testów na główny serwis i łatwiej zamykasz inicjatywy po ich zakończeniu. Pamiętaj jednak o blokadach indeksacji (robots.txt, noindex), jeśli nie chcesz, by treści pilotażowe błądziły po wynikach wyszukiwania. Zadbaj również o spójność sygnałów prędkości i stabilności (Core Web Vitals), bo użytkownik nie rozróżnia, czy powolna strona to subdomena czy subfolder – konsekwencje reputacyjne są wspólne.
Najczęstsze problemy i dobre praktyki
Na styku przeglądarki i backendu często pojawiają się kłopoty z CORS. Jeśli aplikacja na app.example.com odwołuje się do API na api.example.com, serwer API musi zwrócić odpowiednie nagłówki Access-Control-Allow-Origin oraz – w razie potrzeby – Access-Control-Allow-Credentials i nagłówki dla preflightu. Niedbała konfiguracja bywa przyczyną błędów produkcyjnych trudnych do reprodukcji. Warto wdrożyć testy end-to-end w środowiskach zbliżonych do produkcji i modelować ruch cross-subdomain w pipeline’ach CI.
Drugim klasykiem jest mieszana zawartość. Jeśli subdomena obsługuje wyłącznie HTTPS, ale ładuje skrypty lub obrazy z hostów serwujących HTTP, nowoczesne przeglądarki zablokują takie zasoby. Utrzymuj jednolite polityki protokołów i certyfikatów, a przy migracjach stosuj skanery wykrywające zależności. Podobnie z nagłówkami: brak spójności w HSTS lub CSP między subdomenami może prowadzić do nieprzewidzianych blokad lub luk.
W obszarze warstwy sieciowej pamiętaj o IPv6. Dodanie rekordów AAAA dla subdomen to nie tylko zgodność z trendami, ale i przewidywanie sytuacji, w których część użytkowników ma preferencję lub wyłączność ruchu po IPv6. Monitoruj jednak ścieżki trasowania i zachowanie CDN – różne regiony mogą mieć odmienną dostępność łącz i polityk peeringu, co wpłynie na doświadczenie użytkownika.
Jeśli korzystasz z CDN, dopilnuj spójności konfiguracji między subdomenami: reguł cache, kompresji, minifikacji, odświeżania, a także warstw WAF i bot management. Subdomeny o innej funkcji mogą wymagać innych polityk – np. API powinno mieć mniejsze okna cache i ostrzejsze limity zapytań, podczas gdy statyczne zasoby mogą być agresywnie buforowane. Brak rozróżnienia skutkuje problemami wydajności i bezpieczeństwa.
Na gruncie poczty łatwo o niespójność: subdomeny używane do wysyłki e-mail powinny mieć właściwe rekordy SPF, klucze DKIM i polityki DMARC. Wysyłka marketingowa z dedykowanej subdomeny (np. mail.example.com) pomaga izolować reputację nadawcy i ograniczać skutki incydentów. Upewnij się, że łączysz telemetry (bounce, spam complaint) z właściwą subdomeną, by szybko reagować na problemy dostarczalności.
Kwestie IDN i Punycode bywają zdradliwe. Subdomeny w alfabetach narodowych wymagają szczególnej uwagi przy certyfikatach, logach i analizie bezpieczeństwa, ponieważ różne reprezentacje znaków mogą utrudniać korelację zdarzeń. Wspieraj zespoły narzędziami, które prezentują nazwy w obydwu formach (Unicode i Punycode), a w politykach bezpieczeństwa uwzględnij ryzyka homograficzne.
Wreszcie, dobra praktyka operacyjna to inwentaryzacja i budżet. Każda subdomena to koszt: utrzymania, certyfikatu, monitoringu, alertingu, testów i dokumentacji. Z czasem w organizacjach powstają “zapomniane” subdomeny, które stają się wektorem ataku lub źródłem błędów. Cykl życia subdomen powinien być prowadzony tak samo rygorystycznie jak cykl życia usług – z właścicielem, SLO, planem awaryjnym i procesem wygaszania.
FAQ
- Co to jest subdomena w jednym zdaniu?
To etykieta dodana przed nazwą bazową, tworząca osobnego hosta w tej samej przestrzeni nazw, z własnymi rekordami i konfiguracją usług.
- Czym subdomena różni się od katalogu w URL?
Subdomena to inny host (może wskazywać inny serwer, mieć własne certyfikaty i polityki), a katalog to zasób w obrębie tego samego hosta.
- Czy subdomeny kosztują dodatkowo?
Nie płaci się za samą subdomenę, lecz za infrastrukturę i operacje z nią związane (DNS, certyfikaty, hosting, monitoring).
- Jak utworzyć subdomenę krok po kroku?
Dodaj rekord w strefie (A/AAAA lub CNAME), skonfiguruj serwer/hosting dla tej nazwy, wdroż HTTPS i ewentualne przekierowania, a na koniec zweryfikuj działanie.
- Ile trwa propagacja zmian DNS?
Od kilku minut do 48 godzin, zależnie od TTL oraz cache’y po drodze; w praktyce najczęściej kilkadziesiąt minut.
- Czy mogę użyć dzikiej karty, aby obsłużyć wiele subdomen naraz?
Tak, wildcard (*.example.com) obejmuje niejawnie zdefiniowane subdomeny na danym poziomie, ale wymaga ostrożności operacyjnej i bezpieczeństwa.
- Czy subdomeny pomagają w pozycjonowaniu?
Zależy od celu. Dla treści blisko spokrewnionej z serwisem częściej lepszy jest subfolder; dla odrębnych usług lub publiczności – subdomena bywa właściwa.
- Czy można mieć różne serwery dla każdej subdomeny?
Tak, to jedna z głównych zalet – każda subdomena może wskazywać inny adres IP, usługę, region lub dostawcę.
- Jak działają ciasteczka między subdomenami?
Zakres ciasteczek definiuje atrybut Domain. Ustawione globalnie (np. .example.com) są widoczne we wszystkich subdomenach; ograniczone – tylko w swojej.
- Czy mogę mieć osobny certyfikat dla każdej subdomeny?
Tak. Możesz też użyć certyfikatu SAN lub wildcard, zależnie od liczby hostów i polityki bezpieczeństwa.
- Jak uniknąć subdomain takeover?
Regularnie inwentaryzuj aliasy, usuwaj “wiszące” rekordy po deprowizjonowaniu zasobów, monitoruj zmiany i stosuj kontrolę dostępu do platform zewnętrznych.
- Czy nazwy subdomen mogą zawierać podkreślenia lub polskie znaki?
Etykiety hostów nie powinny zawierać podkreśleń; dla znaków narodowych stosuje się IDN i Punycode (transliterację).
- Co lepsze: www.example.com czy example.com?
To głównie kwestia konwencji i infrastruktury. WWW bywa wygodne przy użyciu CDN, cookies i HSTS; ważne, by kanonizować jeden wariant i konsekwentnie przekierowywać drugi.
- Czy mogę przenieść tylko jedną subdomenę do innego dostawcy?
Tak, przez delegację NS dla tej subdomeny (zone cut). Od tego momentu zarządza nią inny zestaw serwerów nazw.
- Jakie są limity liczby subdomen?
Formalnie ogranicza Cię długość FQDN i praktyka operacyjna. Upewnij się, że potrafisz nimi zarządzać: certyfikaty, monitoring, bezpieczeństwo.
- Czy subdomeny ułatwiają wdrażanie mikroserwisów?
Tak, bo pozwalają odwzorować granice usług w przestrzeni adresowej, uprościć routing i polityki bezpieczeństwa, a także skalować zależnie od potrzeb.
- Czy subdomeny wpływają na analitykę?
Domyślnie narzędzia często traktują je oddzielnie. Skonfiguruj łączenie strumieni lub cross-domain tracking, jeśli chcesz analizować ruch jako całość.
- Jak ustalić, kiedy wybrać subdomenę, a kiedy katalog?
Gdy potrzebujesz innej infrastruktury, polityk lub izolacji – wybierz subdomenę. Gdy treść i cel są wspólne – rozważ katalog ze spójnym hostem.
601 162 666
