System nazw domen (DNS) — definicja, działanie i protokoły RFC

System nazw domen (DNS) jest systemem używanym do przekształcania nazwy hosta komputera w adres IP w Internecie. Na przykład, jeśli komputer musi komunikować się z serwerem WWW example.net, komputer potrzebuje adresu IP serwera WWW example.net. Zadaniem DNS jest przekształcenie nazwy hosta na adres IP serwera WWW. DNS jest czasami nazywany internetową książką telefoniczną, ponieważ konwertuje on nazwę strony internetowej, którą ludzie znają, na numer, który jest faktycznie używany w Internecie.

DNS jest definiowany przez dokumenty Request for Comments (RFC). Są to dokumenty techniczne dotyczące sieci komputerowych. DNS jest głównie zdefiniowany przez RFC 1034 i RFC 1035. Istnieją również późniejsze RFC, które definiują zmiany w systemie.

Jak działa DNS — przebieg zapytania

W uproszczeniu proces zamiany nazwy na adres wygląda tak:

• Klient (np. przeglądarka) pyta swój lokalny resolver (zwykle dostarczany przez system operacyjny lub operatora sieci) o adres dla nazwy, np. example.net.
• Jeśli resolver ma odpowiedź w pamięci podręcznej (cache) i odpowiedni czas życia (TTL) jeszcze nie wygasł, zwraca wynik bez dalszych zapytań.
• Jeżeli brak odpowiedzi w cache, resolver może wykonać zapytanie rekurencyjne do serwera DNS dostawcy usług (rekursywny resolver). Ten resolver wykonuje kolejne zapytania iteracyjne do serwerów: najpierw do serwerów root, potem do serwerów zarządzających strefą najwyższego poziomu (TLD), aż do serwera autorytatywnego dla danej strefy, który zna właściwy rekord.
• Serwer autorytatywny zwraca rekord (np. typu A lub AAAA) z adresem IP, a odpowiedź jest przekazywana z powrotem do klienta, przy czym po drodze może być zapisana w cache dla przyspieszenia kolejnych zapytań.

Główne komponenty DNS

• Resolver — oprogramowanie po stronie klienta, które wysyła zapytania DNS (może być rekursywny lub korzystać z rekursywnego serwera).
• Serwery root — najwyższy poziom w hierarchii DNS; przekierowują do serwerów TLD.
• Serwery TLD — obsługują domeny najwyższego poziomu (np. .com, .pl) i wskazują serwery autorytatywne dla danej domeny.
• Serwery autorytatywne — przechowują rekordy DNS dla konkretnej strefy (zone) i odpowiadają na zapytania dotyczące tych rekordów.
• Cache — pamięć podręczna, która przechowuje odpowiedzi przez czas określony w TTL, aby zmniejszyć liczbę zapytań i przyspieszyć odpowiedzi.

Podstawowe typy rekordów DNS

• A — mapuje nazwę na adres IPv4.
• AAAA — mapuje nazwę na adres IPv6.
• CNAME — alias jednej nazwy na inną nazwę (canonical name).
• MX — określa serwery pocztowe obsługujące domenę.
• NS — wskazuje serwery nazw autorytatywne dla strefy.
• PTR — rekord odwrotnego DNS (mapowanie IP → nazwa), używany w zapytaniach odwrotnych.
• SOA — Start of Authority, zawiera podstawowe informacje o strefie (m.in. kontakt, numer seryjny, polityki odświeżania).
• TXT — dowolny tekst, używany m.in. do weryfikacji domeny oraz polityk SPF/DKIM.

Typy zapytań i protokoły transportu

Standardowe zapytania DNS są przesyłane głównie przez UDP (port 53) ze względu na niskie opóźnienia. Jeśli odpowiedź nie mieści się w pojedynczym pakiecie UDP lub gdy wymagana jest transfer strefy, używany jest TCP (port 53). Istnieją dwa style zapytań:

• Rekurencyjne — klient żąda od resolvera pełnej odpowiedzi (resolver sam wykonuje dalsze zapytania do innych serwerów).
• Iteracyjne — serwer odpowiada najlepszą informacją, jaką posiada (np. wskazanie innego serwera), a klient może kontynuować zapytania samodzielnie.

Ważne RFC i rozszerzenia

DNS został pierwotnie zdefiniowany w RFC 1034 i RFC 1035. Z czasem pojawiły się liczne rozszerzenia i doprecyzowania, m.in.:

• RFC 2181 — dodatkowe wyjaśnienia dotyczące DNS;
• RFC 2136 — Dynamic DNS (aktualizacje dynamiczne strefy);
• RFC 4033–4035 — DNS Security Extensions (DNSSEC), które dodają podpisy cyfrowe do rekordów, zwiększając zaufanie do odpowiedzi;
• RFC 6891 — EDNS(0), rozszerzenia umożliwiające przesyłanie większych odpowiedzi przez UDP;
• RFC 7858 — DNS over TLS (DoT) oraz RFC 8484 — DNS over HTTPS (DoH), czyli metody szyfrowania zapytań DNS w celu poprawy prywatności.
• RFC 6762 — Multicast DNS (mDNS) dla lokalnych sieci bez centralnego serwera.

Bezpieczeństwo i prywatność

Tradycyjny DNS był projektowany w epoce, gdy bezpieczeństwo nie było priorytetem; odpowiedzi mogły być podszywane (DNS spoofing). Rozwiązania takie jak DNSSEC pozwalają weryfikować autentyczność odpowiedzi dzięki podpisom kryptograficznym, ale nie szyfrują treści. Aby chronić prywatność zapytań (uniemożliwić ich podsłuch), stosuje się DoT i DoH, które szyfrują komunikację między klientem a resolverem.

Zarządzanie strefami, TTL i delegacja

Domena jest podzielona na strefy (zone). Administrator strefy konfiguruje rekordy i parametr TTL (time to live), określający, jak długo odpowiedzi mogą być trzymane w cache. Delegacja polega na wskazaniu serwerów NS odpowiedzialnych za poddomenę (np. delegowanie sub.example.net do innych serwerów).

Praktyczne wskazówki

• Jeśli strona nie odpowiada, sprawdź najpierw, czy problem nie leży w DNS (np. użyj poleceń nslookup, dig).
• Przy zmianie rekordów pamiętaj o TTL — krótszy TTL pozwala szybciej rozpropagować zmiany, ale zwiększa liczbę zapytań do serwerów autorytatywnych.
• Włącz DNSSEC i rozważ użycie szyfrowanego transportu (DoH/DoT) w celu zwiększenia bezpieczeństwa i prywatności użytkowników.

DNS to kluczowy element infrastruktury Internetu — prosty w koncepcji (mapowanie nazw na numery), lecz złożony w implementacji i zabezpieczeniach. Dzięki wielowarstwowej hierarchii, mechanizmom cache i licznym rozszerzeniom DNS pozostaje skalowalny i elastyczny, obsługując współczesne potrzeby sieciowe.