Co robi DNS i jak działa?

DNS (Domain Name System) to rozproszona infrastruktura nazewnictwa internetowego, która tłumaczy czytelne dla człowieka nazwy domen — takie jak example.com — na czytelne dla maszyn adresy IP, jak 93.184.216.34. Bez DNS każde żądanie przeglądarki, wywołanie API i dostarczenie wiadomości e-mail wymagałoby od użytkowników i aplikacji znajomości dokładnego adresu numerycznego każdego zdalnego hosta, co uczyniłoby nowoczesny internet operacyjnie niemożliwym na dużą skalę.

W swojej istocie DNS jest globalnie rozproszoną, hierarchiczną bazą danych. Nie jest to pojedynczy serwer ani scentralizowany rejestr — jest to drzewo delegacji obejmujące setki tysięcy autorytatywnych serwerów nazw na całym świecie, koordynowane przez niewielki zestaw serwerów głównych i regulowane standardami zdefiniowanymi w RFC 1034 i RFC 1035.

Dlaczego DNS to coś więcej niż tylko „książka telefoniczna”

Analogia do książki telefonicznej jest przydatna dla początkujących, ale dramatycznie zaniża to, co DNS faktycznie robi. DNS to działający w czasie rzeczywistym, odporny na awarie, globalnie replikowany system wyszukiwania, który obsługuje również:

• Routing poczty za pomocą rekordów MX, kierujących pocztę e-mail do właściwych serwerów pocztowych
• Wykrywanie usług za pomocą rekordów SRV, używanych przez protokoły takie jak SIP, XMPP i wewnętrzna sieć Kubernetes
• Weryfikację własności domeny za pomocą rekordów TXT, używanych dla SPF, DKIM, DMARC i Google Search Console
• Kanoniczne nazewnictwo za pomocą rekordów CNAME, umożliwiających integrację CDN i równoważenie obciążenia
• Adresowanie IPv6 za pomocą rekordów AAAA
• Odwrotne wyszukiwania za pomocą rekordów PTR w strefie in-addr.arpa, kluczowych dla reputacji serwera pocztowego i audytu bezpieczeństwa
• Walidacja DNSSEC, która dodaje podpisy kryptograficzne do odpowiedzi DNS, aby zapobiec zatruwaniu pamięci podręcznej

Za każdym razem, gdy wysyłasz wiadomość e-mail, łączysz się z VPN lub ładujesz aplikację internetową, DNS rozwiązuje w tle wiele typów rekordów — często dziesiątki zapytań na załadowanie strony.

Hierarchia DNS: jak zorganizowana jest przestrzeń nazw

DNS jest zorganizowany jako odwrócone drzewo. Zrozumienie tej struktury jest niezbędne do zrozumienia, dlaczego rozwiązywanie nazw działa w taki sposób.

.  (Root Zone)
├── com
│   ├── example.com  (Second-Level Domain)
│   │   └── www.example.com  (Subdomain / FQDN)
├── org
├── net
└── uk
    └── co.uk

• Strefa główna (.): Zarządzana przez IANA. Istnieje 13 logicznych adresów serwerów głównych (od A do M), obsługiwanych przez organizacje takie jak Verisign, NASA i ICANN. W praktyce są one obsługiwane przez setki fizycznych maszyn za pośrednictwem routingu anycast.
• Domeny najwyższego poziomu (TLD): Ogólne TLD, takie jak .com, .net, .org, oraz TLD z kodem kraju, takie jak .uk, .de, .md. Każdy TLD ma własny zestaw autorytatywnych serwerów nazw.
• Domeny drugiego poziomu (SLD): Domena, którą rejestrujesz — example.com. Autorytatywny DNS dla tej strefy jest kontrolowany przez osobę, która zarejestrowała domenę.
• Subdomeny: www, mail, api, staging — są to rekordy w strefie SLD, w pełni kontrolowane przez właściciela domeny.

Krok po kroku: jak rozwiązywane jest zapytanie DNS

Pełne rekurencyjne rozwiązywanie DNS obejmuje do siedmiu odrębnych wymian sieciowych. Oto dokładna sekwencja:

Krok 1 — Sprawdzenie pamięci podręcznej przeglądarki

Gdy wpisujesz www.example.com w przeglądarce, system operacyjny najpierw sprawdza lokalną pamięć podręczną DNS. W systemie Linux może być ona zarządzana przez systemd-resolved; w systemie Windows — przez usługę klienta DNS. Jeśli istnieje ważny rekord w pamięci podręcznej, a jego TTL (Time to Live) nie wygasł, rozwiązywanie kończy się tutaj.

Możesz sprawdzić lokalną pamięć podręczną DNS w systemie Linux za pomocą:

resolvectl statistics

Lub wyczyścić ją za pomocą:

sudo resolvectl flush-caches

W systemie Windows:

ipconfig /displaydns
ipconfig /flushdns

Krok 2 — Zapytanie do resolwera rekurencyjnego

Jeśli nie ma odpowiedzi w pamięci podręcznej, system operacyjny przekazuje zapytanie do skonfigurowanego resolwera rekurencyjnego (zwanego również rekurencyjnym serwerem DNS lub resolwerem pełnej usługi). Zazwyczaj jest to:

• Resolwer Twojego dostawcy usług internetowych (przypisany przez DHCP)
• Publiczny resolwer: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), 9.9.9.9 (Quad9)
• Własny resolwer, taki jak Unbound lub BIND, na Twojej własnej infrastrukturze VPS Hosting

Resolwer rekurencyjny wykonuje ciężką pracę. Przejdzie przez hierarchię DNS w Twoim imieniu i zapisze wyniki w pamięci podręcznej, aby szybciej obsługiwać przyszłe zapytania.

Krok 3 — Odesłanie do serwera głównego

Resolwer rekurencyjny wysyła zapytanie do jednego z 13 klastrów serwerów głównych. Serwer główny nie zna adresu IP www.example.com. Zamiast tego zwraca odesłanie — listę autorytatywnych serwerów nazw dla strefy TLD .com, wraz z ich adresami IP (zwanymi rekordami glue).

Krok 4 — Zapytanie do serwera nazw TLD

Resolwer wysyła zapytanie do serwerów nazw TLD .com (obsługiwanych przez Verisign). Te serwery również nie posiadają ostatecznej odpowiedzi. Zwracają kolejne odesłanie — autorytatywne serwery nazw dla example.com konkretnie (np. ns1.example.com, ns2.example.com).

Krok 5 — Zapytanie do autorytatywnego serwera nazw

Resolwer wysyła zapytanie do autorytatywnego serwera nazw dla example.com. Ten serwer przechowuje rzeczywisty plik strefy i zwraca ostateczną odpowiedź — rekord A zawierający adres IPv4 (lub AAAA dla IPv6).

Krok 6 — Zapisanie odpowiedzi w pamięci podręcznej i dostarczenie

Resolwer rekurencyjny zapisuje odpowiedź w pamięci podręcznej zgodnie z wartością TTL rekordu (np. 300 sekund = 5 minut, 86400 sekund = 24 godziny). Następnie zwraca adres IP do systemu operacyjnego klienta, który przekazuje go do przeglądarki.

Krok 7 — Połączenie TCP/IP

Przeglądarka używa rozwiązanego adresu IP, aby otworzyć połączenie TCP (zazwyczaj na porcie 443 dla HTTPS). Zadanie DNS jest teraz zakończone. Serwer WWW odpowiada i strona się ładuje.

Cały ten proces — kroki od 2 do 6 — zazwyczaj kończy się w ciągu 20–120 milisekund przy ciepłej pamięci podręcznej resolwera i poniżej 500 milisekund przy całkowicie zimnym, niebuforowanym rozwiązywaniu przechodzącym przez wszystkie poziomy hierarchii.

Typy rekordów DNS: techniczny przewodnik

Rekordy CAA zasługują na szczególną uwagę: instruują urzędy certyfikacji, które organizacje mają prawo wystawiać Certyfikaty SSL dla Twojej domeny — jest to kluczowa kontrola bezpieczeństwa, która jest często pomijana.

Typy zapytań DNS: rekurencyjne, iteracyjne i nierekurencyjne

Większość urządzeń użytkowników końcowych wysyła zapytania rekurencyjne do skonfigurowanego resolwera. Sam resolwer używa zapytań iteracyjnych podczas przechodzenia przez hierarchię.

TTL: najbardziej niezrozumiany parametr DNS

TTL (Time to Live) to liczba sekund, przez którą rekord DNS może być przechowywany w pamięci podręcznej przez resolwery i klientów. Jest ustawiany przez właściciela domeny w pliku strefy.

• Niski TTL (60–300 sekund): Szybsza propagacja zmian. Niezbędny przed planowanymi migracjami, zmianami IP lub zdarzeniami przełączania awaryjnego. Zwiększa obciążenie zapytaniami na autorytatywnych serwerach.
• Wysoki TTL (3600–86400 sekund): Zmniejsza obciążenie resolwera i przyspiesza powtarzające się zapytania. Zmiany propagują się wolniej na całym świecie.

Kluczowa wskazówka operacyjna: Planując migrację serwera lub zmianę IP, zmniejsz TTL do 300 sekund co najmniej 48 godzin przed zmianą. Zapewni to, że w momencie aktualizacji rekordu A żaden resolwer nie będzie przechowywał starej wartości w pamięci podręcznej przez więcej niż 5 minut. Niezastosowanie się do tego jest jedną z najczęstszych przyczyn przedłużonych przestojów podczas migracji.

Gdy rejestrujesz domenę przez Rejestrację domen i wskazujesz ją na nowy serwer, okno propagacji jest bezpośrednio regulowane przez poprzednią wartość TTL — a nie przez arbitralne zasady „24–48 godzin”, które są często błędnie cytowane.

Protokoły transportowe DNS: UDP, TCP, DoH i DoT

Tradycyjny DNS działa przez UDP port 53 dla zapytań poniżej 512 bajtów. Odpowiedzi przekraczające ten rozmiar wyzwalają przełączenie na TCP port 53. Odpowiedzi DNSSEC, transfery stref (AXFR) i duże rekordy TXT często wymagają TCP.

Nowoczesne protokoły prywatności DNS znacząco zmieniły ten krajobraz:

DoH vs. DoT — rzeczywista różnica operacyjna: DoH tuneluje DNS wewnątrz ruchu HTTPS na porcie 443, czyniąc go nieodróżnialnym od zwykłego ruchu internetowego. Jest to przydatne dla prywatności, ale znacznie utrudnia monitorowanie i filtrowanie sieci w przedsiębiorstwie. DoT używa dedykowanego portu (853), który administratorzy sieci mogą niezależnie monitorować, blokować lub sprawdzać. W przypadku własnej infrastruktury na Serwerze dedykowanym, uruchomienie lokalnego resolwera DoT lub DoH zapewnia zarówno prywatność, jak i pełną kontrolę nad polityką rozwiązywania nazw.

DNSSEC: kryptograficzna integralność DNS

DNSSEC (DNS Security Extensions) dodaje łańcuch podpisów kryptograficznych do odpowiedzi DNS, umożliwiając resolwerom weryfikację autentyczności odpowiedzi i potwierdzenie, że nie została ona zmodyfikowana podczas transmisji. Chroni przed zatruwaniem pamięci podręcznej DNS (atak Kaminsky’ego) i podszywaniem się pod DNS w atakach man-in-the-middle.

DNSSEC nie szyfruje ruchu DNS — jedynie go podpisuje. Łańcuch podpisów działa następująco:

1. Właściciel strefy generuje klucz podpisywania strefy (ZSK) i klucz podpisywania kluczy (KSK)
2. Każdy zestaw rekordów DNS jest podpisywany za pomocą ZSK, tworząc rekordy RRSIG
3. KSK podpisuje zestaw rekordów DNSKEY
4. Rekord DS (Delegation Signer) jest publikowany w strefie nadrzędnej (np. .com), tworząc łańcuch zaufania prowadzący z powrotem do korzenia

Włączenie DNSSEC jest zdecydowanie zalecane dla każdej domeny obsługującej transakcje finansowe, uwierzytelnianie lub pocztę e-mail. Błędnie skonfigurowany DNSSEC — w szczególności wygasły podpis lub niezgodny rekord DS — spowoduje całkowite niepowodzenie rozwiązywania nazw dla walidujących resolwerów, co jest trudniejszym trybem awarii niż brak DNSSEC.

Typowe awarie DNS i jak je diagnozować

NXDOMAIN — nieistniejąca domena

Autorytatywny serwer potwierdził, że domena nie istnieje. Typowe przyczyny: literówka w nazwie domeny, wygasła rejestracja domeny, usunięty rekord DNS.

dig www.example.com
# Look for: status: NXDOMAIN

SERVFAIL — awaria serwera

Resolwer nie mógł ukończyć zapytania. Typowe przyczyny: błąd walidacji DNSSEC, nieosiągalny autorytatywny serwer, błędnie skonfigurowany plik strefy.

dig +dnssec example.com
# Look for: status: SERVFAIL

Aby ominąć walidację DNSSEC i wyizolować problem:

dig +cd example.com
# +cd = checking disabled; bypasses DNSSEC validation

Przestarzała pamięć podręczna / opóźnienie propagacji

Po zaktualizowaniu rekordu DNS stare wartości pozostają w pamięci podręcznej resolwerów do czasu wygaśnięcia TTL. Aby zapytać bezpośrednio autorytatywny serwer i ominąć pamięć podręczną resolwera:

dig @ns1.example.com www.example.com

Sprawdzanie propagacji DNS na całym świecie

Użyj dig z określonymi publicznymi resolwerami, aby sprawdzić stan propagacji:

dig @8.8.8.8 www.example.com A
dig @1.1.1.1 www.example.com A
dig @9.9.9.9 www.example.com A

DNS w środowiskach hostingowych: praktyczne konfiguracje

Gdy wdrażasz stronę internetową lub aplikację na VPS z cPanel, zarządzanie DNS jest zazwyczaj obsługiwane przez klaster DNS WHM lub edytor stref cPanel. Zrozumienie struktury pliku strefy pozwala wprowadzać zmiany, których interfejs graficzny nie udostępnia.

Minimalny plik strefy dla example.com wygląda następująco:

$TTL 3600
@   IN  SOA  ns1.example.com. admin.example.com. (
            2024010101  ; Serial
            3600        ; Refresh
            900         ; Retry
            604800      ; Expire
            300 )       ; Minimum TTL

@       IN  NS      ns1.example.com.
@       IN  NS      ns2.example.com.
@       IN  A       203.0.113.10
www     IN  A       203.0.113.10
mail    IN  A       203.0.113.20
@       IN  MX  10  mail.example.com.
@       IN  TXT     "v=spf1 ip4:203.0.113.20 ~all"

Aby Hosting poczty e-mail działał poprawnie, rekord MX musi wskazywać na nazwę hosta (nie bezpośrednio na adres IP), a ta nazwa hosta musi sama rozwiązywać się za pomocą rekordu A. Częstą błędną konfiguracją jest wskazywanie MX bezpośrednio na adres IP — narusza to RFC 2821 i powoduje błędy dostarczania w przypadku rygorystycznych serwerów pocztowych.

Wydajność DNS: co faktycznie wpływa na szybkość rozwiązywania nazw

• Bliskość resolwera: Resolwer geograficznie bliski klientowi (lub w tej samej sieci) drastycznie skraca czas podróży w obie strony.
• Współczynnik trafień w pamięci podręcznej: Domeny o dużym ruchu z rozsądnymi wartościami TTL są prawie zawsze obsługiwane z pamięci podręcznej. Rozwiązywanie przy zimnej pamięci podręcznej jest 5–20 razy wolniejsze.
• Routing anycast: Serwery główne i główne publiczne resolwery używają anycast, automatycznie kierując zapytania do najbliższego fizycznego węzła.
• Liczba wyszukiwań DNS na stronę: Pojedyncza strona internetowa może wyzwolić 20–50 zapytań DNS (zasoby CDN, analityka, czcionki, sieci reklamowe). Przeglądarki równoległizują te zapytania, ale każda unikalna nazwa hosta wymaga własnego wyszukiwania.
• Wstępne pobieranie DNS: Nowoczesne przeglądarki obsługują <link rel="dns-prefetch" href="//cdn.example.com"> do rozwiązywania nazw hostów stron trzecich przed ich potrzebą, zmniejszając odczuwalne opóźnienia.

DNS a alternatywne mechanizmy rozwiązywania nazw

Plik /etc/hosts jest sprawdzany przed DNS praktycznie w każdym systemie operacyjnym. Czyni go to nieocenionym narzędziem do lokalnego programowania — możesz mapować myapp.local na 127.0.0.1 bez dotykania jakiejkolwiek infrastruktury DNS.

Kluczowe wnioski i lista kontrolna

Użyj tej listy kontrolnej podczas konfigurowania lub rozwiązywania problemów z DNS w dowolnym środowisku produkcyjnym:

• Przed każdą migracją serwera: Obniż TTL do 300 sekund co najmniej 48 godzin wcześniej
• Dla dostarczalności poczty e-mail: Sprawdź, czy rekordy MX, SPF (TXT), DKIM (TXT), DMARC (TXT) i PTR są wszystkie poprawnie skonfigurowane
• Dla bezpieczeństwa: Włącz DNSSEC na swojej domenie i dodaj rekordy CAA, aby ograniczyć wystawianie certyfikatów
• Dla prywatności: Używaj DoT lub DoH na urządzeniach klienckich i serwerach; unikaj wysyłania niezaszyfrowanego DNS przez niezaufane sieci
• Dla wydajności: Ustaw TTL na 3600–86400 dla stabilnych rekordów; używaj 300 tylko dla rekordów, które często się zmieniają
• Dla diagnostyki: Zawsze wysyłaj zapytanie bezpośrednio do autorytatywnego serwera za pomocą dig @ns1.yourdomain.com, aby odróżnić opóźnienie propagacji od rzeczywistej błędnej konfiguracji
• Dla zarządzania strefą: Zwiększaj numer seryjny SOA za każdym razem, gdy modyfikujesz plik strefy — resolwery używają go do wykrywania zmian
• Dla hostingu: Potwierdź, że delegacja serwerów nazw u rejestratora odpowiada rekordom NS w pliku strefy — niezgodność jest najczęstszą przyczyną „niedziałającego DNS” po transferze domeny

Często zadawane pytania

Jaka jest różnica między resolwerem DNS a autorytatywnym serwerem DNS?

Resolwer rekurencyjny (np. 8.8.8.8) jest pośrednikiem, który wysyła zapytania do hierarchii DNS w imieniu Twojego urządzenia i zapisuje wyniki w pamięci podręcznej. Autorytatywny serwer nazw przechowuje rzeczywiste rekordy strefy dla konkretnej domeny i udziela ostatecznych odpowiedzi. Twój resolwer wysyła zapytania do wielu autorytatywnych serwerów; autorytatywny serwer Twojej domeny odpowiada tylko dla stref, które hostuje.

Dlaczego propagacja DNS zajmuje czas po aktualizacji rekordu?

Opóźnienie propagacji jest spowodowane buforowaniem opartym na TTL. Każdy resolwer, który wcześniej zapisał w pamięci podręcznej Twój stary rekord, będzie go nadal serwować do czasu wygaśnięcia TTL. Jeśli Twój TTL wynosił 86400 (24 godziny), resolwery mogą serwować stary rekord przez maksymalnie 24 godziny po Twojej aktualizacji. To nie jest błąd — jest to zamierzony mechanizm buforowania, który sprawia, że DNS jest skalowalny.

Czym jest wyciek DNS i dlaczego ma znaczenie?

Wyciek DNS występuje, gdy Twoje urządzenie wysyła zapytania DNS poza zamierzony resolwer — zazwyczaj resolwer Twojego dostawcy usług internetowych — nawet podczas korzystania z VPN lub narzędzia do ochrony prywatności. Ujawnia to Twoją aktywność przeglądania dostawcy usług internetowych. Możesz przetestować wycieki na dnsleaktest.com i naprawić je, konfigurując klienta VPN tak, aby wymuszał routing DNS przez własny resolwer.

Czy DNS może być używany jako wektor ataku?

Tak. Typowe ataki oparte na DNS obejmują zatruwanie pamięci podręcznej (wstrzykiwanie fałszywych rekordów do pamięci podręcznej resolwera), amplifikację DNS DDoS (używanie otwartych resolwerów do zalewania celu dużymi odpowiedziami DNS), przejęcie DNS (przekierowywanie zapytań do złośliwych serwerów) i tunelowanie DNS (eksfiltracja danych przez kodowanie ich w ciągach zapytań DNS). DNSSEC łagodzi zatruwanie pamięci podręcznej; ograniczanie szybkości i ograniczanie szybkości odpowiedzi (RRL) na autorytatywnych serwerach łagodzą amplifikację.

Jak znaleźć autorytatywne serwery nazw dla dowolnej domeny?

Użyj dig z typem rekordu NS i flagą +short dla przejrzystego wyniku:

dig NS example.com +short

Aby prześledzić pełną ścieżkę delegacji od korzenia do autorytatywnego serwera, użyj:

dig +trace example.com

Pokazuje to każdy krok odesłania — root → TLD → autorytatywny — co jest najbardziej niezawodnym sposobem diagnozowania błędnych konfiguracji delegacji.