DNS to system, który zamienia przyjazne dla człowieka nazwy stron (np. mojafirma.pl) na adresy IP zrozumiałe dla komputerów (np. 203.0.113.10).
Bez tego tłumacza internet dla zwykłego użytkownika byłby praktycznie nieużywalny – trzeba by zapamiętywać długie numery zamiast prostych nazw.
Najprostsza analogia: książka telefoniczna lub lista kontaktów w telefonie. Człowiek pamięta imię i nazwisko, a telefon na tej podstawie wybiera numer. W DNS jest podobnie – przeglądarka „pyta” o numer IP dla danej nazwy domeny i dopiero wtedy łączy się z serwerem.
Problem, który DNS rozwiązuje, wygląda tak:
człowiek: zapamiętuję nazwy (google.com, onet.pl, mojasklep.pl),
komputer: rozumie adresy IP (np. 142.250.74.78),
DNS: tłumaczy jedną postać na drugą w ułamku sekundy.
DNS działa prawie przy każdym wejściu na stronę www, wysłaniu e‑maila, użyciu aplikacji w chmurze. Użytkownik tego nie widzi, ale w tle cały czas lecą zapytania DNS. Gdy coś się zepsuje, przeglądarka nie wie, na jaki adres IP ma się połączyć – wtedy pojawiają się błędy typu „DNS_PROBE_FINISHED_NXDOMAIN” albo „Nie można odnaleźć adresu serwera”. Efekt jest taki, jakby internet stanął, mimo że łącze fizycznie działa.
Podstawowe pojęcia DNS bez żargonu
Nazwa domenowa, subdomena i końcówka TLD
Przykład rozbity na części: www.mojadomena.pl.
pl – to TLD (Top Level Domain), czyli końcówka najwyższego poziomu, np. .pl, .com, .eu, .org.
mojadomena.pl – to domena główna (tzw. domena drugiego poziomu + TLD).
www.mojadomena.pl – to subdomena (poddomena) domeny mojadomena.pl.
Subdomeną jest wszystko, co stoi po lewej stronie od domeny głównej. Przykłady:
panel.mojadomena.pl – np. panel klienta,
blog.mojadomena.pl – blog firmy,
dev.mojadomena.pl – środowisko testowe.
Technicznie nawet www to subdomena. Część firm rezygnuje dziś z „www” i używa po prostu mojadomena.pl. Z punktu widzenia DNS to po prostu inna nazwa, dla której trzeba zdefiniować odpowiedni rekord.
Strefa DNS – czyli gdzie zapisane są rekordy
Dla każdej domeny istnieje coś takiego jak strefa DNS. To po prostu zestaw rekordów, które mówią: „ta nazwa wskazuje na ten adres IP, ta na inny, tutaj jest poczta, tutaj tekst weryfikacyjny itd.”.
Dla domeny mojadomena.pl w strefie DNS można mieć między innymi:
rekord A dla mojadomena.pl – adres IP serwera www,
rekord A dla www.mojadomena.pl – może wskazywać na ten sam IP,
rekord MX – informacja, gdzie trafia poczta dla @mojadomena.pl,
rekord TXT – np. SPF, weryfikacje Google Search Console, itp.
Strefę DNS najczęściej edytuje się w panelu rejestratora domeny lub w panelu hostingu. Warto rozróżniać:
domena – adres, który kupujesz (np. u OVH, home.pl, nazwa.pl, itd.),
hosting / serwer – miejsce, gdzie leży strona i baza danych.
Jedno nie wymusza drugiego. Domena może być kupiona w firmie A, a serwer w firmie B. Spina to właśnie DNS.
Adres IP (IPv4, IPv6) w kontekście DNS
Adres IP to unikalny numer urządzenia w sieci. W uproszczeniu:
IPv4 – klasyczna postać typu 203.0.113.10,
IPv6 – nowsza, dłuższa forma, np. 2001:db8:85a3::8a2e:370:7334.
Prosta analogia: internet jako miasto, serwer jako blok, a adres IP jako dokładny adres mieszkania w tym mieście. Każdy serwer ma swój adres IP, często kilka.
Użytkownik zna tylko nazwę. Maszyna potrzebuje numeru. Stąd znaczenie DNS przy każdym połączeniu z dowolną usługą sieciową.
Jak działa zapytanie DNS krok po kroku
Droga od paska adresu do odpowiedzi DNS
Scenariusz: użytkownik wpisuje w przeglądarce sklepxyz.pl i naciska Enter. Co się dzieje, zanim pojawi się strona?
Przeglądarka sprawdza własny cache DNS (pamięć, co niedawno odwiedzałeś).
System operacyjny (Windows, macOS, Linux, Android itd.) sprawdza swój cache.
System wysyła zapytanie do lokalnego serwera DNS (zwykle router lub DNS od dostawcy internetu ustawiony w systemie).
Jeśli lokalny DNS nie zna odpowiedzi, rozpoczyna rekurencyjne wyszukiwanie w sieci.
Po otrzymaniu odpowiedzi adres IP jest zapisywany w cache i przekazywany do przeglądarki.
Przeglądarka na podstawie IP łączy się z serwerem www (np. protokołem HTTPS).
Jeśli na którymś etapie odpowiedzi DNS nie uda się ustalić (nazwa nie istnieje, błąd w konfiguracji strefy), strona się nie wyświetli, mimo że sam serwer może działać poprawnie.
Różne typy serwerów DNS i ich rola
Na drodze zapytania DNS pojawia się kilka rodzajów serwerów:
Resolver (serwer rekursywny) – pierwszy, do którego pyta system. Najczęściej to:
DNS od dostawcy internetu (ISP),
DNS ustawiony ręcznie (Google 8.8.8.8, Cloudflare 1.1.1.1, itp.),
dns w routerze, który przekazuje dalej.
Serwery root – wiedzą, gdzie znaleźć serwery odpowiedzialne za poszczególne TLD (.pl, .com, .org, itd.).
Serwery TLD – dla konkretnej końcówki domeny (np. .pl), wskazują, gdzie są autorytatywne serwery dla danej domeny, np. sklepxyz.pl.
Autorytatywny serwer DNS – ten, który trzyma faktyczną strefę DNS domeny. Tutaj jest „prawda” o tym, jaki IP ma sklepxyz.pl, jakie są rekordy MX, itd.
Resolver wykonuje całą „brudną robotę”:
Pyta serwery root: „kto wie coś o .pl?”
Serwery root odsyłają: „idź do serwerów TLD dla .pl”.
Serwery TLD .pl mówią: „autorytatywne serwery dla sklepxyz.pl to ns1.hosting.pl, ns2.hosting.pl”.
Resolver pyta już konkretnie ns1.hosting.pl o rekord dla sklepxyz.pl.
Otrzymuje odpowiedź, zapisuje ją w cache i odsyła do użytkownika.
Ten łańcuch brzmi długo, ale zwykle trwa ułamek sekundy, zwłaszcza że większość odpowiedzi jest już w cache na różnych poziomach.
Realistyczny przykład przepływu zapytania DNS
Użytkownik w domu wpisuje w Chrome adres sklepxyz.pl:
Chrome sprawdza, czy niedawno nie odwiedzał tej strony. Jeśli tak – używa zapisanej odpowiedzi DNS.
Jeśli nie, system (np. Windows) wysyła zapytanie DNS do routera (np. 192.168.0.1).
Router ma skonfigurowane DNS od operatora, np. 89.x.x.x. Przekazuje więc pytanie dalej.
DNS operatora (resolver) patrzy w swój cache. Jeśli w ostatnim czasie ktoś inny pytał o sklepxyz.pl, wynik jest od razu.
Jeśli nie, resolver przechodzi pełną ścieżkę: root → TLD .pl → autorytatywny DNS sklepxyz.pl.
Odpowiedź (np. 203.0.113.25) trafia z powrotem do operatora, do routera, do systemu i do przeglądarki.
Dzięki pamięci podręcznej (cache) kolejne zapytania o tę samą domenę są już dużo szybsze. Kluczowy parametr to TTL, o którym więcej dalej.
Źródło: Pexels | Autor: Brett Sayles
Serwery DNS – jakie masz opcje i od kogo zależy odpowiedź
DNS od operatora, publiczne serwery i DNS w routerze
Na zwykłym komputerze, telefonie lub routerze zawsze jest ustawiony jakiś serwer DNS. To do niego trafiają pierwsze zapytania.
Najczęstsze opcje:
DNS od dostawcy internetu (ISP) – ustawiany automatycznie przez DHCP. Użytkownik często nawet nie wie, że z niego korzysta.
Publiczny DNS – ręcznie wpisany w systemie lub routerze, np.:
Google DNS: 8.8.8.8, 8.8.4.4,
Cloudflare DNS: 1.1.1.1, 1.0.0.1,
Quad9: 9.9.9.9.
Lokalny DNS – np. w większej firmie działa własny serwer DNS, przez który przechodzą wszystkie zapytania.
Gdy zmieniasz DNS w systemie lub routerze, w praktyce decydujesz:
kto będzie odpowiadał na Twoje zapytania DNS,
jak szybko będzie działać rozwiązywanie nazw,
jakie dodatkowe filtry będą stosowane (np. blokada złośliwych domen, kontroli rodzicielskiej).
Dlaczego zmiana serwera DNS czasem „naprawia” internet
Częsty przypadek: internet „działa” (np. komunikator łączy się), ale strony się nie otwierają lub otwierają się wybiórczo. Bardzo często problem leży w serwerze DNS operatora.
Przełączenie na publiczny DNS (np. 1.1.1.1 lub 8.8.8.8) bywa wtedy szybką diagnozą:
jeśli po zmianie DNS wszystko rusza – problem był po stronie operatora,
jeśli nadal nie działa – szuka się dalej (np. firewall, awaria sieci, błąd po stronie hostingu).
Zmiana DNS nie naprawia uszkodzonego łącza, ale potrafi usunąć problemy typu:
przestarzały cache DNS po stronie operatora,
czasowe awarie serwerów DNS dostawcy,
zbyt agresywne filtry (np. blokowanie niektórych domen).
Kiedy warto mieć własny serwer DNS
W małej firmie lub domu najczęściej wystarczy publiczny DNS lub ten od operatora. Własny serwer DNS ma sens, gdy:
jest wewnętrzna sieć z wieloma urządzeniami i własnymi nazwami,
potrzebne są wewnętrzne domeny (np. serwer.intranet.lan),
chce się mieć pełną kontrolę nad cache, filtrami, logami.
W praktyce dla początkujących administracja własnym serwerem DNS jest zwykle zbędna. Lepiej skupić się na poprawnej konfiguracji strefy domeny u rejestratora lub hostingu.
Najważniejsze typy rekordów DNS w praktyce
Rekord A i AAAA – podstawowe powiązanie z adresem IP
Rekord A (Address) łączy nazwę domeny z adresem IPv4.
Przykładowe wpisy w strefie DNS dla domeny mojafirma.pl:
@ (czyli samo mojafirma.pl) → 203.0.113.10
www (www.mojafirma.pl) → 203.0.113.10
panel (panel.mojafirma.pl) → 203.0.113.20
Znak @ w wielu panelach oznacza „domena główna”. To skrót, nie osobna nazwa.
Rekord CNAME – alias, czyli „druga nazwa” tej samej usługi
CNAME (Canonical Name) tworzy alias: jedna nazwa wskazuje na inną nazwę, a nie bezpośrednio na IP.
Przykład dla mojafirma.pl:
www → mojafirma.pl (CNAME)
mojafirma.pl → 203.0.113.10 (A)
Gdy zmienia się IP w rekordzie A domeny głównej, alias www automatycznie idzie za nim. Nie trzeba aktualizować wielu miejsc.
CNAME często stosuje się też przy usługach zewnętrznych:
blog → firmablog.platforma.com (CNAME)
Zapytanie trafia wtedy najpierw na CNAME, a potem na właściwy rekord A/AAAA wskazany przez dostawcę usługi.
CNAME nie powinien być używany dla domeny głównej (nagiego @) u większości dostawców – może to psuć inne rekordy (np. MX).
Rekord MX – gdzie trafia poczta dla Twojej domeny
MX (Mail Exchanger) wskazuje, na jaki serwer mają być dostarczane e-maile dla domeny.
Przykład:
@ (mojafirma.pl) → 10 mail1.mojafirma.pl
@ (mojafirma.pl) → 20 mail2.mojafirma.pl
Liczba przed nazwą (10, 20) to priorytet. Niższa liczba = wyższy priorytet. Najpierw używany jest serwer z priorytetem 10, jeśli jest niedostępny – próbowany jest 20.
Same rekordy MX nie zawierają IP. Wskazują nazwy, które dalej muszą mieć rekordy A lub AAAA:
mail1.mojafirma.pl → 203.0.113.30 (A)
mail2.mojafirma.pl → 203.0.113.31 (A)
Jeśli MX wskazuje na nazwę bez poprawnego A/AAAA, poczta często „znika” lub wraca z błędami. To jedna z typowych usterek przy migracjach.
Rekord TXT – potwierdzenia, bezpieczeństwo i „dziwne” ciągi znaków
TXT przechowuje dowolny tekst. W praktyce służy głównie do:
potwierdzania własności domeny (Google, Facebook, narzędzia SEO),
Taki wpis mówi serwerom pocztowym, które adresy IP są uprawnione do wysyłania maili z Twojej domeny.
Przy weryfikacjach zewnętrznych usług zwykle dodaje się rekord typu:
google-site-verification=losowy_ciag_znakow
Dokładną treść dostarcza usługodawca, a po dodaniu i odczekaniu TTL domena zostaje potwierdzona.
Rekord NS – kto jest „szefem” strefy DNS
NS (Name Server) wskazuje, które serwery są autorytatywne dla danej domeny.
Przykładowy zestaw:
ns1.hosting.pl
ns2.hosting.pl
Te wpisy istnieją na dwóch poziomach:
u rejestratora domeny – tam wskazuje się, jakie serwery obsługują całą strefę,
w samej strefie DNS – tam są rekordy NS zgodne z tym, co u rejestratora (tzw. delegacja spójna).
Jeśli zmienia się dostawcę hostingu lub panel DNS, zwykle zmienia się właśnie rekordy NS u rejestratora.
Rekord SOA – metadane strefy
SOA (Start of Authority) to „nagłówek” strefy DNS. Zawiera m.in.:
nazwę głównego serwera DNS,
adres e‑mail administratora (w formie z kropką zamiast @),
numer seryjny strefy,
parametry odświeżania między serwerami master/slave.
W większości paneli hostingowych SOA jest ustawiany automatycznie. Początkujący zwykle nie muszą go zmieniać.
Inne przydatne typy: SRV, CAA, PTR
W codziennej konfiguracji mogą się jeszcze przewijać:
SRV – określa port i adres dla konkretnej usługi, np. VoIP, Minecraft, Office 365,
CAA – wskazuje, które urzędy certyfikacji mogą wystawiać certyfikaty SSL dla domeny,
PTR – rekord odwrotny (reverse DNS), mapujący IP → nazwę domeny, ważny przy poczcie.
PTR ustawia zwykle operator, który zarządza adresem IP (ISP, dostawca serwera). Nie robi się tego w standardowej strefie domeny.
TTL, cache i „magiczne” opóźnienia, czyli propagacja DNS
Co to jest TTL w rekordach DNS
TTL (Time To Live) to czas, przez jaki odpowiedź DNS może być przechowywana w cache pośrednich serwerów i urządzeń.
TTL podaje się w sekundach. Typowe wartości:
300 (5 minut),
3600 (1 godzina),
14400 (4 godziny),
86400 (24 godziny).
Im niższy TTL, tym szybciej zmiany w DNS „rozchodzą się” po świecie, ale tym częściej serwery muszą pytać autorytatywny DNS.
Jak działa cache DNS na różnych poziomach
Odpowiedzi DNS są zapamiętywane na kilku warstwach:
przeglądarka (cache DNS w Chrome, Firefox itd.),
system operacyjny (resolver w Windows, macOS, Linux),
router domowy,
serwer DNS operatora lub publiczny DNS.
Dopóki TTL odpowiedzi nie wygaśnie, kolejne zapytania o tę samą domenę nie idą dalej, tylko korzystają z pamięci podręcznej najbliższego poziomu.
Z tego powodu jedna osoba może już widzieć stronę na nowym serwerze, a inna – jeszcze na starym, choć od zmiany minęło kilka minut.
Skąd się bierze „propagacja DNS”
Po zmianie rekordu DNS wszyscy, którzy mieli starą odpowiedź w cache, muszą „doczekać” do końca TTL.
Przykład:
rekord A dla mojafirma.pl miał TTL = 86400 (24h),
o 10:00 użytkownik X odwiedził stronę, więc jego DNS zapisał starą wartość,
o 11:00 zmieniono IP domeny,
dla użytkownika X zmiana może być widoczna dopiero po około 24 godzinach od pierwszego zapytania.
W praktyce większość użytkowników trafia na nowe IP szybciej, bo różne serwery pytały o domenę w różnym czasie. Stąd wrażenie, że „u jednych już działa, u innych jeszcze nie”.
Jak planować zmiany DNS, żeby nie było niespodzianek
Przed większą zmianą (np. migracja strony na inny serwer) dobrze jest obniżyć TTL na kluczowych rekordach (A, AAAA, MX) z wyprzedzeniem.
Praktyczny scenariusz:
Na 24–48 godzin przed planowaną migracją zmniejsz TTL z 86400 na np. 600 (10 minut).
Odczekaj, aż stare, długie TTL-y wygasną w cache większości serwerów.
Wykonaj właściwą zmianę (np. zmień IP w rekordzie A).
Obserwuj ruch, sprawdź z kilku sieci, czy wszystko działa.
Po kilku godzinach przywróć TTL do wyższej wartości (np. 14400 lub 86400).
Taki schemat skraca okres „rozjechania” między starym a nowym IP. Dobrze sprawdza się przy sklepach i serwisach, które nie mogą sobie pozwolić na dłuższy chaos.
Dlaczego ping i WHOIS nie zawsze pokazują aktualne dane
Polecenie ping domena.pl korzysta z lokalnego rozwiązywania nazw, więc może używać jeszcze starych danych z cache. Dlatego dwie osoby pingujące tę samą domenę równolegle mogą widzieć inne IP.
WHOIS w ogóle nie pokazuje rekordów DNS (poza NS i danymi domeny). Do sprawdzania aktualnych rekordów A/MX/TXT lepsze są narzędzia typu dig, nslookup lub strony webowe do testowania DNS.
Konfiguracja DNS swojej domeny krok po kroku (scenariusz podstawowy)
Co musisz mieć przed konfiguracją
Przy prostym scenariuszu „strona + poczta” wystarczą trzy rzeczy:
domena zarejestrowana u rejestratora,
serwer www lub konto hostingowe (adres IP albo nazwy serwerów DNS),
dostawca poczty (czasem ten sam co hosting, czasem zewnętrzny, np. Google Workspace, Microsoft 365).
Od tego, kto dostarcza którą usługę, zależy, gdzie dokładnie będziesz klikać i co wpisywać.
Krok 1: wybór, kto będzie obsługiwał DNS
Na początek decydujesz, gdzie będzie leżała strefa DNS domeny:
u rejestratora (domyślne serwery DNS rejestratora),
u dostawcy hostingu (zmiana NS na ns1.hosting.pl, ns2.hosting.pl),
u zewnętrznego dostawcy DNS (np. Cloudflare, DNS od panelu serwerów dedykowanych).
Dla początkujących najprościej jest użyć panelu DNS tam, gdzie jest hosting strony. Wtedy większość wpisów www tworzy się automatycznie.
Krok 2: ustawienie serwerów NS u rejestratora
W panelu rejestratora (tam, gdzie kupiono domenę) szukasz opcji typu „serwery nazw / DNS / delegacja”. Tam wprowadzasz nazwy NS podane przez hosting.
Przykład:
ns1.hosting.pl
ns2.hosting.pl
Po zapisaniu zmiany trzeba poczekać, aż nowe NS-y zaczną obowiązywać. To też podlega propagacji, ale zazwyczaj kilka godzin wystarcza, by większość sieci widziała już nową delegację.
Krok 3: rekord A (i ewentualnie AAAA) dla domeny i www
W panelu DNS hostingu tworzysz lub sprawdzasz rekordy:
@ (domena główna) → IP serwera www (rekord A),
www → albo to samo IP (A), albo CNAME na domenę główną.
Przykład:
@ A 203.0.113.10 TTL 3600
www CNAME mojafirma.pl. TTL 3600
Jeśli serwer obsługuje IPv6, dodajesz analogiczne rekordy AAAA z adresem IPv6.
Krok 4: konfiguracja poczty – rekordy MX i powiązane
Jeśli poczta jest na tym samym hostingu co strona, panel często doda MX-y sam. Dobrze je mimo to sprawdzić.
Przykład dla hostingu:
@ MX 10 mail.mojafirma.pl.
mail A 203.0.113.30
Gdy korzystasz z zewnętrznego dostawcy poczty (np. Google Workspace), w panelu DNS wpisujesz dokładnie takie MX-y, jakie podaje dostawca. Stare, niepotrzebne MX-y warto usunąć, żeby nie było konfliktów.
Krok 5: rekordy TXT dla poczty (SPF, DKIM, DMARC)
Dostawcy poczty podają konkretne rekordy TXT, które trzeba skopiować do strefy domeny. Zwykle będą to:
SPF – główny rekord opisujący dozwolone źródła wysyłki,
DKIM – klucz publiczny dla podpisów wiadomości,
DMARC – polityka postępowania z podejrzanymi mailami.
Nie powinno się mieć kilku różnych rekordów SPF dla tej samej nazwy. Jeśli konfigurujesz dodatkowego nadawcę (np. system newsletterów), dopisujesz go do istniejącego SPF zamiast tworzyć drugi.
Krok 6: przekierowanie z www na bez www (albo odwrotnie)
DNS nie robi przekierowań HTTP. To rola serwera www. DNS jedynie wskazuje, które IP ma domena i jej subdomeny.
Jeśli chcesz, żeby wszystko działało pod jedną wersją (np. tylko bez www), zwykle:
ustawiasz A/CNAME tak, by www i domena główna wskazywały na ten sam serwer,
w konfiguracji serwera (Apache, Nginx, panel hostingowy) ustawiasz przekierowanie 301 z jednej wersji na drugą.
Od strony DNS wystarczy, że obie nazwy „trafiają” na działający serwer. Resztą zajmuje się konfiguracja www.
Krok 7: testy z różnych miejsc
Jak sprawdzać swoją konfigurację DNS w praktyce
Po zapisaniu zmian nie ma sensu czekać „aż samo zadziała”. Konfigurację można zweryfikować od razu z kilku narzędzi.
Dodatkowo warto użyć serwisów webowych typu „DNS lookup” / „DNS checker”, które pokazują odpowiedzi z wielu lokalizacji na świecie. Dobrze widać wtedy, jak wygląda propagacja.
Jeśli coś nie działa, zacznij od prostych pytań:
czy domena wskazuje na poprawne IP (rekord A/AAAA),
czy rekord MX istnieje i prowadzi na nazwę, która ma rekord A/AAAA,
czy w strefie nie ma sprzecznych wpisów (np. kilka MX o tej samej wadze do różnych dostawców).
Drobny błąd w nazwie hosta lub brak kropki na końcu przy MX/CNAME potrafi zablokować pocztę na wiele godzin.
Typowe błędy początkujących przy konfiguracji DNS
Przy pierwszych podejściach powtarza się kilka tych samych wpadek.
Mylenie domeny z hostem – dodanie rekordu A dla www.mojafirma.pl zamiast dla www, przez co panel traktuje to jak osobną, pełną nazwę.
Brak kropki na końcu FQDN – np. mail IN MX 10 mail.mojafirma.pl zamiast mail.mojafirma.pl., co skutkuje doklejeniem domeny podwójnie.
Podwójny SPF – dwa rekordy TXT z polityką SPF dla tej samej nazwy, co powoduje ignorowanie obu.
CNAME i inne rekordy w jednym miejscu – próba ustawienia CNAME i A/MX dla tej samej nazwy. Standard tego nie dopuszcza.
Za długi TTL przed migracją – zmiana IP „w ciemno” przy TTL = 86400 i frustracja, że wszędzie widnieje stary adres.
Kiedy coś nie działa, przejrzyj strefę pod kątem duplikatów i sprzecznych rekordów. Często wystarczy usunąć zbędne wpisy i zostawić minimalny, spójny zestaw.
DNS a SSL: co trzeba ustawić, żeby działał HTTPS
Samo DNS nie tworzy certyfikatu, ale bez poprawnych rekordów nie da się go wygenerować.
Dla certyfikatu muszą istnieć rekordy A/AAAA dla wszystkich nazw, które chcesz zabezpieczyć, np.:
mojafirma.pl
www.mojafirma.pl
Przy automatycznym wydawaniu certyfikatów (np. Let’s Encrypt) możesz spotkać dodatkowe wymagania:
rekord TXT dla walidacji DNS (np. _acme-challenge.mojafirma.pl),
prawidłowo ustawiony rekord CAA, jeśli jest używany.
Jeśli CAA ogranicza wystawców, a chcesz użyć innego dostawcy certyfikatu, trzeba dopisać go do istniejącego rekordu lub zmienić politykę.
Subdomeny i delegowanie części strefy
Subdomena to po prostu kolejna nazwa w tej samej strefie, np. panel.mojafirma.pl. W większości paneli dodaje się ją jak zwykły rekord A/CNAME.
Przykład prostych subdomen:
panel A 203.0.113.40
blog CNAME zewnetrzny-blog.hosting.pl.
Istnieje też opcja delegowania całej subdomeny innemu operatorowi DNS za pomocą NS, np. oddzielny DNS dla dev.mojafirma.pl:
dev NS ns1.dev-dns.pl.
dev NS ns2.dev-dns.pl.
Od tego momentu rekordy typu A/MX/TXT dla cokolwiek.dev.mojafirma.pl ustawia się już u dostawcy, którego NS wskazano.
DNS w chmurze i CDN – co się zmienia
Przy korzystaniu z CDN lub usług typu „reverse proxy” DNS często nie wskazuje już bezpośrednio na IP twojego serwera, tylko na infrastrukturę pośrednika.
Przykładowy scenariusz:
@ A 198.51.100.20 – IP sieci CDN zamiast IP hostingu,
prawdziwe IP serwera jest „ukryte” za dostawcą CDN.
W panelu CDN zwykle:
definiujesz, na jaki host i port ma być przekazywany ruch,
zarządzasz certyfikatami SSL i ustawiasz przekierowania.
Przy takich rozwiązaniach błędy DNS często widać dopiero podwójnie: trzeba sprawdzić zarówno strefę domeny, jak i konfigurację po stronie CDN.
Jak DNS łączy się z rekordami odwrotnymi (PTR)
Rekordy PTR są szczególnie istotne przy poczcie wychodzącej. Serwery odbiorcy porównują adres IP łączącego się serwera z reverse DNS.
Dobre minimum:
IP serwera pocztowego ma PTR wskazujący na nazwę, którą podajesz w HELO/EHLO,
ta nazwa ma rekord A (np. mail.mojafirma.pl → IP serwera poczty).
PTR ustala operator IP, więc samodzielnie konfiguruje się tylko drugą stronę powiązania: rekord A dla nazwy, na którą wskazuje reverse DNS.
Bezpieczeństwo DNS w wersji podstawowej
Bez dodatkowych zabezpieczeń DNS jest podatny na podszywanie się pod odpowiedzi (spoofing). W domowych i małych firmowych instalacjach najczęściej spotkasz jednak minimum ochrony.
Kilka prostych kroków:
używanie serwerów DNS z filtrowaniem złośliwych domen (często oferują je operatorzy i publiczne DNS),
ograniczenie publicznego dostępu do własnego serwera DNS, jeśli taki prowadzisz (brak „otwartego resolvera”),
rozsądna konfiguracja rekordów pocztowych (SPF, DKIM, DMARC), żeby utrudnić podszywanie się pod twoją domenę.
Zaawansowane funkcje jak DNSSEC czy DNS-over-HTTPS wprowadza się zwykle już na późniejszym etapie, często z pomocą administratora lub dostawcy hostingu.
Przenoszenie domeny i hostingu bez przerwy w działaniu
Migracja domeny między rejestratorami a migracja hostingu to dwie różne operacje. Przerwę w działaniu zwykle powoduje ta druga.
Przy przenoszeniu strony na inny serwer prosty schemat wygląda tak:
Skopiuj dane na nowy hosting i przygotuj tam działającą kopię (czasem pod techniczną subdomeną).
Obniż TTL rekordów A/AAAA kilka dni wcześniej.
W umówionym momencie zmień IP w rekordzie A/AAAA (lub przełącz CNAME na nowego dostawcę).
Przez pewien czas utrzymuj starą i nową instalację równolegle, jeśli to możliwe.
Przy przenoszeniu samej domeny do innego rejestratora można zachować te same serwery NS. Wtedy strefa DNS się nie zmienia, a użytkownicy nie widzą różnicy.
Minimalny zestaw rekordów dla prostej strony firmowej
Dla małej strony „wizytówki” wystarcza w praktyce kilka pozycji w strefie:
A dla @ – IP serwera www,
CNAME dla www na mojafirma.pl. lub osobny A z tym samym IP,
MX dla @ wskazujący na nazwę serwera pocztowego,
A dla hosta poczty (np. mail),
1–3 rekordy TXT dla SPF, DKIM, DMARC, jeśli korzystasz z poczty.
Większość paneli hostingu ma gotowe szablony takich konfiguracji. Warto je przejrzeć, ale dobrze też rozumieć, co dokładnie jest dodawane do strefy.
Najczęściej zadawane pytania (FAQ)
Co to jest DNS prostymi słowami?
DNS to „książka telefoniczna internetu”. Zamienia nazwy stron, które wpisujesz w przeglądarce (np. mojafirma.pl), na adresy IP serwerów (np. 203.0.113.10), które rozumie komputer.
Dzięki DNS nie musisz pamiętać numerów IP. Wpisujesz nazwę domeny, a reszta dzieje się automatycznie w ułamku sekundy.
Po co jest DNS i co by było, gdyby go nie było?
DNS sprawia, że internet jest używalny dla ludzi. Pozwala korzystać z prostych nazw zamiast z długich ciągów cyfr (adresów IP).
Bez DNS musiałbyś wpisywać dokładne adresy IP każdej strony i poczty. Technicznie internet nadal by działał, ale dla zwykłego użytkownika byłby praktycznie nie do ogarnięcia.
Dlaczego pojawia się błąd „DNS_PROBE_FINISHED_NXDOMAIN” lub „Nie można odnaleźć adresu serwera”?
Ten typ błędu oznacza, że przeglądarka nie może ustalić adresu IP dla wpisanej domeny. Coś poszło nie tak na etapie „tłumaczenia” nazwy na numer.
Przyczyny bywają różne: literówka w domenie, błędnie skonfigurowana strefa DNS u właściciela domeny, problem z serwerem DNS dostawcy internetu albo z lokalnym routerem.
Czym różni się domena od hostingu i jaką rolę ma DNS?
Domena to sam adres (np. mojasklep.pl), który rejestrujesz u rejestratora. Hosting (serwer) to miejsce, gdzie fizycznie leży Twoja strona, pliki i baza danych.
DNS „spina” jedno z drugim. Rekordy DNS mówią: ta domena i subdomeny (np. www.mojasklep.pl, panel.mojasklep.pl) mają kierować ruch na konkretny serwer, pod konkretny adres IP.
Co to jest rekord A, MX i TXT w strefie DNS?
Rekord A wskazuje adres IP (IPv4) serwera dla danej nazwy, np. mojadomena.pl → 203.0.113.10. To podstawowy typ rekordu dla stron www.
Rekord MX określa, gdzie ma trafiać poczta dla danej domeny, np. gdzie są serwery obsługujące adresy w formacie imie@mojadomena.pl.
Rekord TXT przechowuje teksty techniczne, np. SPF do ochrony poczty, weryfikacje Google Search Console czy inne potwierdzenia własności domeny.
Co to jest resolver DNS i czym różni się od serwera autorytatywnego?
Resolver (serwer rekursywny) to pierwszy serwer, do którego trafia zapytanie z Twojego komputera lub routera. Szuka odpowiedzi w swoim cache, a jeśli jej nie ma, „biega” po internecie, pytając kolejne serwery.
Serwer autorytatywny trzyma właściwą strefę DNS domeny. To on przechowuje rekordy A, MX, TXT itp. dla danej domeny i jest ostatecznym źródłem prawdy, jaki adres IP ma konkretna nazwa.
Czy zmiana DNS na 8.8.8.8 lub 1.1.1.1 przyspieszy internet?
Zmiana DNS może przyspieszyć samo „tłumaczenie” nazw na adresy IP, szczególnie gdy DNS od operatora działa wolno lub niestabilnie. Często widać to przy pierwszym wejściu na stronę.
Nie wpływa to jednak na prędkość pobierania danych z serwera (np. łącze 300 Mb/s nie stanie się 600 Mb/s). Zmienia się głównie czas pierwszego „namierzenia” serwera po wpisaniu domeny.
