W poniższym wpisie przeprowadzę test pokazujący, w jaki sposób system DNS tłumaczy nazwę domenową na adres IP. Ćwiczenie pozwala prześledzić każdy krok zapytania opisanego w teorii sieci: od lokalnej pamięci podręcznej, przez serwer rekurencyjny, aż po odpytanie serwerów głównych, TLD oraz autorytatywnych.

Cel i założenia ćwiczenia

Celem ćwiczenia jest zbadanie mechanizmu translacji nazwy na przykładzie domeny tryhackme.com przy użyciu systemu Kali Linux oraz narzędzia dig.

Główne punkty zadania:

  1. Sprawdzenie działania lokalnego cache DNS w systemie operacyjnym.
  2. Wysłanie zapytania do serwera rekurencyjnego i analiza flag odpowiedzi.
  3. Ręczne przejście pełnej ścieżki hierarchii DNS: Root Server → TLD Server → Authoritative Server.
  4. Weryfikacja ścieżki za pomocą automatycznego śledzenia dig +trace.
  5. Obserwacja czasu życia rekordu (TTL) i buforowania odpowiedzi.

Środowisko laboratoryjne

Do wykonania ćwiczenia wystarczy pojedyncza maszyna wirtualna z systemem Kali Linux.

Krok 1: Weryfikacja lokalnego cache DNS

Przed wysłaniem zapytania do internetu system sprawdza lokalną pamięć podręczną oraz plik /etc/hosts.

W nowoczesnych dystrybucjach Linuksa usługą zarządzającą lokalnym cache jest często systemd-resolved. Stan pamięci podręcznej można zweryfikować poleceniem:

resolvectl statistics

Jeśli chcemy upewnić się, że kolejne testy trafią do sieci, możemy wyczyścić lokalny cache DNS:

sudo resolvectl flush-caches

Krok 2: Standardowe zapytanie do serwera rekurencyjnego

W codziennym użytkowaniu stacja robocza wysyła jedno zapytanie do serwera rekurencyjnego (np. serwera dostawcy ISP lub publicznego 1.1.1.1 / 8.8.8.8), który wykonuje całą pracę za klienta.

Wykonanie zapytania o rekord A dla domeny:

dig @1.1.1.1 tryhackme.com A +noall +answer +comments

Wynik polecenia:

Znaczenie kluczowych flag w nagłówku:

  • qr (Query Response) – pakiet jest odpowiedzią.
  • rd (Recursion Desired) – klient poprosił serwer o wykonanie pełnego zapytania rekurencyjnego.
  • ra (Recursion Available) – serwer potwierdza, że obsługuje rekurencję.

Krok 3: Ręczne odtworzenie hierarchii zapytań DNS

Aby zrozumieć, co dzieje się pod maską serwera rekurencyjnego, odpytamy kolejno poszczególne szczeble hierarchii DNS z wyłączoną rekurencją (+norecurse).

1. Zapytanie do serwera głównego (Root DNS)

Wysyłamy zapytanie do jednego z 13 serwerów głównych (np. a.root-servers.net o adresie 198.41.0.4):

dig @198.41.0.4 tryhackme.com A +norecurse

Serwer główny nie zna adresu IP domeny tryhackme.com, ale wskazuje serwery odpowiedzialne za domenę najwyższego poziomu .com (TLD):

;; AUTHORITY SECTION:
com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
...

;; ADDITIONAL SECTION:
a.gtld-servers.net.	172800	IN	A	192.5.6.30

2. Zapytanie do serwera TLD (.com)

Pobieramy adres jednego ze wskazanych serwerów TLD (np. a.gtld-servers.net - 192.5.6.30) i wysyłamy do niego kolejne zapytanie bez rekurencji:

dig @192.5.6.30 tryhackme.com A +norecurse

Serwer TLD również nie zwraca jeszcze rekordu A, lecz przekazuje listę autorytatywnych serwerów nazw (nameservers) dla badanej domeny:

;; AUTHORITY SECTION:
tryhackme.com.		172800	IN	NS	kip.ns.cloudflare.com.
tryhackme.com.		172800	IN	NS	uma.ns.cloudflare.com.

3. Pobranie rekordu z serwera autorytatywnego

Ostatnim etapem jest odpytanie serwera autorytatywnego (np. kip.ns.cloudflare.com):

dig @kip.ns.cloudflare.com tryhackme.com A +norecurse

Wynik odpowiedzi:

;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
tryhackme.com.		300	IN	A	104.26.10.229
tryhackme.com.		300	IN	A	104.26.11.229

Flaga aa (Authoritative Answer) potwierdza, że odpowiedź pochodzi bezpośrednio z autorytatywnego źródła zarządzającego strefą domeny.

Krok 4: Automatyczne śledzenie ścieżki za pomocą dig +trace

Wszystkie powyższe kroki można prześledzić w jednym poleceniu przy użyciu przełącznika +trace:

dig tryhackme.com A +trace

Narzędzie dig rozpoczyna zapytanie od serwerów głównych (Root), przechodzi do serwerów TLD .com, a na końcu odpytuje serwer Cloudflare i wypisuje końcowy adres IP.

Podsumowanie

Przeprowadzone ćwiczenie w przejrzysty sposób pokazuje różnicę między zapytaniem rekurencyjnym a iteracyjnym:

  • Klient komunikuje się zazwyczaj wyłącznie z serwerem rekurencyjnym.
  • Pełny proces translacji nazwy wymaga kontaktu z trzema poziomami hierarchii: serwerem Root, serwerem TLD oraz serwerem autorytatywnym.
  • Mechanizm buforowania oraz parametr TTL ograniczają ruch w sieci i odciążają serwery autorytatywne.