Rekord A w DNS to najprostszy sposób, by powiedzieć przeglądarce, pod jakim adresem IPv4 ma szukać strony. W praktyce od tego jednego wpisu zależy, czy domena otworzy się poprawnie, czy trafi na stary serwer albo w ogóle przestanie odpowiadać. Poniżej rozkładam temat na czynniki pierwsze: od działania w DNS, przez poprawne ustawienie, aż po błędy, które najczęściej psują migracje i zmiany hostingu.
Rekord A łączy domenę z konkretnym adresem IPv4 i steruje ruchem do strony
- Wskazuje adres IPv4, a nie samą nazwę hosta.
- Najczęściej używa się go dla domeny głównej, subdomen i prostych konfiguracji WWW.
- Zmiana nie działa natychmiast, bo odpowiedzi DNS są buforowane przez TTL.
- Przy IPv6 potrzebny jest rekord AAAA, a przy aliasach często lepiej sprawdza się CNAME.
- Najczęstszy błąd to stary adres IP, konflikt z innym rekordem albo wpisanie prywatnego IP do publicznego DNS.
- Jeśli zależy ci na prywatności, pamiętaj, że publiczny rekord A może zdradzać adres serwera.
Czym jest rekord A i kiedy w ogóle go potrzebujesz
Najkrócej: to wpis DNS, który mapuje nazwę domeny na adres IP w wersji IPv4. Litera A pochodzi od słowa address, więc nie chodzi o „ładną etykietę” dla domeny, tylko o konkretny adres, pod który ma trafić ruch. Jeśli serwer ma kilka adresów IPv4, można dodać kilka wpisów A dla tej samej nazwy, na przykład po to, by rozłożyć obciążenie albo przygotować prosty wariant awaryjny.
W codziennej pracy najczęściej widzę go przy domenie głównej, subdomenie www i prostych hostach typu blog, panel czy shop. To właśnie ten rekord sprawia, że twojadomena.pl nie jest tylko nazwą, ale realnym wskazaniem, dokąd ma pójść połączenie. Gdy już wiadomo, co dokładnie zapisuje, łatwiej zrozumieć, jak przeglądarka dochodzi do właściwego serwera.

Jak działa w DNS i dlaczego zmiana nie jest widoczna od razu
Mechanizm jest prosty, ale warto go rozumieć. Użytkownik wpisuje domenę, przeglądarka pyta resolver DNS, resolver odpyta serwery autorytatywne, dostanie adres IPv4 z rekordu A i dopiero wtedy połączy się z serwerem. DNS nie przesyła samej strony, tylko wskazówkę, gdzie ją znaleźć.
Opóźnienie bierze się z buforowania. Każda odpowiedź ma TTL, czyli czas życia wpisu w pamięci pośrednich serwerów DNS. Jeśli TTL jest niski, zmiana IP zaczyna działać szybciej. Jeśli jest wysoki, stare dane mogą wracać jeszcze przez dłuższą chwilę. Ja przy zmianach hostingowych zwykle obniżam TTL wcześniej, często do 300 lub 600 sekund, a dopiero potem podmieniam adres. To prosty ruch, który oszczędza nerwów.
Warto też pamiętać, że kilka rekordów A dla jednej nazwy nie oznacza automatycznie pełnego, inteligentnego przełączania awaryjnego. Czasem to tylko prosty round robin, czyli rozdzielanie zapytań między kilka adresów. Działa to sensownie przy identycznej zawartości i dobrze przygotowanej infrastrukturze, ale nie zastępuje prawdziwego monitoringu dostępności.
Skoro wiadomo już, jak DNS dochodzi do adresu IP, łatwiej ocenić, kiedy lepiej użyć samego A, a kiedy sięgnąć po inny typ rekordu.
Kiedy wybrać A, a kiedy AAAA albo CNAME
W praktyce najwięcej problemów bierze się nie z samego rekordu, tylko z wyboru niewłaściwego typu. Dla porządku porównuję to tak:
| Typ rekordu | Na co wskazuje | Kiedy ma sens | Ograniczenie |
|---|---|---|---|
| A | Adres IPv4 | Klasyczna strona WWW, subdomena, domena główna | Nie obsługuje IPv6 |
| AAAA | Adres IPv6 | Gdy serwer i sieć są gotowe na IPv6 | Nie zastąpi IPv4, jeśli część ruchu nadal go potrzebuje |
| CNAME | Inną nazwę hosta | Gdy subdomena ma być aliasem innej usługi lub domeny | Zwykle nie stosuje się go w domenie głównej bez dodatkowych mechanizmów |
Jeśli chcesz wskazać konkretny serwer po IPv4, wybór jest prosty. Jeśli masz pełne wsparcie dla IPv6, rekord AAAA warto dodać równolegle, żeby nie zamykać drogi użytkownikom korzystającym z tej wersji protokołu. A gdy subdomena ma tylko przekierować do innej nazwy, CNAME bywa wygodniejszy niż ręczne powielanie adresów. To właśnie w tym miejscu najłatwiej uniknąć niepotrzebnego bałaganu w strefie DNS.
W praktyce najważniejsze jest jedno: nie mieszaj przypadkowo różnych typów rekordów dla tej samej nazwy, bo potem trudno dojść, który wpis faktycznie wygrywa.
Jak ustawić go poprawnie w panelu DNS
Najbezpieczniej robić to krokami, nie na skróty. Ja zwykle sprawdzam najpierw źródłowy adres IP od hostingu, potem czy wpis ma dotyczyć domeny głównej, www, czy subdomeny, a dopiero później zapisuję rekord. W praktyce wygląda to tak:
- Zbierz publiczny adres IPv4 serwera, na który ma kierować domena.
- Ustal, czy konfigurujesz domenę główną (
@), subdomenę czy oba adresy naraz. - W panelu DNS wybierz typ
A. - W polu host/nazwa wpisz
@dla domeny głównej albo nazwę subdomeny, na przykładblog. - W polu wartość/target wpisz publiczny adres IPv4.
- Na czas migracji ustaw TTL na 300 lub 600 sekund, jeśli panel to umożliwia.
- Zapisz zmiany i usuń stare wpisy, które wskazują na nieaktualny serwer.
| Pole | Co wpisać | Przykład |
|---|---|---|
| Typ | A | A |
| Nazwa |
@ albo nazwa subdomeny |
@, blog
|
| Wartość | Publiczny IPv4 serwera | 203.0.113.10 |
| TTL | Krótszy przy zmianie, dłuższy po ustabilizowaniu | 300 s |
Jeśli konfigurujesz także www, możesz wskazać ten sam adres IP albo zrobić z www alias prowadzący do domeny głównej, o ile panel i infrastruktura to wspierają. Ważne, żeby dla jednej nazwy nie zostawić sprzecznych rekordów, bo wtedy w praktyce zaczyna się zgadywanie zamiast administracji. To prowadzi wprost do najczęstszych błędów, które potrafią wyłączyć stronę nawet po poprawnym wpisaniu IP.
Najczęstsze błędy, które psują stronę
Najbardziej kłopotliwe pomyłki są zwykle banalne. Z mojej perspektywy powtarzają się cztery scenariusze:
-
Wpisanie prywatnego adresu IP, na przykład z zakresu
192.168.x.xalbo10.x.x.x. Taki adres działa w sieci lokalnej, ale nie w publicznym DNS. - Zostawienie starego rekordu po migracji. Domenę dalej obsługuje poprzedni serwer, więc użytkownik widzi starą stronę albo błąd.
-
Konflikt A i CNAME dla tej samej nazwy. Często dzieje się to przy
www, gdy panel automatycznie dodał już wpis, a ktoś dorzucił drugi ręcznie. -
Zapomnienie o jednej wersji adresu, na przykład o domenie głównej bez
wwwalbo odwrotnie. Dla użytkownika to od razu wygląda jak niedziałająca strona.
Do tego dochodzi jeszcze jeden problem, który łatwo przegapić: stary rekord AAAA. Jeśli kiedyś był skonfigurowany i został bez kontroli, część ruchu może nadal iść inną ścieżką niż ruch po IPv4. To nie zawsze daje twardy błąd, ale potrafi tworzyć dziwne, trudne do zdiagnozowania objawy. Dlatego po każdej większej zmianie sprawdzam całą strefę, a nie tylko jeden wpis.
Gdy strona ma działać nie tylko poprawnie, ale też możliwie bezpiecznie i z rozsądnym poziomem prywatności, dochodzi jeszcze jeden aspekt, o którym wiele osób zapomina.
Co to oznacza dla prywatności i bezpieczeństwa domeny
Publiczny rekord A może ujawniać adres twojego serwera. To nie jest tragedia samo w sobie, ale warto wiedzieć, że osoba znająca domenę często może sprawdzić, pod jakim IP działa infrastruktura. Jeśli serwer stoi bezpośrednio w internecie, ten adres bywa łatwy do namierzenia i można go skanować albo próbować atakować. Z punktu widzenia bezpieczeństwa to ważne, bo sama nazwa domeny nie powinna zdradzać więcej, niż trzeba.
Jeżeli chcesz to ograniczyć, najpraktyczniejszym rozwiązaniem jest warstwa pośrednia, na przykład CDN albo reverse proxy. Wtedy rekord A wskazuje na usługę pośrednią, a nie bezpośrednio na origin, czyli serwer źródłowy. To nie ukrywa wszystkiego, ale znacząco zmniejsza ekspozycję. DNSSEC też ma sens, tylko trzeba jasno powiedzieć, czego nie robi: nie ukrywa IP i nie zastępuje dobrych rekordów, ale utrudnia podmianę odpowiedzi DNS po drodze.
Warto też oddzielać usługi. Strona WWW, poczta i panele administracyjne nie powinny z zasady wisieć na jednym, przypadkowo użytym adresie. Mniejsza liczba punktów styku to mniejsza powierzchnia ataku. Dla bloga o prywatności i bezpieczeństwie to szczególnie ważne, bo tu liczy się nie tylko działanie, ale też sposób, w jaki zbudowana jest widoczność całej domeny. Po takim podejściu zostaje już tylko szybka kontrola po zmianie, żeby nie ufać samemu panelowi DNS na słowo.
Co sprawdzić po zmianie, żeby DNS nie zaskoczył później
Po zapisaniu zmian nie zakładam od razu, że wszystko już działa. Najpierw sprawdzam odpowiedź DNS z kilku miejsc i porównuję ją z tym, co faktycznie mam na serwerze. Przydatne są proste testy, na przykład:
dig twojadomena.pl A
dig www.twojadomena.pl A
nslookup twojadomena.pl- Czy domena zwraca nowy adres IPv4, a nie stary.
- Czy
wwwi domena główna prowadzą tam, gdzie powinny. - Czy stara odpowiedź nie wraca jeszcze z cache po stronie resolvera.
- Czy certyfikat SSL pasuje do nowego hosta, jeśli zmieniał się także serwer.
- Czy rekordy pocztowe, TXT i inne wpisy pomocnicze nie zostały przypadkiem naruszone.
Jeśli wszystko zgadza się w testach, konfiguracja jest już poukładana. Właśnie tak rozpoznaję dobrze ustawiony rekord A: nie po samym wpisie w panelu, tylko po tym, że domena, subdomena i warstwa bezpieczeństwa zachowują się przewidywalnie. A to, przy DNS, jest dużo cenniejsze niż szybki klik bez sprawdzenia skutków.